UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Adventurer
Adventurer
8,203 Views
Registered: ‎01-13-2012

Help understanding chipscope output f Virtex5 ddr2

Hi,

 

I am working with a DDR2 controller generated by MIG for a virtex5 board. I have a testbench that performs read and write operations. I use chipscope to probe some signals to look at the latency of these operations. Below is a snapshot of a waverform from chipscope.

 

chipscope-capture.PNG

 

I am reading from address 0x2000000 (app_af_cmd = 1, app_af_wren = 1). From the application note (http://www.xilinx.com/support/documentation/application_notes/xapp858.pdf) the read latency is calculated as the difference between the deassert of app_af_wren and rd_data_valid signal. Here, I am calculating the latency as the difference between the deassert of 0x200000 on app_af_addr (cycle 309) and assertion of rd_data_valid signal (311). Therefore, the latency is 2 cycles. Note that the clock for the chipscope ILA is driven by the DDR2 module clock signal. I do not understand the 2 cycle latency. The read latency to my understanding is a sum of timing contraints. The smallest timing constraint is 4 cycles (CAS latency). So, I would assume the latency would have to be atleast 4 cycles. Also, there is a preceeding write operation. This would mean the read to 0x200000 would have to incur a bus direction reversal delay. However, I don't see that happening. Are my observations correct? Any suggestions on this would be useful. Thanks

 

 

 

Tags (2)
0 Kudos
3 Replies
Instructor
Instructor
8,171 Views
Registered: ‎08-14-2007

Re: Help understanding chipscope output f Virtex5 ddr2

From your waveform it looks like you are stacking up a large number of read commands.  If this is not the first time you've issued a read command, it's likely that you are seeing the data returned from a previously issued read.  It would also help to show the app_af_afull and app_wdf_afull signals in the waveform view to make sure you see when commands are actually being accepted.

-- Gabor
0 Kudos
Adventurer
Adventurer
8,160 Views
Registered: ‎01-13-2012

Re: Help understanding chipscope output f Virtex5 ddr2

Thanks for the response. I added the app_af_afull and app_wdf_afull signals to the waveform. I don't see the adrress fifo being full (i.e app_af_afull is not asserted). So, I am assuming that the addresses being sent out is indeed being accepted. I have attached the waveform in this post. I wonder if it is possible that the rd_data_fifo_out value is being forwarded from the write data fifo? This is because I am alternating reads and writes to the same two addresses. Also, the ras and cas commands show that the cas signal is asserted (cas_n = 0) so there is some column access happening.

 

chipscope-capture.PNG

0 Kudos
Instructor
Instructor
8,127 Views
Registered: ‎08-14-2007

Re: Help understanding chipscope output f Virtex5 ddr2

I guess I'm a little unclear on what you're trying to do here.  It looks like you're writing the same address 4 times then going to another address 4 times, and looping back to the original address.  Similarly it looks like you're reading the same address 4 times, etc.  That is, unless you don't have all of the address bits showing in your ChipScope trace.  When operating in a loop like this, it's hard to figure out the latency because when you trigger after the loop has been running for some time, there is no clear cause and effect between read commands and rd_data_valid.  i.e. is the rd_data_valid indicating the completion of the read command from this loop iteration?  Or perhaps the previous loop iteration or even the one before that.  It would be easier to see if you hold off the activity for some time, and then trigger when the activity resumes so you don't have any previous transaction in the pipeline.

-- Gabor
0 Kudos