This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

C6678 - SRIO "Transaction Timeout occured on Non-posted transaction"

Hi Champs,

I've got a complex question on doorbell response:

Scenario: DSP1 is sending to DSP2 via SRIO DirectIO + Doorbell for singnalling.So LSU_Reg3 das Drbll_val bit 31 is set.

Doorbell message should also generate an interrupt in case an error occurs.

Bit 0 and Bit 1 in LSU_Reg4 are set.

LSU0 setup:

LSU_REG0 0x00000000
LSU_REG1 0x80000000
LSU_REG2 0x1082A348
LSU_REG3 0x800FFF00
LSU_REG4 0x00030103
LSU_REG5 0x0000FF54
LSU_REG6 0x00000011
 
Transfer of data and doorbell works fine.
 

LSU1 setup for second transfer:
LSU_REG0 0x00000000
LSU_REG1 0x80000000
LSU_REG2 0x1082A348
LSU_REG3 0x800FFF00
LSU_REG4 0x00031103
LSU_REG5 0x0000FF54
LSU_REG6 0x00000011

Transfer of data and doorbell works fine. However on transmit side I see Completion Status "Transaction Timeout occured on Non-posted transaction".

The issue goes away when setting SrcID_MAP to 0. However this workaround is not OK since I use the SrcID_MAP to identify the LSU.

Why does the doorbell response fail when setting SrcID_MAP == 1?

Thanks and regards,
one and zero

  • The srcid_map value in LSU reg4 and reg6 doesnot match. I beleive you need to match these.

     

    Thanks,

    Arun.

  • Hi Arun,

    that's not the issue. LSU_Reg6 is not written to. The transfer is started by writing to LSU_Reg5. Sorry for the confusion The value of the LSU_Reg6 as stated in the post is the read-only view.

    Kind regards,

    one and zero

  • ... any ideas?

    Thanks and regards,

    one and zero

  • If the destination device is getting the doorbell ok, then it is truly just the doorbell response that isn't getting routed back to the LSU in time.  You probably would have the same issue sending NWRITE_Rs instead of NWRITEs, it isn't a Doorbell issue.  I think the issue is somewhere in the deviceID checking modes.  So you can either be in promiscuous mode, i.e. accepting all incoming DESTIDs, or you can be in a mode that only allows the 16 local IDs to be accepted.  16 = BASE_ID + 15 BRR registers.  I'm assuming you are in the 2nd mode, or you probably wouldn't have any issues.  The unique thing about SRCID_MAP=0, is that this is the BASE_ID value and it is global for all ports on the device.  Note the BRR offset 0x1B3A4 is not used, instead this one is equivalent to the BASE_ID value.  The other BRRs can be specified to be local or global with the PRIVATE bit in the RIO_PLM_SP(n)_BRR_0-3_CTL registers.  By default this is set to private not global (allowing only 4 IDs per port), so make sure the PRIVATE and ENABLE bits are set appropriately on all the registers.  I'm betting the response is getting destroyed in the RX physical layer before being sent to the logical layer LSU.

     

    Regards,

    Travis