08-26-2016 06:56 AM
I have built a DDR3 using the MIG software in Vivado 2015.3.
The user interface is 512 bits wide and the burst length is 8.
I have written a bit of test code that writes addresses from 0 to 1024, incrementing by 8 each time, (because of the burst size).
This is written by a process that deals with the command interface. It will hold the address if app_rdy = 0, otherwise it will increment the address on each clock until the maximum value has been reached. The app_en is held high whatever, until all commands are sent.
Another process deals with the write interface, and sets a new data bus value each clock, unless app_wdf_rdy is 0, in which case it will hold the data until it is 1. Both app_wdf_wren and app_wdf_end are held high whatever, until all data is sent.
After a time, the command and write interfaces will be complete.
I then request a read from the command interface, setting an address from 0 to 1024, incrementing each clock unless app_rdy is low, in which case we hold the address. app_en is held high throughout until this has been completed.
My concern is the synchronization between the command and the write interface. I'm hoping that this is taken care of in the core. However, when I perform the burst read, incorrect data is often given at the start from when app_rd_data_valid is set high by the core. It appears to be correct after a number of clock cycles, but I feel that I am not driving the user interface correctly.
I write one write command for every write. However, because of the app_rdy and app_wdf_rdy signals going low independently, I have to keep the commands and writes separate. I am concerned about the 2 clock rule in that I could perform a write command with an address, but the app_wdf_rdy could be low for over 2 clocks before the data for that address is written into the write fifo.
I am assuming that the addr is the required address in DDR which has to be increased by 8 each time as we are doing a burst of 8.
Both my processes wait until the Calibration Complete before starting.
I don't always get incorrect data back. I ran 4 tests successfully back to back, but it then failed on the 5th.
I also tried to combine the processes doing a more inefficient write. It would check to see that app_rdy and app_wdf_rdy were high before setting the command and write bus enables app_en and app_wdf_wren/app_wdf_end simultaneously. However, I found that when I looked at my simulation, app_rdy dropped straight away when I set the enables, but app_wdf_rdy stayed high, so I went back to the separate processes.
I'm thinking about going to the AXI interface build but would rather get this working. My waveforms appear to be similar to the example Traffic generator, although with different data. Am I missing something?
Many thanks in advance for any kind of help.
08-28-2016 10:24 AM
08-29-2016 06:13 AM
You can operate command and write data interfaces independently.
Also the two clock cycles applies only to non back-to-back write commands.
app_wdf_rdy goes low when the write data fifo is full. app_rdy goes low for reasons mentioned in page-94 of http://www.xilinx.com/support/documentation/ip_documentation/mig_7series/v4_0/ug586_7Series_MIS.pdf