Forum Discussion

FabianL's avatar
FabianL
Icon for Occasional Contributor rankOccasional Contributor
16 days ago
Solved

Avalon Transaction Responses & Bridges

Hello

I have a question about the behavior of Avalon-MM Pipeline Bridges concerning the response signals.

I have the following setup:

  • 2 (or more) Avalon-MM Masters
    • Master cmd_ctrl (supports Avalon responses) 
    • Master B (no response support)
  • global_mm_bridge (pipeline Bridge IP Core) with Support for Transaction Responses
    •  

  • Multiple Slaves 
    • Slave global_reg (simple register read & write access)
    • other Slaves do not have Avalon response signals (neither readdatavalid, nor writeresponsevalid)

 

My understanding of Avalon-MM bridges was always that they act as kind of "transparent bridge", i.e. they do not sent responses by themselves, but only transfer/route the responses of the addressed slave behind the bridge.

However, when I capture the transactions using Signaltap I noticed that the Bridge is creating a writerepsonse valid before, this is even processed by the addressed slave.  In the signaltap capture, you can see the writereponse (highlighted in yellow) arriving at the initiating master (cmd_ctrl) before, the addressed slave (global_reg) even generates it. Hence I would assume this is generated by the mm_bridge directly after it accepts the write command.

 

Now my questions are:

  1. Is this the intended behavior of a pipeline bridge? 
  2. If yes, is there any way to modify the settings of the bridge, to make sure the master (cmd_ctrl) only receives a writeresponsevalid after the respective slave has sent it?
    • Background is: cmd_ctrl also needs to write/read from slave B, however this must not be done, before the slave global_reg has fully processed the write command, as it must prepare some glue logic.
  3. Is there any other option to realize a fully transparent Avalon-MM bridge?

 

best regards

Fabian

  • That was the reason, why we tried the response interface. I also expected the response codes to be propagated back to the master. But when I understand you correct, the Avalon response only works on a single interconnect and is not useable across bridges ist that correct?

    Yes, your understanding is correct.

     

    Can you don't use the bridge? Master get the response from slave?

4 Replies

  • FabianL's avatar
    FabianL
    Icon for Occasional Contributor rankOccasional Contributor

    Hi Sheng, thanks for the update,

     

    We tried the variant by holding waitrequest until a write command is fully processed already. However that does not work in case of pipeline bridges in between either, since e.g. for single word writes, the bridge accepts the write right away before the slave is triggered, due to its pipeline stage. Hence the initiating Master has also no control, when the write is actually processed at the slave side. ==> so that is not working either.

    That was the reason, why we tried the response interface. I also expected the response codes to be propagated back to the master. But when I understand you correct, the Avalon response only works on a single interconnect and is not useable across bridges ist that correct? 

    best regards

    Fabian

     

    • ShengN_altera's avatar
      ShengN_altera
      Icon for Super Contributor rankSuper Contributor

      That was the reason, why we tried the response interface. I also expected the response codes to be propagated back to the master. But when I understand you correct, the Avalon response only works on a single interconnect and is not useable across bridges ist that correct?

      Yes, your understanding is correct.

       

      Can you don't use the bridge? Master get the response from slave?

      • FabianL's avatar
        FabianL
        Icon for Occasional Contributor rankOccasional Contributor

        In parts of the design this is an option. But the relevant parts are in a QSYS subsystem, which requires a bridge to have a single Avalon Slave port at the interface. Otherwise all Avalon-MM Slave Ports of the subsystem are exported individually, causing a real mess in the interface (we are talking about 5-10+ slave ports).

         

        So I guess we have to implement a independent handshaking mechanism on top of Avalon.

        Thanks for your explanations.

  • ShengN_altera's avatar
    ShengN_altera
    Icon for Super Contributor rankSuper Contributor

    Hi Fabian,

    what you’re seeing is expected: once “transaction response support” is enabled, the Avalon-MM Pipeline Bridge is no longer fully transparent and may generate an early writeresponsevalid as soon as it accepts a write, rather than waiting for the downstream slave, which breaks strict ordering assumptions. There isn’t a setting to force true pass-through behavior, so if your cmd_ctrl depends on the slave (global_reg) finishing its internal processing before accessing another slave, the correct fix is to enforce completion at the slave side—typically by holding waitrequest high until the write is fully processed, or by adding a status/handshake mechanism—rather than relying on the bridge’s response timing.