Why do two Avalon_MM_Pipeline Bridges respond differently to READ

[Altera_Forum]

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

[Altera_Forum]

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]

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]

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]

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