Spartan® Family FPGAs

[barriet]

I would argue that trying to establish an understanding of the bottlenecks and associated throughput is not a deviation from the practical application of the MCB...

For example, 12.8Gbps (for a 16-bit interface at 800Mbps) equates to a peak bandwidth of 1.6GB/s.

A 128-bit back-end continually running at 200MHz equates to 16x 200MB/s or 3.2GB/s. Clearly this is not possible if you can't stop the data. It also fails to account for inefficiencies in the transfer or the problem of reading the data as well (which if you can't stop would presumably be interleaved or else the data capture is eventually terminated like a logic analyzer).

bt

[andrewmulcock]

Hi

you seem to be implying that Xilinx have no information as to what the maximum continuous data transfer rate the MCB can cope with.

If that is so and you can confirm this, then I'm happy in that  my original question is answered.

[ivan.mironenko · Accepted solution]

You need to understand, that the bandwidth will depend on many parameters: what kind of memory you use, how wide is the memory bus is, how many MCBs you have instantiated, whether your data access pattern is random or not, etc.

To answer your hypothetical question about maximum bandwidth, consider the following:

1) You have a chip with 4 MCBs working in x16 800Mbps mode

2) You write to contiguous blocks of memory, no random access whatsoever

3) You only write to memory

Then the best case memory bandwidth(upper bound) will be  4x16x800=51200Mbps = 6400 Megabytes per second.

OK?

[andrewmulcock]

thank you Ivan,

that's the number and bounds I am after, 

A very good answer,

[rgaddi]

Here's a related question for anyone who's got an answer.  According to UG388, you need to provide the MCB with a clock at 2x the memory bus frequency, i.e. an 800 MHz clock to get a 400 MHz bus (800 Mb/s on each pin.)  On page 80, the recommendation is that this clock be driven from one of the main PLLs, then through a BUFPLL_MCB (which doesn't change the frequency) and finally from there into the MIG wrapper core.

The only problem in all of this is that according to electrical specs document DS162 the PLL is unable to exceed 375 MHz, limiting the memory bus to 187.5 MHz.  The Clocking Wizard CoreGen seems to agree with this assessment, and that's whether or not you output those lines into a BUFG.

Anyone know what the story is there?

[jschmitz]

Are you looking at 36 of the DS162 which shows 375 for the PLL with the BUFGMUX?  I think you should be looking at the next page which lists the Foutmax with the BUFPLL (I think we need BUFPLL_MCB).  Unfortunately this doesn't have a spec yet, but one would hope that it would be sufficient to run the MCB at its supported rate.  Perhaps the clocking wizard is using the only available number but will be updated for this case.

[thomas1974]

Picking up and hopefully continuing that discussion, I found the frequencies  1080 1050 950 500  for the -3, -3N, -2, -1L devices, which clarifies that the 1l cannot run a 400 MHz DDR. (Table 51, pg 56).

Referring to the initial question:

Assuming a one-chip DDR3 attached to the MCB by 16Bit @ 400MHz x 2 and 40% maximum efficiency for balanced read an write - 10% overhead : This should by around 650 MBps continuous data transfer.

My question now is, if it is better to use a 4 port (2W + 2W) interface or better a dual port (1R + 1W) with 128 Bits and manage access manually rather than adding 4 processes and let them be managed by round robin ?