Forum Discussion

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

Why do two Avalon_MM_Pipeline Bridges respond differently to READ

Hi All,

In my design I have two Avalon_MM_Pipeline Bridges connecting to two segments of Avalon busses. In simulation, I can write and read from

one perfectly but the second bridge, although I can read and write to it, responds differently. The write access is fast but the read access is much

longer yet it completes ok and reads the correct written data. The two are identical in spec. The first one is the original from a reference design while

the second one is what I added. I started tracing through the maze of xbars and limiters and translators, my head is spinning now.

Can anyone suggest what the problem could be?:mad:

Thanks guys,

Shvitzer

4 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    Are you using different clocks on both sides of the bridge? If yes, QSys/SOPC Builder will add some clock crossing logic that can cause some latency on read transfers.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    Thank you !!! One of the slaves is on a slower clock so it probably adds clock crossing logic for all.

    Now, here is another twist, I am using generic SW drivers: "IOWR_32DIRECT, IORD_32DIRECT" for my verification, they work fine for slaves on the "good" bus but lock up on the troubled bus. You would think that they would for both, slow and fast busses. Again, the HW simulation works fine...

    One more question: where can I find info. on QSYS "under the hood works"? I would like to understand what there translators and limiters, etc. are.

    Thanks again.

    Shvitzer
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    The 'lock up' is probably caused by the addressed slave not responding correctly to all the bus cycle signals.

    You also want to make all your slaves 32bit (eg by returning 0 for any unwanted high bits) rather than having any 8 or 16 bit slaves.

    If the widths mismatch logic is added to generate multiple cycles on the slave side - some of which are likely to have no asserted byte enables.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    13 years ago

    Thank you guys ! The issue was that 1) as was stated by Daixiwen the second bus uses peripherals with two clocks 2) the second bus had Avalon MM FIFOs which have a backpressure feature (waitrequest) which prevents over-run or under-run. This caused the lockup e.g. reading from an empty FIFO. So, the SW has to make sure that there is something in the FIFO before attempting to read it ( similarly, for outgoing the other way make sure the FIFO is not full, etc.)

    Cheers,

    Shvitzer