MIG back-to-back write timing confusion

[helmutforren]

I'm using Vivado 2017.1, verilog, KC705, Kintex-7.

I'm looking at UG586 Figure 1-77 "4:1 Mode UI Interface Back-to-Back Write Commands Timing Diagram (Memory Burst Type =

BL8)".

• Isn't it true that in 4:1 mode a ***SINGLE*** isolated write via app_wdf_wren (like the prior Figure 1-75) will cause EIGHT writes to my attached DDR3 Memory.
  
  
• Therefore, in Figure 1-77, it's a bit misleading.  app_sdf_wren is being held high for EIGHT clock cycles.  So this is in fact EIGHT CONSECUTIVE BACK-TO-BACK BURSTS.  (It would have been better for the example to have used a different number of writes, like 5 back-to-back bursts, where each burst is known to be 8 writes to DDR.)  Please confirm.
  
  
• Now I get a little confused.  I see what appears to be 8 sets of data, numbered 1-8 in my image below for "DATA CNT".  These are the data while app_wdf_wren is being asserted by the example.  I also see the app_addr getting incremented for successive data.  This works great for writes 1-6, and I've colored them green.  However, for writes 7-8, or at least for write number 8, there's no longer synchrony between the address and data.  Perhaps I just figured this out.  See below.  Please confirm below.
  
  
  • Inside the MIG, the address queuing is somewhat independent of the data queuing. (With a particular 2-cycle late limit.)  So the data got queued because app_wdf_rdy remained high and the example asserted app_wdf_wren eight consecutive times.  However, the addresses were being queued while app_en was being asserted... with the exception that app_rdy went low during this time.  So the address number 7 ("0000a30") was provided, but MIG ignored it because app_rdy went low for whatever MIG-internal reason.  The user application kept app_en high during this period, waiting for app_rdy to rise again.  Once it did, a clock cycle was allowed to get address number 7 in, followed by address number 8, and then app_en was deasserted.  Is this correct?  If so, then I finally understand it.

[vemulad · Accepted solution]

Hi @helmutforren

Please find my comments inline below

• Isn't it true that in 4:1 mode a ***SINGLE*** isolated write via app_wdf_wren (like the prior Figure 1-75) will cause EIGHT writes to my attached DDR3 Memory.

Deepika>> Yes, this is correct. Single write writes data to 8 address locations.

• Therefore, in Figure 1-77, it's a bit misleading.  app_sdf_wren is being held high for EIGHT clock cycles.  So this is in fact EIGHT CONSECUTIVE BACK-TO-BACK BURSTS.  (It would have been better for the example to have used a different number of writes, like 5 back-to-back bursts, where each burst is known to be 8 writes to DDR.)  Please confirm.

Deepika>> Yes, this is for eight back to back writes.

1. Now I get a little confused.  I see what appears to be 8 sets of data, numbered 1-8 in my image below for "DATA CNT".  These are the data while app_wdf_wren is being asserted by the example.  I also see the app_addr getting incremented for successive data.  This works great for writes 1-6, and I've colored them green.  However, for writes 7-8, or at least for write number 8, there's no longer synchrony between the address and data.  Perhaps I just figured this out.  See below.  Please confirm below.

Deepika>> the write data fifo and the command fifo work independently. You can fill in the data fifo with the write data before sending the command/address to command fifo. Check out figure 1-75 in UG586.

• Inside the MIG, the address queuing is somewhat independent of the data queuing. (With a particular 2-cycle late limit.)  So the data got queued because app_wdf_rdy remained high and the example asserted app_wdf_wren eight consecutive times.  However, the addresses were being queued while app_en was being asserted... with the exception that app_rdy went low during this time.  So the address number 7 ("0000a30") was provided, but MIG ignored it because app_rdy went low for whatever MIG-internal reason.  The user application kept app_en high during this period, waiting for app_rdy to rise again.  Once it did, a clock cycle was allowed to get address number 7 in, followed by address number 8, and then app_en was deasserted.  Is this correct?  If so, then I finally understand it.

Deepika>> Yes, this is correct. The user interface has to hold the app_en/app_wdf_wren and the values on address,command, data bus  till the app_rdy/app_wdf_rdy goes high.

[helmutforren]

thanks

[mingtaimingtai]

excuse me ,sir ,could you tell me  ,what is back to back meaning in uG586 MIG , 

back to back is  continuous writing?

non back to back is not continuous writing?

i donot know,

could you explain it ,thank you ,sir!

[helmutforren]

@mingtaimingtai yes, you are correct in that "back to back" means "continuous".  

[ahmad.zaklouta]

Hi!

I am also confused about the figure 1-77 in ug586.

I have a 1 GB DDR3 in KC705. After I generated the MIG core, the app_wdf_data is 512 bit (64 * 8) as the burst length is 8. my understanding of that is that I provide a write command with one address and 512 bit of data and the MIG do 8 writes to the DDR. Is this right? and then I add to the address 512 to write the next 512 bit.

from figure 1-77, the address is 28 bit so it seems like a 1GB DDR and it seems that I should provide just part of the app_wdf_data (64 bit) each clock cycle with a write command. Is this the case or what I have understood?

when it says that the MIG makes 8 write to the DDR. Does that mean eight 64bit writes or eight 8bit writes?

also is the 28 bit address for 512 bit block or for 64 bit block?