cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
helmutforren
Scholar
Scholar
2,823 Views
Registered: ‎06-23-2014

MIG back-to-back write timing confusion

Jump to solution

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.

MIG Write Question 201706061424.jpg

0 Kudos
Reply
1 Solution

Accepted Solutions
vemulad
Xilinx Employee
Xilinx Employee
4,285 Views
Registered: ‎09-20-2012

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.

Thanks,
Deepika.
--------------------------------------------------------------------------------------------
Google your question before posting. If someone's post answers your question, mark the post as answer with "Accept as solution". If you see a particularly good and informative post, consider giving it Kudos (the star on the left)

View solution in original post

5 Replies
vemulad
Xilinx Employee
Xilinx Employee
4,286 Views
Registered: ‎09-20-2012

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.

Thanks,
Deepika.
--------------------------------------------------------------------------------------------
Google your question before posting. If someone's post answers your question, mark the post as answer with "Accept as solution". If you see a particularly good and informative post, consider giving it Kudos (the star on the left)

View solution in original post

helmutforren
Scholar
Scholar
2,781 Views
Registered: ‎06-23-2014
thanks
0 Kudos
Reply
mingtaimingtai
Visitor
Visitor
2,204 Views
Registered: ‎08-29-2016

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!

 

 

0 Kudos
Reply
helmutforren
Scholar
Scholar
2,201 Views
Registered: ‎06-23-2014

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

ahmad.zaklouta
Contributor
Contributor
609 Views
Registered: ‎03-07-2018

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?

Tags (3)
0 Kudos
Reply