Accessing DDR2 on Nexys 4 DDR

[JColvin]

A customer on our website asked the following question:

I'm a before graduation student and I'm studying FPGA design with Nexys4DDR board. I'm using vivado 2016.2 as a tool. I already have used Nexys2 board before. I'm trying to make a design that contains VGA and DDR2 SDRAM. For my design working, I must access DDR2 SDRAM from my computer directly. It was done by adept program of Digilent inc when I used Nexys2 borad. But now, using Nexys4 borad, I had my siturations changed totally. adept program can not access DDR2 SDRAM. There seems some other ways such as MIG or so. I should download datas from my computer to DDR2 SDRAM directly for my design working. 
Question1 : Can I download datas from my computer to DDR2 SDRAM?
Question2 : If can, How?

The response is below.

[JColvin]

Hello,

I have asked some of our applications engineers about this; they will get back to you here on the Forum.

Thanks,
JColvin

[sbobrowicz]

There is no Adept SDK data transfer interface on the Nexys4-DDR. On the Nexys2 the Adept SDK and Adept GUI (in windows) allowed you to transfer data to CellRAM, but that is not possible on the Nexys4-DDR. You will need to modify your design to either get data from your computer over USB-UART (max bitrate ~3 mbps) or Ethernet (max bitrate ~100 mbps). You can then stream this data into the DDR2 memory via the MIG component. If you do not need a lot of bandwidth into and out of the DDR2, you can use our SRAM2DDR interface to access the memory in an easier to implement way. It provides the same physical interface that the CellRAM use to have, but at a higher latency for accessing the memory.

[Sewonkim]

On 2016. 8. 30. at 1:47 AM, JColvin said:

Hello, JColvin.

I have asked some of our applications engineers about this; they will get back to you here on the Forum.

Thanks,
JColvin

Thank you. You friendy made my question get a good answer! For my poor English! I really appreciate your favor.

[Sewonkim]

On 2016. 8. 31. at 9:16 AM, sbobrowicz said:

There is no Adept SDK data transfer interface on the Nexys4-DDR. On the Nexys2 the Adept SDK and Adept GUI (in windows) allowed you to transfer data to CellRAM, but that is not possible on the Nexys4-DDR. You will need to modify your design to either get data from your computer over USB-UART (max bitrate ~3 mbps) or Ethernet (max bitrate ~100 mbps). You can then stream this data into the DDR2 memory via the MIG component. If you do not need a lot of bandwidth into and out of the DDR2, you can use our SRAM2DDR interface to access the memory in an easier to implement way. It provides the same physical interface that the CellRAM use to have, but at a higher latency for accessing the memory.

Thank you, Mr.. sbobrowicz.

Your answer was greatly helpful. Now I can get closer to the design solution. I appreciate your apply angain. However, I can not fine the subjective way to solve my problem cause of my short experience in spite of your nice guidance. I think UART might be the proper way for me. But I'm afraid of its low bit-rate. As you know, graphic data are quite huge. So, I really need your favor again. If you're okay, please help me again.

1. Can I get some documents or tutorials about the ways you mentioned?

2. How do you think about using micro SD memory card rather than transferring from my PC?

 

Thank you,

Sewon, Kim

[D@n]

Sewon,

It sounds like there's more that you have to do besides just getting data into your SDRAM.  Yes, the low bit-rate of a UART can be a problem.  You could compress the data going across the UART, and then decompress it on the other end ...?  I know I've tried this solution before.  I used a run-length encoded pixel stream.  It worked really well ... as long as the number of colors was limited.

The reason for the difference between the Nexys 2 and the Nexys 4 is specifically the SDRAM.  SDRAMs are made of capacitors, and the charge in a capacitor slowly drains over time.  What this means is that SDRAM cells will all turn to zeros if they are not properly fed every second.  That means that, to use SDRAM, you must have a controller that continually issues refresh commands to the SDRAM--usually via one refresh command every 7.8us or so.  While you could build something to load data into this SDRAM, if you then switched configurations, you would lose that data.  (That's why the ADEPT tools can't do it anymore ...)

So really, your problem is twofold: first, you need to load an image into the SDRAM, and then second you wish to do something with it ... I imagine you'd like to display it?  Because of the SDRAM constraints, one configuration will be required to do both loading and displaying. 

My personal recommendation as to how to accomplish this would be to create a data bus within your FPGA.  I like to use the wishbone bus, although many others here prefer Xilinx's AXI bus.  You would need a UART receiver.  There are many example implementations, although I use this one.  You would then need a component, such as this one, that took read from the UART, and wrote to the memory which would reside somewhere on that bus.  (You get to pick where you want to wire it up ...)  Since I want my interaction to be two-way, allowing a CPU to read from the FPGA bus as well as writing to it using a fairly simple and generic interface, this approach also needs a UART transmitter.  A second component would need to read from the memory and write to the display.  A third component will even be necessary to arbitrate between the two, so that only one of the two components drives the bus at any given time.

That's a lot of components already, and I haven't even gotten to the display yet! 

If you would rather use an SD card than a UART, solutions exist there as well.  You can try mine, although it only uses the SD card in its SPI mode.  Here's another one that claims to use the full SDIO protocol, although I've never had a chance to try it.  If you've never used an SD card, though, there's a lot of protocol that needs to be done to set it up before you can read from the card.  Once you've got the card set up to read from, then you may find yourself needing to parse through a FAT filesystem of some type.  I haven't gotten that far in my SD card implementation, so whereas I can read and write sectors, I cannot read and write files from the SD card.

So, if you wish to go the SD card route, you will need some kind of computer program driving your configuration, either from within the configuration or from the PC.  That program will need to set up the card, and then issue read commands to the card--possibly interpreting the filesystem along the way.  Once the card has been read, at least in my example, some piece of logic still needs to transfer the data that was read from the SD-card to your SDRAM memory.  My plan was to use a direct memory access (DMA) peripheral to a ZipCPU, but I'm sure that many others here would recommend the microBlaze CPU--something I have no experience with.  The difficult thing about a DMA peripheral to a computer is that ... you'll need yet another bus arbiter (or two), since you will now have at least four bus masters: your PC across the UART, your video display driver, and now the CPU which will need to read its instructions from memory, as well as your DMA peripheral.

Wow.  That's a lot of pieces.

The closest I have to a project that can do all of this is the xulalx25soc project.  Sadly, though, this project has a standard SDRAM memory, not a DDR2 SDRAM.  Hence, if you wished to copy and use that project (it's available under GPL), you'd still have to figure out how to access the DDR2 SDRAM.  That's not a trivial task.  Hence, you come back to the Xilinx's Memory Interface Generator (MIG) and the AXI bus.

I guess my point is ... there's a lot between here and there besides just writing to your RAM. 

Dan

[Sewonkim]

19 hours ago, D@n said:

Sewon,

It sounds like there's more that you have to do besides just getting data into your SDRAM.  Yes, the low bit-rate of a UART can be a problem.  You could compress the data going across the UART, and then decompress it on the other end ...?  I know I've tried this solution before.  I used a run-length encoded pixel stream.  It worked really well ... as long as the number of colors was limited.

The reason for the difference between the Nexys 2 and the Nexys 4 is specifically the SDRAM.  SDRAMs are made of capacitors, and the charge in a capacitor slowly drains over time.  What this means is that SDRAM cells will all turn to zeros if they are not properly fed every second.  That means that, to use SDRAM, you must have a controller that continually issues refresh commands to the SDRAM--usually via one refresh command every 7.8us or so.  While you could build something to load data into this SDRAM, if you then switched configurations, you would lose that data.  (That's why the ADEPT tools can't do it anymore ...)

So really, your problem is twofold: first, you need to load an image into the SDRAM, and then second you wish to do something with it ... I imagine you'd like to display it?  Because of the SDRAM constraints, one configuration will be required to do both loading and displaying. 

My personal recommendation as to how to accomplish this would be to create a data bus within your FPGA.  I like to use the wishbone bus, although many others here prefer Xilinx's AXI bus.  You would need a UART receiver.  There are many example implementations, although I use this one.  You would then need a component, such as this one, that took read from the UART, and wrote to the memory which would reside somewhere on that bus.  (You get to pick where you want to wire it up ...)  Since I want my interaction to be two-way, allowing a CPU to read from the FPGA bus as well as writing to it using a fairly simple and generic interface, this approach also needs a UART transmitter.  A second component would need to read from the memory and write to the display.  A third component will even be necessary to arbitrate between the two, so that only one of the two components drives the bus at any given time.

That's a lot of components already, and I haven't even gotten to the display yet! 

If you would rather use an SD card than a UART, solutions exist there as well.  You can try mine, although it only uses the SD card in its SPI mode.  Here's another one that claims to use the full SDIO protocol, although I've never had a chance to try it.  If you've never used an SD card, though, there's a lot of protocol that needs to be done to set it up before you can read from the card.  Once you've got the card set up to read from, then you may find yourself needing to parse through a FAT filesystem of some type.  I haven't gotten that far in my SD card implementation, so whereas I can read and write sectors, I cannot read and write files from the SD card.

So, if you wish to go the SD card route, you will need some kind of computer program driving your configuration, either from within the configuration or from the PC.  That program will need to set up the card, and then issue read commands to the card--possibly interpreting the filesystem along the way.  Once the card has been read, at least in my example, some piece of logic still needs to transfer the data that was read from the SD-card to your SDRAM memory.  My plan was to use a direct memory access (DMA) peripheral to a ZipCPU, but I'm sure that many others here would recommend the microBlaze CPU--something I have no experience with.  The difficult thing about a DMA peripheral to a computer is that ... you'll need yet another bus arbiter (or two), since you will now have at least four bus masters: your PC across the UART, your video display driver, and now the CPU which will need to read its instructions from memory, as well as your DMA peripheral.

Wow.  That's a lot of pieces.

The closest I have to a project that can do all of this is the xulalx25soc project.  Sadly, though, this project has a standard SDRAM memory, not a DDR2 SDRAM.  Hence, if you wished to copy and use that project (it's available under GPL), you'd still have to figure out how to access the DDR2 SDRAM.  That's not a trivial task.  Hence, you come back to the Xilinx's Memory Interface Generator (MIG) and the AXI bus.

I guess my point is ... there's a lot between here and there besides just writing to your RAM. 

Dan

Thank you, Dan.

I appreciate your favor. I'd like to study your whole words quite repeatedly. I think I can learn so many things from your answer!

Thank you for sharing your precious experiences and wording so sincerely. I'd like to consider and try ones you gave to me.

Bless you,

Sewon

 

[NewUser]

On 8/31/2016 at 8:16 AM, sbobrowicz said:

There is no Adept SDK data transfer interface on the Nexys4-DDR. On the Nexys2 the Adept SDK and Adept GUI (in windows) allowed you to transfer data to CellRAM, but that is not possible on the Nexys4-DDR. You will need to modify your design to either get data from your computer over USB-UART (max bitrate ~3 mbps) or Ethernet (max bitrate ~100 mbps). You can then stream this data into the DDR2 memory via the MIG component. If you do not need a lot of bandwidth into and out of the DDR2, you can use our SRAM2DDR interface to access the memory in an easier to implement way. It provides the same physical interface that the CellRAM use to have, but at a higher latency for accessing the memory.

Hi, I am a new user for digilent board, I also face a problem of external memory DDR2 SRAM. I currently working with a tutorial from the ARM university programme, however, the tutorial is based on Nexys 4 (cellRAM). 

In this project I try to use the MIG component provided and change the memory controller port in the tutorial to suit the MIG port [1] , however, the port MemDB ( in tutorial ) is inout port while the port in the MIG is ram_dq_i and ram_dq_o (which is separate port) so I connect it like the pic below and the error come out.

The next part of project will require the processor read the hex file inside the DDR2 SRAM [2]. 

 

Questions:

1) Is this correct to use MIG [1] ?

2) Is there any tutorial how to implement this MIG in project?

3) How to resolve the error? , add another MUX?

4) How do I put the hex file into the DDR2 SRAM [2] since the Adept can't use.

 

I am very sorry if I ask something sound silly, and please give me some guideline or any link that can help me. Thanks a lot. 

 

 

[jpeyron]

Hi,

Here is a tutorial that uses the MIG. You wont need to use the ethernet portion of the tutorial but this should help with the MIG instantiation. Also in the MIG wizard you can set it to use a file on start up.

Thank you,

Jon

[marablu]

Hi,

I have a similar question but before I ask it I should explain my code that is attached below. I have developed a Discrete Fourier Transform (DFT) algorithm on a NEXYS 4 DDR board using Vivado 2018.3. The code takes an external clock signal of 10 MHz and generates 100 MHz, 200 MHz, and 10 MHz clocks synchronous to the external clock input. The 200 MHz clock is used for DFT analysis. The generated 10 MHz clock is fed into the ADC of a signal detector which converts a captured signal into a 12 bit digital data that is in turn being read into the FPGA code through 12 digital input. The DFT algorithm calculates the amplitude of two harmonics of a desired frequency at 10 MHz rate and stores them into Ave_R1 and Ave_R2 values which are 16 bit integers. I have tested this algorithm and it works fine. (The 100 MHz clock is not being used now and I will finally omit that from the design).

Now,  I want to transfer the Ave_R1 and Ave_R2 values into a computer and fit an ellipse to the stored data and transfer the ellipse parameters back to the FPGA. The data should be stored at 10 MHz speed which makes it 320 Mb/s and I need to save it for about 2 seconds. Since the UART or the Ethernet port cannot transfer data at 320 Mb/s, I have to first store the data into the SDRAM and then transfer it to the PC. The ellipse parameters that should be stored back into the FPGA block RAM will be five integers of 64 bits. So the data transfer between the FPGA and the PC will happen just twice, i.e. write to PC and read ellipse values from the PC. I would like to trigger the data transfer from the FPGA to the SDRAM and then to the PC by a push button on the board. I need a signal to inform the FPGA that the ellipse parameters are transferred so that a process will use that signal to start. I would appreciate it if anyone could help me to figure this out because I have no idea about data transfer protocols and IPs.

P.S.

After getting this step done, I would like to store the code in the Q-SPI Flash memory of the board so that it reboots automatically. Would you please comment on this as well?

 

Kind Regards,

Mesut

DFT.txt

xdc.txt