Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
14 years ago

pipeline bridge bursting and clock crossing bridge fifo length

Hello,

I'm new to Qsys/SOPC Builder and I'm currently developing a Nios II system and have problems to understand what the effects and the dependencies of the mentioned features are.

The Clock Crossing Bridge offers a FIFO length for Master-to-slave and Slave-to-master transfers. How can I determine the optimal setting of the FIFO length? Are there any prerequisites to setup the FIFO on the slave site for the different values or do higher values simply lead to more resource usage on the FPGA?

The Pipeline Bridge supports burst transfers which can be enabled for the component. What would happen if I connected a slave which doesn't support burst transfers or which doesn't support the maximum number of burst transfers set for the Pipeline Bridge component?

The typical settings seems to be that a fast component is connected to a Pipeline Bridge. The Pipeline Bridge is then connected to a Clock Crossing Bridge to which a slow component is connected:

fast <-> pipeline bridge <-> clock crossing bridge <-> slow

The Pipeline Bridge is not necessary but looking at the design examples it seems to be recommended to use one. Is there a rule for when to use a Pipeline Bridge?

Sincerely

Martin Stolpe

11 Replies

Show More
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    That's correct, whether you use a burst read of 10 beats or just sequentially read from 10 addresses in a row you'll get similar performance. In fact in SOPC Builder has a single dead cycle at the beginning of each burst that can eat into your performance when performing show bursts so when you don't need it you are better off not burst (besides the reduced complexity of having burst adapters all over the place). For something like on-chip RAM which doesn't support bursting this can cut your throughput down by as much as 50% if you were performing bursts of 2 into it (every transaction would take two cycles due to the extra dead cycle caused by the burst adapter).

    One thing you need to take care of though is to increase the arbitration share of the masters hooked up to the SDRAM when not using bursting as the round robin arbitration defaults to equal fairness of one access per master. For the Nios II masters I typically use an arbitration share of 8 when accessing a x32 SDRAM to match the cache line size (assuming 32 byte/line data cache).

    The high performance 2 controller has two burst settings, one for the offchip memory and the other for the local side (Avalon slave port). You can get away with setting the local burst count to 1 (non-bursting) and rely on the memory controller to glue multiple transactions together to form an offchip burst. Again if you do this then you should tweak your arbitration share since if a bunch of masters are fighting over the memory at different addresses then the memory controller most likely will not be able to buffer up enough accesses per master to perform the transaction merging I referred to earlier.

    The burst adapter you are seeing might be caused by the burst wrapping nature of the Nios II instruction master. It performs critical word first filling whereas the memory controller does not (internally it supports burst wrapping though but not the Avalon interface). If you disable bursting in the CPU and set the memory local burst count to 1 and tweak the arbitration shares you'll get the same functionality as having the burst adapter. The burst adapter would take the CPU burst and chop it up into non-wrapping bursts.