11-21-2013 04:48 AM
Hello every one,
Can we give continuous app_cmd+app_addr for write or read processes (separately of course) without the any delay.
In my system, I want to give the continous write and read commands where number of write commands are from 512 to 2048(depending on circumstances) where as continous READ commands are from 400 to 800 (depending on circumstances). Note that write commands are give to consecute addresses for example : 0,8,16,24,32....
While the READ commands' addresses are not at the continous DDR3 locations, but based on the algorithm(skipping here now) for example 0, 512, 1024, 1536, 2048...
Hence is it possible. I have one very serious doubt. Plaese do comment on that.
1. The DDR3 I am using has 1K column A[9:0] hence for continous write of <1024, I do not need latency delays since only 1 ROW is opened. But for write of more than >1024 addresses, do I have to consider this (I am talking about MIG based design).
2. Similarly, for Read addresses, since the locations are not consecutive, do I need to give the addresses + commands (app_add + app_cmd + app_en) with some latencies.
waiting for reply
11-21-2013 05:41 AM
hello again every one
so I found one quite strange thing. while reading...It is like either data slips or something like that, i.e. the data 0x0000 appears to the rd_data_fall1 when it should not be. Hence all data is shifted by 1. Hence it does not also appear on app_rd_data as well (when app_rd_dval is HIGH)
Is there any way to solve or sort out this thing...
please see the image.
11-21-2013 05:55 AM - edited 11-21-2013 06:08 AM
Please have a look at the user interface addressing in the below AR and check if your Read address is aligning to the
burst boundaries and not interleaved address which can cause the data shift by address locatons..
As long as the app_rdy is high, you can issue either read or write commands and no need to wait on which address locations you are accessing,it can be adjacent or not adjacent addr locations in the DRAM.
At the user interface it is plane addressing as mentioned in the AR.
The Arbitration block in the Controller takes care of the row and column accessing and commands issuing to the DRAM
11-21-2013 06:33 AM - edited 11-21-2013 07:23 AM
Is this fine in simulation and only a hardware issue?
I guess the snapshot is chipscope captures, can you please export the User interface signals to a vcd and share us so that we can help you more ?
11-21-2013 07:22 AM - edited 11-21-2013 07:23 AM
thank you for replies
Vsrung, It is S.Raza not Sara ^_^
Please find the attached VCD
Yenigal, I had that burst_order chart before me and for my case I think it should not pose any problem. Why? since if you see the Burst Order chart on the DDR3 data sheet, it clearly says that if Starting Column address a[2,1,0] = 000 then burst type in sequential is 0,1,2,3,4,5,6,7 and since my addresses are the multiple of 8 hence I relaxed the issue discussed in the AR you told me. But even then if I am doing something wrong please notify me...
But I see your point related to app_rdy, it make sense of course and I follow it in my design
11-21-2013 04:37 PM
Just wanted to double check if the below thread vcds and the one you attached now are the same or is this a differnet project ?
11-21-2013 04:58 PM - edited 11-21-2013 04:59 PM
thanks for reply
yes they are the same. And please also note that they are in hardware, not simulation (checking using chipscope analyzer)
11-21-2013 09:38 PM
I have gone through your waveforms and noticed the shift, but as the write and read are given as seperate dumps it is a bit diificult to trace the sequence of events, it seems the first data itself shifted one word, so can you issue one write and one read command and provide one vcd with all the transactions?
Can you please reconfirm that this issue can't be seen in simulation ?
11-21-2013 10:21 PM
thank you for your constant input and response. If anything it has helped me push forward and think in different ways to solve.
So I did not do all the things in simulation. I only perform address geenration + write data path in simulation, since while reading I had severe problem of saving file in the data from VHDL and it was taking too long time to develop the simualtion enviornemnt, and since I was sure for the address generation thing and write path so I moved on and planned to see the read directly thru hardware which is actually paying good.
the other thing is OK I will try to send single data and then check the result as well. But before that I have planned some other testing things, if they do not work then I will try your point as well. Though it is easy but then I have to cahnge my code a little + c++ code as well for communication whihc will comsume a good amount of time which I am lacking becasue of my submission date for thesis