Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++

Avalon Bridges

Altera_Forum
Honored Contributor II
1,281 Views

I have created a series of bridges that you may find useful to improve your FMAX or control how the Avalon switch fabric is created. See the below link to the project.  

 

avlaon to avalon bridges project (http://www.niosforum.com/pages/project_details.php?p_id=85&t_id=18)
0 Kudos
9 Replies
Altera_Forum
Honored Contributor II
531 Views
0 Kudos
Altera_Forum
Honored Contributor II
531 Views

Thanks I fixed the link

0 Kudos
Altera_Forum
Honored Contributor II
531 Views

I've run into a couple of problems using the bridges. In all cases, I'm using the Asynchronous FIFO'ed bridges. 

 

1) The lpm fifo component declarations include an lpm_width parameter, but this parameter isn't used when declaring the width of the components ports. This causes one of the fifos to error out in compilation due to mismatched port & signal widths. The simple fix is to modify the generated VHDL and use the lpm_width parameter when declaring the components data port widths (as opposed to hard-coding them). I'm not sure how to edit the generator script to correct this. 

 

2) When trying to pass interrupts through the asynchronous FIFO'ed bridge, I get an error when trying to generate if the clock domain on the slave side of the FIFO is pipelined. The error is: 

 

ERROR: 

adapter_downstream_pipeline_3/upstream, no device_base (Base_Address = ) 

255 

 

Haven't figured out how to fix this one. 

 

3) Still not sure what's going on with the .zip within the .zip. Should they be unzipped at the same level or are they hierarchical? The outer .zip file has a directory name embedded, but the inner one doesn't. Where should the inner .zip file be unzipped to (directory name and relative location)? 

 

Any help would be appreciated.
0 Kudos
Altera_Forum
Honored Contributor II
531 Views

1- yes I have heard from someone else about this. I will try and fix it in the next week or so.  

2- not sure what is going on so I will take a look.  

3-ignore the zip file inside the .zip it should not have been included. Sorry 

 

Longshot. 

 

 

 

--- Quote Start ---  

originally posted by dallasc@Sep 7 2006, 07:06 PM 

i've run into a couple of problems using the bridges.  in all cases, i'm using the asynchronous fifo'ed bridges. 

 

1)  the lpm fifo component declarations include an lpm_width parameter, but this parameter isn't used when declaring the width of the components ports.  this causes one of the fifos to error out in compilation due to mismatched port & signal widths.  the simple fix is to modify the generated vhdl and use the lpm_width parameter when declaring the components data port widths (as opposed to hard-coding them).  i'm not sure how to edit the generator script to correct this. 

 

2)  when trying to pass interrupts through the asynchronous fifo'ed bridge, i get an error when trying to generate if the clock domain on the slave side of the fifo is pipelined.  the error is: 

 

error: 

adapter_downstream_pipeline_3/upstream, no device_base (base_address = ) 

255 

 

haven't figured out how to fix this one. 

 

3) still not sure what's going on with the .zip within the .zip.  should they be unzipped at the same level or are they hierarchical?  the outer .zip file has a directory name embedded, but the inner one doesn't.  where should the inner .zip file be unzipped to (directory name and relative location)? 

 

any help would be appreciated. 

<div align='right'><{post_snapback}> (index.php?act=findpost&pid=18142) 

--- quote end ---  

 

--- Quote End ---  

0 Kudos
Altera_Forum
Honored Contributor II
531 Views

Hi Longshot, 

 

i just read the doc about this avalon to avalon bridge. Maybe your bridge could help me to gain the performance and resources used.  

 

The project(s) i am currently working on has a couple of avalon masters. 

The target FPGA is an EP2C50F484I8N and fniosclock is 64MHz. Sometime it is hard to keep the 64MHz. 

 

The seven avalon masters are : 

niosII-F 

ethernet Mac 100MBit 

4x self written interfacemaster 32-Bit with up to 1,6MByte/sec  

adc streaming master 32-Bit with 4MByte/sec 

 

and a couple of slaves (uart,timer,epcs,jtag,spi,1wire,tristate cfi ...) 

 

all masters read and write only to the sdram. except the nios that also read and writes to all other slaves. 

 

my first idea is to use a registered bridge and put all slaves only the nios comunicates with into. but then i need access to all 32 ints. i guess this could seperate the load and speed up fmax. 

 

is there a chance with one of these bridges to speed up nios & sdram without incrementing the clock of all the other masters ?  

 

should i add a (a)sync. fifo bridge to let the nios / sdram run at a higher clock rate (as high as possible) ? 

 

would any bridge be usefull to be put into the master connections ? 

 

if you need more information like the ptf let me know. i would greatly try your bridges if this project yould benefit from it.  

 

Thanks in advance. 

 

Michael Schmitt 

 

PS: I use nearly all 32 IRQs ...
0 Kudos
Altera_Forum
Honored Contributor II
531 Views

If you put a couple of master behind a registered bridge that would help you maintain for fmax. Your slow down in ostlikely in the arbitration logic on the bus with all thouse masters. If the slow down is not in bus then it will not help. 

Longshot 

 

 

 

--- Quote Start ---  

originally posted by mschmitt@Sep 11 2006, 02:44 AM 

hi longshot, 

 

i just read the doc about this avalon to avalon bridge. maybe your bridge could help me to gain the performance and resources used.  

 

the project(s) i am currently working on has a couple of avalon masters. 

the target fpga is an ep2c50f484i8n and fniosclock is 64mhz. sometime it is hard to keep the 64mhz. 

 

the seven avalon masters are : 

niosii-f 

ethernet mac 100mbit 

4x self written interfacemaster 32-bit with up to 1,6mbyte/sec  

adc streaming master 32-bit with 4mbyte/sec 

 

and a couple of slaves (uart,timer,epcs,jtag,spi,1wire,tristate cfi ...) 

 

all masters read and write only to the sdram. except the nios that also read and writes to all other slaves. 

 

my first idea is to use a registered bridge and put all slaves only the nios comunicates with into. but then i need access to all 32 ints. i guess this could seperate the load and speed up fmax. 

 

is there a chance with one of these bridges to speed up nios & sdram without incrementing the clock of all the other masters ?  

 

should i add a (a)sync. fifo bridge to let the nios / sdram run at a higher clock rate (as high as possible) ? 

 

would any bridge be usefull to be put into the master connections ? 

 

if you need more information like the ptf let me know. i would greatly try your bridges if this project yould benefit from it.  

 

thanks in advance. 

 

michael schmitt 

 

ps: i use nearly all 32 irqs ... 

<div align='right'><{post_snapback}> (index.php?act=findpost&pid=18209) 

--- quote end ---  

 

--- Quote End ---  

0 Kudos
Altera_Forum
Honored Contributor II
531 Views

Hi, 

 

I am working on a system with 5 masters accessing a DDR2 via the Altera MegaCore DDR2 interface (slave). The avalon switch fabric can not achieve our FMAX target of 125 MHz. 4 of the masters should run at 125 MHz - the 5th master is a NiosII at 50 MHz. Could your avalon to avalon bridge help here? If so - what approach do you suggest? 

 

Thanks in advence, 

Ove Brynestad
0 Kudos
Altera_Forum
Honored Contributor II
531 Views

Usually the problem with fmax has to do with the number of masters trying to arbitrate for a slave. Here you have 5. I am assuming that you are working with the cyclone family, because this should not be a problem for the Stratix familes. The best way to aproach this would be to place several of the masters behind a registered bridge. However that bridge needs to support bursts for the best efficiency. I am working on that right now and hope to have it finished within a week. The Nios since it is running at a different clock rate will be using the standard clock crossing logic that is standard with the nios. This is very inefficient from a through put point of view. The clock crossing fifoed bridge is the best for this.  

 

Infact this week the bridges have been going through a major revamping and testing , to improve performance and fix bugs. Hopefully withing a week I will have them post and then it should help.  

 

Now it may be that the real slow down is your masters. Currently DDR2 suports burst of 2 and 4 if I remember correctly. You will be adding extra logic in the switch fabric if your master&#39;s max burst is 128. What sopc builder does is add logic to break that burst up into smaller burst sizes that match those of the slave. This extra logic can be slowing the fabric down. I have noticed this with the PCI core. SO by simply putting a registered bridge in front of this master you can then do the burst size reduction in one clock and then arbitration in the second clock. All it cost is one cycle of latency. The current registered bridge can help with that. And then when the updated version is availible with burst, you set the bridge to have a burst size equal to that of the slave and your efficiency goes back up.  

 

The other option is to add the registered bridge right in from of the DDR2 core. It really all depends on where the slowdown critical path is.  

 

Hope this helps. 

 

Longshot
0 Kudos
Altera_Forum
Honored Contributor II
531 Views

Wow - thanks for your excellent advices - I almost have a solution now! 

 

A short resume of what I did: 

 

1) The critical path was inside the Avalon switch fabric and related to the burst circuitry. Took down the burstwidth from 9 to 6 bits (max burst from 512 to 64) - we only need 48. This chopped the slack from -9 to -5 ns. 

2) As a test case I took down the masters from 5 to 1. The slack went down to -1.8 ns - still not good enough. The critical path was now from the burst circuitry to the DDR2 controller. 

3) Added one of your registered bridges between the master slave pair - and voila - achieved a slack of 0.5 ns plus reduction of 200 LE&#39;s! 

4) Added back a master (from 1 to 2) and the slack was back at -3.8 ns. Critical path is now from the avalon_to_avalon_bridgest_0_avalon_slave_arbitrator to burst_0. Don&#39;t know what to do to fix this one.  

 

So it is clear that the Altera Megacor DDR2/Avalon/burst combination in a CycloneII -8 is struggling to achieve 125 MHz in general - and in particular with multi master systems. We will thus try to do the 4:1 arbitration for the high speed masters ourselves. 

 

Some further questions: 

- What does the current registered bridge do to the burstcont/how should it be set up? 

- Are there any conditions/terms to use your bridges in a commercial product? 

 

Looking forward to the new burst supporting version! 

 

Many Thanks & Regards, 

Ove Brynestad
0 Kudos
Reply