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!

Showing results for 
Search instead for 
Did you mean: 
Registered: ‎11-26-2014

UG586 - clarification needed



The UG586

ver 4.1: https://www.xilinx.com/support/documentation/ip_documentation/mig_7series/v4_1/ug586_7Series_MIS.pdf


and ver 1.0: https://www.xilinx.com/support/documentation/ip_documentation/ug586_7Series_MIS.pdf


both show a figure showing back-to-back write commands

page 616, figure 4-61 on the new version

page 93, figure 1-49 on the old version.


They both try to explain: "When issuing back-to-back write commands, there is no maximum delay between the write data and the associated back-to-back write command".


Following image is from the older document, which has the problematic part more clear:




The app_en is sending 6 successive writes to command interface (addr a-f), and addr-g is ignored as the app_en is low.


But the app_wdf_* is sending 7 successive datas to writedata interface.


The horizontal arrow-line is trying to indicate some delay from app_en going low to what?


In the new document, the figure is:




 Here again, addr g is to be ignored on command interface, but as the bursting, the diagram cuts the vital part, on writedata interface.

Again, there is a horizontal arrow-line from falling edge of app_en to what?




1. Is there an error in the old document, such that one extra writedata is supplied to the controller compared to writecommands.


2. What is the horizontal arrow-line trying to indicate?


3. Is the following true: If the write_command is single isolated command (previous and next commands are NOPs (app_en is low) and READs), then the timing requirement from app_cmd to app_wfd_* is -1 to +2 clock cycles.

But if the write command is immediately (without en going low) followed by at least one write command, then the timing from app_cmd to app_wfd_* is -inf to +inf clock cycles?


4. What is the exact definition of back-to-back access. Do the successive commands need to have adjacent addresses? Or can the addresses be totally random? And do the successive commands need to be on adjacent clock cycles, or can there be clock cycles in between where app_en is low?


Br, -Topi

0 Kudos
1 Reply
Registered: ‎11-28-2016

Re: UG586 - clarification needed

Hello @topi-procemex,


When looking at this, the earliest version of the doc, and everything in between, I think this was a confusing example that should have been completely purged but remained in the LPDDR2 section.


I would stick with the latest version of the doc and follow the Write Path description and examples in the DDR3/DDR2 section starting on page 168 of the latest version.  They have a figure that shows back-to-back writes when app_en goes low while continuing to issue write data but they don't include any description to go along with it. 


Here they're trying to get clever with the explanation on how the write paths and command paths are independent of each other and you can queue more data in the write path while the command path is on hold.  The requirement is still met that the write data is still accepted within 2 clocks of the write command (Addr f and W f0 in the original figure) and in the 2:1 figure in the current doc the data is being supplied as quickly as it could be in that scenario where the 2tck rule is a 4tck rule.  Overall trying to use the app_interface this way makes it more complex than necessary for most users and has no real benefit in application.  If the app_interface can't accept any more commands then hold off on sending data until it's ready again.


1:  There is no error in the old document and it's a completely valid scenario.  Write F command and data timing is satisfied while the write path data FIFO now has data G.  When app_en comes back high you can issue Write G.


2: In the old document that arrow serves no purpose in that condition.  It makes sense in the 2:1 scenario in the current version. Overall these are unnecessarily complex examples that I don't recommend following. 


3:  The takeaway here is that if a command is accepted in a 4:1 controller you need to present the data -1 or +2 CK.  If a command isn't accepted you can keep filling the write path data FIFO until it's filled.  Now you just need to keep track of your write data pointer and your command pointer.  99.99% of the time doing it this was just causes issues for most users.  Most of the time users do this inadvertently and end up issuing duplicate write commands.


4: See above. It's mostly about the concept of independent command and data paths where you can stuff more data in to the data path as long as you're satisfying the command path to data path requirements.