Getting the most out of S6 MCB - rd/wr port usage

[rifo]

Hello,

Given the below conditions

* 128 bit bidirectional MCB port

*  64 word constant burst length for MCB fifo

* 16 bit wide phsyical DDR3 interface running @325Mhz

* 130 Mhz fabric clock accessing MCB ports

Am I right in saying that  "In order to get the most out of MCB, I should

1) Give the MCB a RD command and at the same time start filling the WR fifo

2) When RD operation is finished, I should give the MCB the WR command and start emptying RD fifo contents

In my current design, I do NOT fill/empty MCB FIFOs parallel to a RD/WR operation and have a very low bandwidth. I seem to be using less than %50 of the available bandwidth.

   325 x 2 x 16 = 10400  where 325Mhz is the DDR3 operating frequency and 16 is the word length of DDR.

   15 x 160 x 2 = 4800 where 15Mhz is the incoming data rate, 160 is the data width and 2 is for RD & WR operation.

I would be most happy if you can guide me about this.

thanks a lot

rifo

[xud]

Hi Rifo,

please take a look at http://www.xilinx.com/support/answers/36413.htm

If you want to take most advantage of MCB, please re-order the commands to avoid turning it over(from WRITE to READ, or the other way) as possible.

To increase throughput, you may get better results using BL8 instead of BL4. Also, by re-ordering the data to reduce the amount of activate commands, throughput will be increased significantly.

You can figure the actual bandwidth from simulation.

[rifo]

Hello Sally,

Thanks a lot for your answer but I am not sure if I understand you correctly.

* The reason I thought that turning commands over (frm read to write or the other way) would be better was that by emptying /  filling FIFOs, I would save time. Because in my current setup  when I do consecutive reads, MCB can't start a new command before FIFO is emptied.

I can of course start emptying the buffer before MCB fully fills it but when I did that it led to errors. In your opinon, should one start filling / emptying MCB FIFOs before the operation is done?

* Does BL mean burst length? I have a constant burst length of 64 words and the physical ddr interface is 16 bits. Can you please elobarate what you mean with your last statement.

thank you very much for your time

rifo

[eteam00]

* Does BL mean burst length? I have a constant burst length of 64 words and the physical ddr interface is 16 bits. Can you please elobarate what you mean with your last statement.

In this context, BL means burst length at the DRAM component level, and this is completely distinct from the MCB 6-bit pX_cmd_bl port at the (internal) user interface.  Check the memory component datasheet for description of burst length.

For Spartan-6 MCB DDR3 designs, component level burst length is fixed at 8, specified with an MCB instantiation attribute.  Reference UG388, Table 2-2: C_MEM_BURST_LEN.  Keep this separated in your mind from the pX_cmd_bl port described in UG388 Table 2-5.

-- Bob Elkind

[rifo]

Thanks Bob,

Then I understand that since the original suggestion was to use BL 8 and S6 MCB already uses that by default. I don't have to worry about this point.

-- EDIT --

I should have told this sooner but the bandwidth calculation in my original post was obtained where I made 7 consecutive Reads followed by 7 consecutive writes. So I wasn't actually turning over commands.

thanks again

--------

[eteam00]

Then I understand that since the original suggestion was to use BL 8 and S6 MCB already uses that by default.

For DDR3 configurations, BL 8 is the sole option.

I don't have to worry about this point.

Correct.

-- Bob Elkind

[eteam00]

* The reason I thought that turning commands over (frm read to write or the other way) would be better was that by emptying /  filling FIFOs, I would save time. Because in my current setup  when I do consecutive reads, MCB can't start a new command before FIFO is emptied.

What do you mean by 'MCB can't start a new command before FIFO is emptied'?

I can of course start emptying the buffer before MCB fully fills it but when I did that it led to errors.

Please explain.

In your opinon, should one start filling / emptying MCB FIFOs before the operation is done?

Yes. Looking at UG388, I do not see any examples of emptying (reading) the READ data FIFO before the 'operation is done', nor do I find any text which prohibits emptying the FIFO before the 'operation is done' -- i.e. as the FIFO is beging filled.  Of course, many of the 'waveform diagrams' in UG388 are incomplete and have odd errors.  You may want to open a webcase on this matter, to either correct your use of the S6 MCB or to correct the incomplete or misleading details (if any) in UG388.

With Xilinx FIFOs, the timing of the 'rd_empty' flag is reliable.  I do not rely on the consistent timing or accuracy of the 'data_count' output.  If you read UG388 section 'Read Path Timing', there are references to the potential uncertainty of the data_count signal.

Finally, your original post does not state a clear problem or question.  What information or guidance are you seeking?

-- Bob Elkind

[rifo]

Hello Bob,

I am sorry for not being clear enough. I try to explain things further below

"" What do you mean by 'MCB can't start a new command before FIFO is emptied'  ""

Since I have 128 bit bidirectional RD/WR configuration. I don't have any other MCB ports. Therefore while doing consecutive RDs, I cannot start a new RD command before I empty the RD FIFO. I may of course be wrong on this statement but that's what I tried to mean. 

In my opinion, the time where I empty the RD FIFO is a waste in terms of DDR bandwidth utilization.

I can of course start emptying the buffer before MCB fully fills it but when I did that it led to errors.

When I start emptying/filling MCB FIFOs before corresponding command wasn't finished, the amount of time that it takes MCB to complete the WR / RD operation increased. I expected it to stay the same since the 2 sides of the FIFO should be independent. I will try to reproduce the waveform. Maybe I was being too aggressive and didn't give the MCB enough head start.

Finally, your original post does not state a clear problem or question.  What information or guidance are you seeking?

Assuming that I have to issue 7 RD and 7 WR commands, I was trying to find out which one of the following 2 approaches is better?

Approach A)

Timeline

1)    issue RD cmd    (wait till operation finishes)

2)    Empty FIFO    

3)    issue RD cmd 

4)    Empty FIFO

              ...

              ...

15)  Fill FIFO

16)  issue WR cmd

17)  Fill FIFO

18)  issue WR cmd

            ...

Approach B)

Timeline

1)    issue RD cmd,    Fill WR FIFO    (wait till RD operation finishes)

2)    issue WR cmd,   Empty RD FIFO

3)    issue RD cmd,    Fill WR FIFO

                    ...

                    ...

14)  issue WR cmd,  Empty RD FIFO

thank you very much for your help

rifo

[eteam00]

Since I have 128 bit bidirectional RD/WR configuration. I don't have any other MCB ports. Therefore while doing consecutive RDs, I cannot start a new RD command before I empty the RD FIFO.

As long as you do not over-run the RD FIFO, there should be no problem whatsoever with queuing up the next RD command while the current RD command is under way.  This is what FIFOs are for.  This would be no different than queuing up RD transactions on two different ports of a 2-port MCB configuration.  If the two-port case can be handled, certainly the MCB is capable of handling two queued RD commands from a single MCB port.

When I start emptying/filling MCB FIFOs before corresponding command wasn't finished, the amount of time that it takes MCB to complete the WR / RD operation increased. I expected it to stay the same since the 2 sides of the FIFO should be independent. I will try to reproduce the waveform. Maybe I was being too aggressive and didn't give the MCB enough head start.

This is worth double-checking.  I am skeptical of your conclusions, but I reserve the right to concede to them.

Assuming that I have to issue 7 RD and 7 WR commands, I was trying to find out which one of the following 2 approaches is better?

Approach C) -- three concurrent operations

1. Keep the 4-deep CMD FIFO full until all 7 READ commands have been queued, then keep the CMD FIFO full with WRITE commands until all 7 WRITE commands have been queued.
2. Keep the READ_DATA FIFO from overflowing until data from all 7 READ commands have been fetched
3. Keep the WRITE_DATA FIFO supplied with data, without overflowing or emptying, until all data for the 7 WRITE commands has been queued.

-- Bob Elkind

[rifo]

Thanks a lot Bob,

Once again your answer leads me to a new direction. I'll try your approach C. I am sure that it will yield better results than my current approach.

have a nice day

rifo