04-18-2017 06:48 AM - edited 04-18-2017 06:56 AM
Using MIG 4.0, Vivado 2016.4 I have an issue in simulation and also in hardware. Sometimes when attempting to write to the DDR via the UI I present the data, address, command etc but the data actually written out on the dq pins is that of a previous transaction. I've attached a screen shot from modelsim to try to highlight the issue.
I'm running in 4:1 mode but only using the bottom 256 bits of the app_wdf_data bus at the moment so I mask off the top 256 bits. The data I am writing is a test pattern and as shown in the waveform is 0xe010e010.......but what gets written out on the ddr3_dq pins is 0xd010d010........ which happens to be the data pattern of the previous write transaction. Any idea why this is happening?
04-24-2017 03:16 AM - edited 04-24-2017 03:19 AM
It looks like the number of data words written till 189220ns (this is where you are not seeing b010 data) are more than number of write commands. See the search results below in Questa. This is the reason for old data being written at current address. I noticed some spikes on app_en,app_wdf_wren signals, check if this is the reason for the discrepancy.
04-18-2017 08:34 AM
Are you saying the previous write data gets written to the DDR3 memory twice? The MIG user interface has command and data FIFOs. If you're seeing the same data twice, it's possible that the data was pushed on the data FIFO twice when you sent the previous command. The data FIFO is written whenever you assert app_wdf_wren while app_wdf_ready is true. It doesn't depend on app_ready. That only affects the command FIFO. I would look back at the prior transaction to see if you can find an issue there.
On the other hand, if you don't know for sure that the same data was written twice, what you're seeing could simply be the fact that the command queue is backed up and the transaction at the memory is lagging behind the transaction at the user interface.
04-18-2017 08:49 AM
Yes that is the effect I am seeing, it looks like the previous data is written twice. I've had some issues previously with Xilinx IP and TCQ delays and you've just jogged my memory about that so I will take a closer look and see if it could be related to that.
Yes I'm aware of the command and data FIFOs, i'm just assigning the write command and write data at the same time. I'm by no means pushing the interface hard. I have to read a location, update the data and write it back so I only have bursts of 1!
04-19-2017 05:30 AM
Still no joy. I'm setting the commands and write data as expected for a single clock cycle. Most of the time the write data is written correctly but occasionally I see this problem where the previous data is written rather than the new data.
04-20-2017 02:03 AM
Having used Xilinx devices for the majority of my career and occasionally using the Webcase to get support about specific issues I was hoping to raise a case regarding this MIG issue. However, after a bit of going round in circles on the support part of the Xilinx site and doing a search in the forum it looks like that isn't an option any more. So how do I get support for this issue apart from relying on the kindness of other forum users who may be able to help?
04-20-2017 08:00 AM
You could continue to post here, and hope someone from Xilinx, possibly @vemulad , answers you. Your other best bet is to contact your FAE, who is typically connected with the distributor for your region (Avnet for most of the US).
04-21-2017 12:34 AM
Yes I think that's the best I can do by the looks of things. I'll create a .wlf from modelsim and upload so at least someone has a chance of taking a closer look at how i'm using the UI and what's happening on the DDR side.
04-21-2017 12:36 AM - edited 04-21-2017 12:37 AM
Please upload the WLF, I will take a look and get back to you.
Have you tried running simulation on IP example design? Does that show this issue too?
04-21-2017 03:32 AM - edited 04-21-2017 04:28 AM
Thanks for responding. I've attached the WLF file that includes the UI and the DDR interface. Drop down through the hierarchy and you'll find inst_mig_ui which is what we're interested in looking at.
I've also attached some screen grabs to explain what's going on and where I first see the issue. On the waveform.png I have circled 3 events:
1) After the DDR has calibrated we check the DDR by writing PRBS data to the entire DDR, read it back and verify it's as expected and then write some blanking data back. In simulation this sequence is shortened significantly to save simulation run time. This sequence works fine on the hardware. If it failed, we wouldn't be able to access the DDR at all.
Then you will see several groups of accesses to the DDR. This is where we are reading a 512bit word from the DDR, updating the data and writing it back. This works fine up until 2)
3) This is where the data written previously is read out.
waveform_zoom.png zooms in on point 2) from the waveform.png. This is where we can see I perform a write of data 0xb010b010..... but what gets written to the DDR is 0xa010a010.......and I have no idea why.
Can you see anything that I may be doing wrong in terms of accessing the UI?
I've run the example design and it completes successfully.
04-23-2017 10:59 PM
Can you please upload the mig .XCI and .PRJ files?