Digilent 128x32 OLED Display IP doesn't work properly

[zygot]

While preparing a tutorial I came across an issue with all Digilent IP associated with the 128x32 Monochrome OLED display module that appear on numerous Digilent products.

There are numerous versions of VHDL and Verilog source code to demonstrate how to use the OLED display that have been posted over the years that the display has appeared on Digilent products. Unfortunately, none of them function properly. The most concerning is the manipulation of the Vbatt and Vdd FET control signals. Digilent acknowledges that not observing a recommended power-on and power-off can have deleterious effects on the display hardware over time.

From the PmodOLED Reference Manual: "The PmodOLED has a particular power-on/power-off sequence that must be followed to prolong the life of the display."

From the vivado-library PmodOLED_V1_0 README.md file: "To make sure that the Pmod OLED isn't damaged, make sure to safely quit the demo."  I haven't checked this version as it only supports ZYNQ or MicroBlaze designs and the source is in the form of a pre-compiled netlist.

As for the Verilog and VHDL code versions, none of them actually work as advertised. Specifically, there is no power-off activity on the control pins. In the case of the latest published Verilog code the OLEDCtrl.v code has major flaws that prevent if from being suitable for any of the demos.

When there is a possibility of damaging hardware it is vital that the designer actually verify that the design works as intended. I did this using an oscilloscope and by simulation. Obviously, no one at Digilent, including the many coders who've massaged the design, have bothered to do either of those verification steps.

I hacked the OLEDCtrl.v to at least manipulate the display power controls properly, and over repeated power-on and power-off cycles; but the code is so overly complicated and badly structured that I don't have the time to correct it's deficiencies.  It's not my responsibility to do this for Digilent IP even if I were so inclined. I thought about writing my own OLED controller but it's beyond the scope of my tutorial.

I suggest having someone completely re-write the OLED controller from a fresh start.

• Since it requires absolute timing it should work with any input clock. This can be done with generic or parameter specifications.
• Make it simpler so that whoever designs it, or modifies it, can understand what the heck is going on.
• Verifiy that the code does what it claims to be doing with a proper testbench simulation
• Verify control pin behavior with an oscilloscope.

Given the severity and number of products involved, I'd expect that Digilent would want to address this issue ASAP

 

Edited November 14, 2022 by zygot

[zygot]

Digilent does keep support for some of it's product up to date. For others, like the Nexys Video and the display PMODs support is generally pretty awful.
Once you get your OLED HDL working ( I'm optimistic! ) I suggest purging the old stuff. For things like hardware low level drivers, I strongly suggest not providing pre-compiled netlists in lieu of HDL sources. What's the user going to do when the netlist is non-functional, or as in the case of display controllers potentially dangerous?
[edit] As an experiment selecting the vivado_library OLED IP in a Spartan7 project. The netlist is incompatible because it was created for an Artix device. Even dcp netlists, as wonderful as they are, creates problems if you aren't careful.

Currently for the 128x32 OLED it's too difficult for users to know what code to use. Edited November 15, 2022 by zygot

[Ionut]

Hello,

The Nexys Video OLED Demo and the ZedBoard OLED Demo have been reviewed and the OLED turn on and turn off sequences have been updated.

To safely shut down the OLED display on Nexys Video, you would need to press the CPU_RESET button and wait for at least 3.5 seconds. Then you can turn off the board or reprogram it.

To safely shut down the OLED display on ZedBoard, you would need to press the BTNR button and wait for at least 3.5 seconds. Then you can turn off the board or reprogram it.

The above updates can be found in the latest releases for these demos:

• Nexys Video OLED/2022.1-2
• Nexys Video OLED/2023.1-1
• ZedBoard OLED/2022.1-2
• ZedBoard OLED/2023.1-1

Please consult the corresponding demo pages for more details: https://digilent.com/reference/programmable-logic/nexys-video/demos/oled?redirect=1 and https://digilent.com/reference/programmable-logic/zedboard/demos/oled?redirect=1, respectively.

 

The PmodOLED IP from vivado_library has also been reviewed and its turn on and turn off sequences updated. You can find the changes in the latest version of the master branch (https://github.com/Digilent/vivado-library).

Best Regards.

[zygot]

While I'm thinking about displays.

The ancient 12-pin PMOD really limits the ability of Digilent FPGA board users to experiment with small display modules. 8 GPIO pins is simply not enough to control a decent display, and in particular a grey-scale or colored display. FPGA boards from other vendors, like Terasic don't have this limitation. Come on Digilent... it's the 21st century!

[BMiller]

On 11/14/2022 at 1:42 PM, zygot said:

I strongly suggest not providing pre-compiled netlists in lieu of HDL sources. 

I strongly agree with this in general; what's the customer going to do, take the HDL and run off to build their own PMOD? Plus with the HDL (open sourced) it would be relatively easy for customers who are still using old(er) PMODs to keep them working (perhaps creating pull requests for modified versions so others can benefit too). 

[JColvin]

Hi @zygot,

You are correct in that the demo for the Pmod OLED IP does not do the DemoCleanup function (https://github.com/Digilent/vivado-library/blob/master/ip/Pmods/PmodOLED_v1_0/drivers/PmodOLED_v1_0/examples/main.c#L194) which would call the OLDE_DevTerm (https://github.com/Digilent/vivado-library/blob/master/ip/Pmods/PmodOLED_v1_0/drivers/PmodOLED_v1_0/src/OledDriver.c#L395) and OLED_HostTerm (https://github.com/Digilent/vivado-library/blob/master/ip/Pmods/PmodOLED_v1_0/drivers/PmodOLED_v1_0/src/OledDriver.c#L219) functions.

The HDL examples (available on the Pmod OLED Resource Center here: https://digilent.com/reference/pmod/pmodoled/start#programmable_logic) as you correctly noted do not do any proper manipulation of the power off sequences. In principle both of these things will be straightforward to update on Digilent's end (likely be forcing the display to turn off after a set period of time since adding support for an external button to aribtarily choose when to turn the display off is impractical if only due to hardware portability problems), though I do not know when the Applications and Systems Engineers will be given the green light to focus on this product instead of other tasks.

As for the comment on the 12-pin Pmod port being limiting with only 8 data lines, I am curious as to your thoughts on what Digilent could do instead. I'm imagining four different options if I was looking at something like the Nexys Video (or realistically any Digilent board embedded display or not), but maybe there is a fifth option to consider.

- Use a bigger FPGA/SoC/whatever with more IO pins available. Drawback would be higher cost of the (presumably) more expensive chip and physically larger board.
- Take away some of the generic IO pins for random use and put them towards a display. Drawback is this appears (at least from my memory) to conflict with what you have requested before of having a large set of IO available for (high speed and properly impedance matched differential) pins. More board variants would also probably need to be made as not everybody is interested in having a display (but maybe that's not true?).
- Take away some other IO hungry feature like Ethernet.
- Use something that has it's own integrated processor that you send pre-defined commands to (like the late Pmod MTDS) that then uses a lot more IO pins to control the display. Drawback would be that firmware would need to be supported and also not have (soft) embedded processor only support that struggles with Xilinx version updates.

Thanks,
JColvin

[zygot]

12 hours ago, JColvin said:

I do not know when the Applications and Systems Engineers will be given the green light to focus on this product instead of other tasks

Well, while this issue isn't being addressed, you have bad code and example projects available for users to try out thinking that there's not harm in using the code. Worse, they are trying to follow warnings that they need to shut down the demo properly to avoid damaging the display hardware. In fact, there is no way to shut down the demo properly and not harm the display according to the product reference manual. It's a bit disturbing that apparently this bothers me more than the managers at Digilent. At least post a warning on the appropriate web pages until the issue is fixed. For the vivado-library code there's no warning that some of the sources have compiled netlists for one FPGA family and that the IP is unusable with Digilent products based on a different family.

12 hours ago, JColvin said:

As for the comment on the 12-pin Pmod port being limiting with only 8 data lines, I am curious as to your thoughts on what Digilent could do instead.

Well this is fairly easy to answer. I've posted suggestions and requrests about this numerous times in the past. Let's see what I can remember off the top of my head:

The so-called differential PMODs should have been on or two wider ports with pins routed to IO banks with an appropriate Vccio. Replacing 2 PMODs that can't support differential signalling frees up 16 GPIO.  That's 8 differential pairs one of which could be a clock-in.  These could be routed on the PCB to be length matches but not on the same PCB layer to support 16 single-ended signals alternatively. There's no consistency among PMODs with clock-in availability. In any case I'm pretty sure that none of your FPGA boards are using every available IO pin. The ways in which a usable interface for user expansion could have been done are almost endless.

There just aren't many PMOD boards that need 2 GND and VCC pins. A 12-pin header with 10 GPIO would, itself, be a fantastic improvement over the current one with 8 GPIO. Really, a 2x20 header with 1 Vcc, 1 GND, and 18 GPIO would be great.

There are a number of cheap color OLED displays available that Digilent FPGA board users could experiment with that would only require 11  interface signals.

This just isn't an engineering problem; it's a marketing problem. How many users purchased Digilent FPGA boards over the years hoping to use advertised features only to discover that in practice the boards didn't support what was being suggested? For now I choose to pass on answering that question. Frankly, I think that Digilent just doesn't care about what their customers want in terms of functionality.

I suspect that all of this speculation is moot as Digilent hasn't produced a new FPGA product that didn't have a ZYNQ or MPU in years.

 

Edited November 22, 2022 by zygot

[zygot]

More3 on the topic of user IO.

I'm looking at a Spartan 3A Starter board ( 2006 ). XC3S700A-4FGG484C device:
Sdram
10/100 Ethernet
40 GPIO on a FX2 connector ( Digilent even sold FX2 bread boards for user development and experimnetation )
3 6-pin PMOD headers
1 ADC header
1 DAC header
2 RS-232 UARTs
NOR FLASH
2 configuration FLASH devices
2 2x16 headers supporting 5 differential inputs, 5 differential outputs, 1 differential clk-in, 1 differential clk-out

The Series 7 devices deserve as much. So, some of the cheaper Digilent FPGA boards use cheaper parts with fewer pins. I don't think that this is the issue. It's more about what you want to provide the user in terms of utility.

I don't have a problem with the PMOD ecosystem, not even the 12-pin PMODs. But these headers are just too limiting. Here it is almost 20 years later and Digilent doesn't off one FPGA board with anything close to the usability of this board for anyone wanting to experiment with all of the device IO capability. There's been plenty of user questions demonstrating that there's a good market for anyone willing to supply good FPGA development platforms at a reasonable price. Doesn't Digilent like making money?

[robfinch]

Thanks for the heads-up on the OLED display. I am looking forward to an updated OLED core. I have not worried about the power cycling and been using FPGA for about six years so far. The OLED still works; but I have not used it for every project. I find the OLED is too small to read at a distance. I have the FPGA board on a table about 10 feet from my workstation. I use the HDMI port and a monitor to get a readable display. It would be better to have the OLED display hooked up with a longer cable and that likely means some sort of serial interface.

I find the PMODs work okay for me. I use the 12-bit ports as two independent six bit ports sometimes. They are not designed to be high-speed device I/O. Since they are generally not connected to high-speed I/O perhaps a pmod expander port based on shift registers could be useful. A couple of PMODs on my wish-list are a source of random values, and a color composite output module.

[zygot]

1 hour ago, robfinch said:

I find the PMODs work okay for me

Sometimes a low speed port with only 8 pins works out for me too. Mode often than not, however, I need more pins. Put s couple of 12-pin PMODs on you boards; just don't limit the utility of an FPGA board hoping to sell add-on PMOD boards. Better yet make a interface standard that let's you design and sell higher performance PMODs, or if you care about your customers, make  boards that let your users take full advantage of the FPGA devices that they are paying for. I don't think that I'm the only person that this makes sense to.

[asmi]

On 11/22/2022 at 10:54 AM, zygot said:

I don't have a problem with the PMOD ecosystem, not even the 12-pin PMODs. But these headers are just too limiting. Here it is almost 20 years later and Digilent doesn't off one FPGA board with anything close to the usability of this board for anyone wanting to experiment with all of the device IO capability. There's been plenty of user questions demonstrating that there's a good market for anyone willing to supply good FPGA development platforms at a reasonable price. Doesn't Digilent like making money?

I thought SYZYGY is supposed to address this exact issue. I can be powered by any VCCIO (so you can take advantage of any IO standard supported by FPGA) and gives enough IO for a lot of applications, and it uses proper high-speed connector so doing high-speed LVDS should not be a problem. Creating a LVDS SYZYGY module seems like a fairly trivial task as it only requires 4 or 5 matched differential pairs. Standard SYZYGY connector port provides for at least 8 differential pairs, so that's more than enough.

It will be a little tight for standard RGB interface, but in can be done (my board's RGB interface connector uses 33 lines, but it also includes connection for a touch panel). Some RGB panels allow for using 6 bits per color (as opposed to 8 bits), that should allow to fit it comfortably even with touch panel connections.

Also SYZYGY standard allows for a double-width pods which connects to 2 SYZYGY ports on a carrier, but I'm not sure if there are any carries which implement that feature yet.

Finally, there Samtec also makes cables for these connectors, so it should be possible to create a simple pod which would bridge two SYZYGY connectors with a cable (you will need a small pod with connectors to allow both carriers to configure Vccio and to recognize that pod is actually there), if you want to play with FPGA-to-FPGA high-speed connections.

[zygot]

2 hours ago, asmi said:

I thought SYZYGY is supposed to address this exact issue.

SYZYGY provides what is supposed to be a "plug and play" industry standard that supports all of modern FPGA IO features. I like the effort and use SYZYGY ports and pods where they are available. A problem with SYZYGY for students and hobbyists or even small companies wanting to design a custom SYZYGY pod is that the connectors are not easy to layout using free tools on boards with 2 signal layers.  The standard also requires uC controller to request supply voltages. This doesn't have to be that complicated.

I've done 500+ MHz differential on 2x20 .1" headers. Connectors that are suitable for 12 GHz signals just aren't a requirement for the vast majority of users who just want to something using an FPGA that can't be supported by overly constrained low-speed headers with only 8 signals. designing an FPGA board with sensible IO headers that have a mix of differential signalling, pins connected to clock capable input pins, and 1 pin for power out plus a sensible number of ground pins isn't hard to do. Most of Digilent's customers who just want to have an FPGA platform that can be used for any custom project don't need wide GHz LVDS busses or 300 MHz single-ended IO to get their project completed. I realize that you don't have a problem with creating custom LVDS SYZYGY pods but I doubt that this is the case for most students or experimenters who just want to complete a project with very limited time and budget. I frequently make custom PCB boards and, as we both know, it's not cheap to buy 1 or 2 boards, populated or not, of any design.

Digilent makes 2 boards with FMC connectors. These are great and I use them. The problems with FMC is that, even though in theory it could be "plug and play" no one actually makes an FPGA board that takes advantage of it's capabilities because VITA isn't a complete programmable logic standard. There are just not many SYZYGY pods out there. There are fewer FMC mezzanine cards for FPGA use. SYZYGY pods are relatively expensive and FMC mezzanine cards, for the most part are even more expensive. And, after spending a lot of money for one you don't necessarily get exactly want you need for a particular project. Worse, for FMC is that not all mezzanine cards with LVDS are compatible with Digilent FPGA boards that have FMC connectors.

My point is that sure, for a lot of money perhaps someone makes a SYZYGY or FMC mezzanine card that is close to meeting your project needs. Very few people need or want to spend their money on high speed add-on cards. All they want or need is sensibly designed FPGA platforms that let them connect to "whatever" with no ridiculous limitations. It's not that Digilent doesn't know how to do this, as I pointed out with the Spartan 3A Starter Kit reference. Sensible design isn't magic. The whole point of programmable logic is that you can do almost anything that you want using logic. Inexpensive FPGA boards should be available that let users do anything that the devices are capable of. 

This post veered into the PMOD problem because, with a header having a reasonable number of IO signal pins  there are a myriad of cheap color display panels that are available for development purposes and Digilent has chosen to make boards that can't do something this simple. They do make and sell exactly one color display PMOD that has absolutely no FPGA support, probably because an SPI interface on a color display panel with an interesting number of pixels is too slow to be useful to anyone. This, of course, is just one of the things that Digilent can't make using 12-pin PMODs because technology has advanced beyond a 30 year old standard meant to sell to educational labs. 

Why should anyone have to use Quartus so that they can do useful, cheap, FPGA projects using a Cyclone IV on a platform like the Terasic DE0 Nano?

Edited November 28, 2022 by zygot

[asmi]

17 hours ago, zygot said:

A problem with SYZYGY for students and hobbyists or even small companies wanting to design a custom SYZYGY pod is that the connectors are not easy to layout using free tools on boards with 2 signal layers.

Really? What exactly is not easy?

17 hours ago, zygot said:

The standard also requires uC controller to request supply voltages.

That is also a trivial issue, because OpalKelly provides a firmware for that, so you only need to adjust a few parameters.

17 hours ago, zygot said:

I've done 500+ MHz differential on 2x20 .1" headers.

I've done a lot of stupid things in my life. It doesn't mean others should repeat it. Also modern ICs have much sharper fronts, so such crap connectors is a much more serious problem for them.

17 hours ago, zygot said:

Most of Digilent's customers who just want to have an FPGA platform that can be used for any custom project don't need wide GHz LVDS busses or 300 MHz single-ended IO to get their project completed.

And here you contradict yourself - didn't you ask for ability to take advantage of all IO functions that FPGAs offer? Well guess what - 1.25 Gbps LVDS lines is also one of such functions. If you don't need it, it doesn't mean others don't need it too.

17 hours ago, zygot said:

I frequently make custom PCB boards and, as we both know, it's not cheap to buy 1 or 2 boards, populated or not, of any design.

If you would've actually made a custom PCB in the last year or so you'd know that what you've said is utter nonsense. Nowadays you can get five 10x10 cm 4 layer PCBs for under $30 delivered to you in about a week since placing an order. If that is not cheap for you, then I don't know what is.

---

I wonder if you will ever learn a virtue of brevity.

Edited November 29, 2022 by asmi

[BMiller]

10 minutes ago, asmi said:

I wonder if you will ever learn a virtue of brewity.

Some of us can't handle the high glycemic index beverages...

[asmi]

21 minutes ago, BMiller said:

Some of us can't handle the high glycemic index beverages...

Thanks, fixed it!

[zygot]

@asmi, I have no problem with people expressing counter viewpoints. But... and I'm sure that you will take this the wrong way, I don't think that you represent the typical user that my musings on this topic refer to. That's just my opinion, having read countless posts to Digilent's Forum over the years. When you do it all day every day it's expected that you've gotten pretty skilled and efficient at using layout tools, finding reliable pcb board fabricators etc. For most people who just want to use an FPGA to do more than purchase more boards, with limited time and budget, and no experience designing board level designs, I'm pretty sure that this isn't so trivial as you make it out to be.  I do detect that the tone of your criticism suggests that your thoughts are more about something other than the points that I'm trying to make. Fine, don't mind making someone else's day even if it appears to be at my expense. Was this brewittier ?

 

Edited November 29, 2022 by zygot

[asmi]

2 hours ago, zygot said:

@asmi, I have no problem with people expressing counter viewpoints. But... and I'm sure that you will take this the wrong way, I don't think that you represent the typical user that my musings on this topic refer to. That's just my opinion, having read countless posts to Digilent's Forum over the years. When you do it all day every day it's expected that you've gotten pretty skilled and efficient at using layout tools, finding reliable pcb board fabricators etc. For most people who just want to use an FPGA to do more than purchase more boards, with limited time and budget, and no experience designing board level designs, I'm pretty sure that this isn't so trivial as you make it out to be.  I do detect that the tone of your criticism suggests that your thoughts are more about something other than the points that I'm trying to make. Fine, don't mind making someone else's day even if it appears to be at my expense. Was this brewittier ?

 

I suspect most people who actually buy FPGA devboards (especially the more advanced/expensive ones who have SYZYGY/mezzanine connectors) do so to implement their projects which ultimately end up with custom PCBs. There isn't that many who buys expensive boards just for fun. With that in mind, it's absolutely not a problem to spin up a cheap PCB with custom components before designing a fully-custom boards. 

Edited November 29, 2022 by asmi

[zygot]

1 hour ago, asmi said:

There isn't that many who buys expensive boards just for fun.

Perhaps, perhaps not. It depends on what they want to do. The Digilent FPGA boards with HDMI or mDP video tend to be expensive but that doesn't have to be the case as the Numato Labs Mimas A7 makes clear. From what I gather, what you've been trying to say is that making cheap FPGA boards with lots if usable IO including LVDS is a pretty simple affair. So, aside from the snarky suggestions that I don't know what I'm talking about, I take it that you basically agree with my premise that there's no good reason for Digilent not offering  a cheap (<$300) smallish Artix board not being suitable for easy connections to a wide variety of custom applications that might need an add-on board. Digilent only make the one Eclypse Z7 board with more than one ZYZYGY port; and that was probably meant as a way to help pay for the AD3000 series instruments more than as a product. As a conterpoint Opal Kelly's Brain-1 with a smaller Z7014s has 3 standard pods and 1 transceiver pod and sold for a lot less. 

Sometimes accessible transceivers will sell an expensive board, or a higher-end FPGA like the Genesys2.

The Terasic DE0 Nano was, before Cyclone IV devices became expensive. a $59 board with 72 IO on 2 2x20 headers plus a few more on a smaller header. I've dedicated 4 of them as components in useful instruments that have been in use for years. Digilent simply doesn't have a suitable alternative to this board, even at it's current $108 price.

I'm suggesting that this is a missed opportunity for Digilent.

Edited November 29, 2022 by zygot

[zygot]

On 8/23/2023 at 9:32 AM, Ionut said:

The Nexys Video OLED Demo and the ZedBoard OLED Demo have been reviewed and the OLED turn on and turn off sequences have been updated.

Well, I suppose that it's nice that someone got around to fixing this.

I downloaded the Nexys-Video-OLED-2022..1-2 "project source" using the link you provided. Of course it's just an empty archive except for empty folders and a README file about how to get the GIT. Why you you bother providing links to empty zip files?

I won't bother getting the git sources as I assume that the format is the same as the earlier Digilent vivado-library IP and includes a netlist instead of actual source code. Also, I don't use MicroBlaze.

[JColvin]

Hi @zygot,

You'll want to download the .xpr.zip rather than the Source Code (zip), as per the Using the Latest Release dropdown in the guide that Ionut linked to here: https://digilent.com/reference/programmable-logic/nexys-video/demos/oled#download_and_usage_instructions. You'll find all of the materials you're looking for in the usual folder (hw->hw.srcs->sources_1->imports->src->hdl).

Thanks,
JColvin

[zygot]

16 minutes ago, JColvin said:

You'll want to download the .xpr.zip rather than the Source Code (zip), as per the Using the Latest Release dropdown

In my browser, it's not obvious that there is even a dropdown under the Using the Latest Release part of the HTML page ( it's not visible by default ). But this doesn't answer the question about why there is an obvious link to downloading a "source code zip file" which is empty. This is not only confusing ( no one expects to download a source code archive that's empty ) and very irritating.

It would've been nice if the IP included the simulation testbench, assuming that one was used to verify the design.

As a general impression, the way that Digilent releases source code has gotten overly complicated for the user and not particularly friendly or easy to track down all of the requirements, instructions, information about what's included, etc. etc.; it's unnecessarily an exercise in frustration to do something that should be straight-forward.

Does anyone at Digilent bother to take the time to experience what the customer experiences and think,"Great!"?

Edited August 24, 2023 by zygot

[Ionut]

Hi,

The OLED turn on and turn off sequences for all the above mentioned boards (Nexys Video, ZedBoard, PmodOLED) have been verified in hardware and all the updates are based on that.

Best Regards.

[zygot]

On 8/25/2023 at 3:15 AM, Ionut said:

The OLED turn on and turn off sequences for all the above mentioned boards (Nexys Video, ZedBoard, PmodOLED) have been verified in hardware and all the updates are based on that.

Not to be offensive, but "verified on hardware" as the only verification hurdle that a company providing HDL sources as support for their products would find to be acceptable is disappointing to say the least. That's the biggest reason why the original code didn't work.