Using DDR as a Video Frame Buffer

[zygot]

There are some nice tutorials available for anyone wanting to do FPGA based video using an HDL. Most of what I've come across, for HDMI at least, is based on work that Mike Field has published. None of them use external memory as a video frame buffer. This tutorial demo project aims to change that. Enjoy. Thanks Mike.

I've added a demo for the Genesys2 that implements a True Color 32-bit RGBA video frame buffer in DDR for 24-bit RGB HDMI displays. It's the obvious extension of the Nexys Video 8-bit indexed color demo.

 

NexysVideo_Demo_R1.zip

 

Genesys2VideoDemo_R1.zip

Edited April 6, 2023 by zygot

[zygot]

Haven't figured out how to refresh posts to indicate that new content has been added, hence this post.

If you were interested in the Nexys Video demo, you should find the Genesys2 even more interesting as we go from 8-bit indexed color to 32-bit RGBA in our DDR video frame buffer.

[DBanks60]

Have you tried your Genesys2VideoDemo_R1 with Vivado 2023.1?

[zygot]

@DBanks60

No, I haven't installed Vivado 2023.1. The demo tried to avoid version issues by providing commentary about how to re-create the IP in whatever version of the tools anyone might be using. Occasionally, Vivado makes changes that thwart even this approach.

Have you encountered a problem building the project in Vivado 2023.1? The MIG IP, in my experience, can be difficult depending on what version of the tools you are using. Specifying the target as a Genesys2 in your project settings instead of using the device product number is, in my experience, a good way to get all kinds of IO constraint artifacts that cause problems and have to be manually corrected. I've stopped using the board files many versions of Vivado ago. Be aware that older versions of the Digilent master constraints files have numerous errors. The schematic is golden as far as I can tell. I'm in the habit of checking the constraints against the schematic whenever I use pin for the first time.

[edit] The main reason why I don't use current versions of Vivado for Genesys2 projects is because my device license isn't supported by them.... I still use a LOT of vendor tool versions, on way too many PCs, for one reason or another. Sigh....

Edited July 25, 2023 by zygot

[DBanks60]

2 hours ago, zygot said:

@DBanks60

No, I haven't installed Vivado 2023.1. The demo tried to avoid version issues by providing commentary about how to re-create the IP in whatever version of the tools anyone might be using. Occasionally, Vivado makes changes that thwart even this approach.

Have you encountered a problem building the project in Vivado 2023.1? The MIG IP, in my experience, can be difficult depending on what version of the tools you are using. Specifying the target as a Genesys2 in your project settings instead of using the device product number is, in my experience, a good way to get all kinds of IO constraint artifacts that cause problems and have to be manually corrected. I've stopped using the board files many versions of Vivado ago. Be aware that older versions of the Digilent master constraints files have numerous errors. The schematic is golden as far as I can tell. I'm in the habit of checking the constraints against the schematic whenever I use pin for the first time.

[edit] The main reason why I don't use current versions of Vivado for Genesys2 projects is because my device license isn't supported by them.... I still use a LOT of vendor tool versions, on way too many PCs, for one reason or another. Sigh....

Thanks. No problems yet--I have not started my project, since I don't have a Genesys 2 board yet. Once it have the board, and the IP voucher for Vivado ML Enterprise, I'll get started. Your code is very well commented, thanks for that!

[zygot]

1 hour ago, DBanks60 said:

Once it have the board, and the IP voucher for Vivado ML Enterprise, I'll get started.

Don't hesitate to ask questions if something unexpected pops up. The Genesys2 has been a very useful platform for me.

[DBanks60]

Great project!

Please clarify some things for me concerning the readme file you provided. (1) I need to compile VideoDemo.cpp--there is no executable for this until I do, yes? (2) Once I have that executable, I can proceed with adding the Digilent ADEPT SDK dpti and dmgr libraries and headers to the project, implement the project, create the bitstream and program, and then execute the windows command line with the board connected to see the turkey image, right?

In other words, the parts about using GIMP and a hex editor, you already did, correct?

[zygot]

16 hours ago, DBanks60 said:

In other words, the parts about using GIMP and a hex editor, you already did, correct?

Yes, all of the picture cropping and data manipulation has been incorporated into the header file that's been provided. The initial grid display is done in software. You don't need to install GIMP or a hex editor to complete the project.

Thanks for not mentioning all of the typos ( I still find more every time I re-read the documentation).

So, once you have a bitstream, all you need to do is install the Adept SDK and create a project to turn the software sources into ( for Windows ) a x64 executable. The software sources have a few display content headers for different display modes.

[DBanks60]

Thanks for all of your help-I have it working on a Genesys2. [I edited and erased my questions]

Edited August 4, 2023 by DBanks60
dumb questions

[zygot]

3 hours ago, DBanks60 said:

I have it working on a Genesys2

Great! Thanks for the feedback. Hopefully, you can see the basic functionality as a starting point for more interesting projects.

[DBanks60]

On 8/4/2023 at 6:37 PM, zygot said:

Great! Thanks for the feedback. Hopefully, you can see the basic functionality as a starting point for more interesting projects.

Would you have any advice to offer on how to replace your dpti module with dvi2rgb to implement a hardware HDMI-in source solution?

[zygot]

On 8/29/2023 at 8:30 AM, DBanks60 said:

Would you have any advice to offer on how to replace your dpti module with dvi2rgb to implement a hardware HDMI-in source solution?

I'm not sure what exactly that you have in mind. If I wanted to capture/manipulate/display a live video source, using the Genesys2 HDMI inputs and outputs, I'd likely have a very different architecture for such a project. The architecture would be highly dependent on what I wanted to accomplish. Simultaneously writing and reading video line buffers in external memory would require a faster MiG controller than the one that I use in the Nexys Video or Genesy2 demos in this tutorial; assuming that I needed external memory.

Both the Nexys Video and Genesys2 ( and the Mimas A7 ) can capture video using the HDMI input port.

I haven't used Digilent's dvi2rgb or rgb2dvi IP. As an alternative you might browse Mike Field's archive here: https://github.com/hamsternz

Be aware of content protection features in HDMI transport.

[digiuser1970]

What I am missing is a mig project file. I would expect the "mig_a.prj" and / or information how to configure the MIG to get the design complete. (?)

[zygot]

One would think that a valid MIG .prj file for a particular platform, like the Genesys2, would be a suitable source file. The MIG Wizard let's your try and import one. The problem is that I've never had success doing this. Part of the problem is that constraint syntax keep changing with occasional Vivado releases. In fact I've had Vivado add constraints to my user managed constraints file that it then decides to ignore because of syntax errors. Unfortunately the MIG hasn't gotten much love over the years. No updates to the IP wizard. Same old bugs in every new Vivado version plus a few new ones.

One way to handle Vivado bugs is to manually keep track of Ip settings. This is what I did for the Genesys2 Video demo. Whenever I want to add DDR to new project I just create a new project and replicate the setting. If you read the commentary in my video demo sources you can find all of the relevant settings that I used to create Vivado IP. Another, probably more appropriate, way to to use the MIG is to create a tcl script to create your MIG IP for a board. Neither of these are totally foolproof s there are bugs that are consistent through all of the Vivado versions; like trying to edit a MIG project file using the wzard and having the GUI change settings from what you initially made back to default settings. It's all a pain in the ars and the Vivado coder have no interest in fixing it. another problem unique to the MIG IP is that you could never modify the IP; you can only create a new set of IP product files. In my experience Vivado gets 'confused with having multiple MIG .prj files and generated IP products.

Digilent usually supplies a ucf file for the MIG in setting up the location assignments. Often these have to be modified due to changes in a tool version. For the video demos I had to create a modified ucf file, which I included in the demo sources.

n my opinion Vivado is trying to depreciate the HDL design flow and force users to use the IPI GUI and high resource IP that come with it. Also, managing source files has gotten harder, though it's not as bad as it is for Intel Quartus users. In ISE and early versions of Vivado one could open a generated IP and change the name and produce a variation of it. No more. As the years go by I find using Vivado less and less friendly to work with. Edited February 25 by zygot