What is bit 19 in the SRIO ISDRn register?

Hi,
I marked this as unanswered because there's some more follow-up from the customer that I need help with. See below.


Brad,

Thanks for the information. Since I couldn’t find any documentation for RIO AMU, can you help answering these questions ?

Attached is the SRIO registers dump showing RIO_AMU_INT_ICSR value as 0x00000002, does it mean CPRIVD 1 ?

What is CPRIVD and what does it say about the error that caused this interrupt ?

What are the specific actions need to be taken and to clear this error ?

RIO AMU capture registers contain these values, do they provide any source information of the error ? How to decode them for back tracing ?
rio_amu_capt0_map 0x5AD1C580
rio_amu_capt1_map 0x00000101

Why the TI C6678 SRIO manual doesn’t show any information and memory mapping details related to RIO AMU ? Is there any other document for reference ?

SRIO    
    [0 ... 99]    
        rio_pid    0x44AB1900    Memory Mapped    
        rio_pcr    0x00000005    Memory Mapped    
        rio_per_set_cntl    0x0D000860    Memory Mapped    
        rio_per_set_cntl_1    0x00000000    Memory Mapped    
        rio_gbl_en    0x00000001    Memory Mapped    
        rio_gbl_en_stat    0x000007FF    Memory Mapped    
        rio_blk_en    0x00000001    (1 of 10, stride 8) [Memory Mapped]    
        rio_blk_en_stat    0x00000001    (1 of 10, stride 8) [Memory Mapped]    
        rio_multiid_reg    0x00FFFFFF    (1 of 8, stride 4) [Memory Mapped]    
        rio_pf_16b_cntl    0x00000000    (1 of 8, stride 8) [Memory Mapped]    
        rio_pf_8b_cntl    0x00000000    (1 of 8, stride 8) [Memory Mapped]    
        rio_doorbell_icsr    0x00000000    (1 of 4, stride 16) [Memory Mapped]    
        rio_doorbell_iccr    0x00000000    (1 of 4, stride 16) [Memory Mapped]    
        rio_lsu_icsr    0x00000000    (1 of 2, stride 16) [Memory Mapped]    
        rio_lsu_iccr    0x00000000    (1 of 2, stride 16) [Memory Mapped]    
        rio_err_rst_evnt_icsr    0x00000000    Memory Mapped    
        rio_err_rst_evnt_iccr    0x00000000    Memory Mapped    
        rio_amu_icsr    0x00000002    Memory Mapped    
        rio_amu_iccr    0x00000000    Memory Mapped    
        rio_doorbell_icrr1    0x00000000    (1 of 4, stride 12) [Memory Mapped]    
        rio_doorbell_icrr2    0x00000000    (1 of 4, stride 12) [Memory Mapped]    
        rio_lsu0_module_icrr    0x00000111    (1 of 4, stride 4) [Memory Mapped]    
        rio_lsu1_module_icrr    0x00000000    Memory Mapped    
        rio_err_rst_evnt_icrr    0x00000000    Memory Mapped    
        rio_err_rst_evnt_icrr2    0x00000000    Memory Mapped    
        rio_err_rst_evnt_icrr3    0x00000000    Memory Mapped    
        rio_amu_icrr1    0x00000000    Memory Mapped    
        rio_amu_icrr2    0x00000000    Memory Mapped    
        rio_interrupt_ctl    0x00000000    Memory Mapped    
        rio_intdst_decode    0x00080000    (1 of 24, stride 4) [Memory Mapped]    
        rio_intdst_rate_cnt    0x00000000    (1 of 16, stride 4) [Memory Mapped]    
        rio_intdst_rate_dis    0x00000003    Memory Mapped    
        rio_rxu_map_l    0x3F000000    (1 of 64, stride 12) [Memory Mapped]    
        rio_rxu_map_h    0x11112002    (1 of 64, stride 12) [Memory Mapped]    
        rio_rxu_map_qid    0x000002C0    (1 of 64, stride 12) [Memory Mapped]    
        rio_rxu_type9_map0    0x00000000    (1 of 64, stride 12) [Memory Mapped]    
        rio_rxu_type9_map1    0x00002000    (1 of 64, stride 12) [Memory Mapped]    
        rio_rxu_type9_map2    0xFFFF0000    (1 of 64, stride 12) [Memory Mapped]    
        rio_amu_srcid_map    0x00000000    (1 of 4, stride 4) [Memory Mapped]    
        rio_amu_window_reg0    0x10080000    (1 of 16, stride 12) [Memory Mapped]    
        rio_amu_window_reg1    0x00000000    (1 of 16, stride 12) [Memory Mapped]    
        rio_amu_window_reg2    0x00000000    (1 of 16, stride 12) [Memory Mapped]    
        rio_amu_priority_map    0x00000000    Memory Mapped    
        rio_amu_capt0_map    0x5AD1C580    Memory Mapped    
        rio_amu_capt1_map    0x00000101    Memory Mapped    
        rio_amu_window_pane    0x00000000    (1 of 128, stride 4) [Memory Mapped]    
        rio_amu_flow_masks0    0xFFFFFFFF    Memory Mapped    
        rio_lsu_reg0    0x00000000    (1 of 8, stride 28) [Memory Mapped]    
        rio_lsu_reg1    0xDA46CE00    (1 of 8, stride 28) [Memory Mapped]    
        rio_lsu_reg2    0xE7D86E00    (1 of 8, stride 28) [Memory Mapped]    
        rio_lsu_reg3    0x00000000    (1 of 8, stride 28) [Memory Mapped]    
        rio_lsu_reg4    0x11120401    (1 of 8, stride 28) [Memory Mapped]    
        rio_lsu_reg5    0x00000055    (1 of 8, stride 28) [Memory Mapped]    
        rio_lsu_reg6    0x00000000    (1 of 8, stride 28) [Memory Mapped]    
        rio_lsu_setup_reg0    0x44444444    Memory Mapped    
        rio_lsu_setup_reg1    0x00000000    Memory Mapped    
        lsu_stat_reg    0x00001111    (1 of 6, stride 4) [Memory Mapped]    
        rio_lsu_flow_masks    0xFFFFFFFF    (1 of 4, stride 4) [Memory Mapped]    
        rio_supervisor_id    0x00000000    Memory Mapped    
        rio_flow_cntl    0x00010000    (1 of 16, stride 4) [Memory Mapped]    
        rio_tx_cppi_flow_masks    0xFFFFFFFF    (1 of 8, stride 4) [Memory Mapped]    
        rio_tx_queue_sch_info    0x06060602    (1 of 4, stride 4) [Memory Mapped]    
        rio_garbage_coll_qid0    0x0389038A    Memory Mapped    
    [100 ... 194]    



Thanks,

Balaji

Thanks for the information. Since I couldn’t find any documentation for RIO AMU, can you help answering these questions ?
Why the TI C6678 SRIO manual doesn’t show any information and memory mapping details related to RIO AMU ? Is there any other document for reference ?

Attached is the SRIO registers dump showing RIO_AMU_INT_ICSR value as 0x00000002, does it mean CPRIVD 1 ?

What is CPRIVD and what does it say about the error that caused this interrupt ?

What are the specific actions need to be taken and to clear this error ?

RIO AMU capture registers contain these values, do they provide any source information of the error ? How to decode them for back tracing ?
rio_amu_capt0_map 0x5AD1C580
rio_amu_capt1_map 0x00000101

Hi, I appreciate all the help I've been getting here. The customer has some more follow-up questions highlighted in red below. This all stems from them trying to resolve a crash issue.

Thanks for the information. Since I couldn’t find any documentation for RIO AMU, can you help answering these questions ?

Why the TI C6678 SRIO manual doesn’t show any information and memory mapping details related to RIO AMU ? Is there any other document for reference ?

This information will available on next SRIO user guide release.

Attached is the SRIO registers dump showing RIO_AMU_INT_ICSR value as 0x00000002, does it mean CPRIVD 1 ?

Yes, CPRIVD 1 is set.

Q:  Is there a relation between CPRIVD # n and Core # n ?  

What is CPRIVD and what does it say about the error that caused this interrupt ?

The CPRIVID can be used to confirm the DestID of the incoming response. If it is not targeted for our endpoint device, the request will not be accepted.

Q:  Does it mean this interrupt occurred due to an  incoming response not targeted for this DSP SRIO ?   If not  what caused the SRIO master to trigger this error behavior please explain ? For example  I see the AMU interrupt bit set due to DDR3 ECC errors  from the silicon errata  (TMS320TCI6616 Communications Infrastructure KeyStone SoC Silicon Errata Silicon Revisions 1.0, 1.0A, 2.0, SPRZ331G)  

What are the specific actions need to be taken and to clear this error ?

The general flow of the AMU can be described as:

1. DMA requests sent to the peripheral with write data sent to FIFO

2. Segmentation/Aggregation Rules determine MAKE PACKET

3. VBUS CPRIVID from Master determines the SOURCEID of packet

4. Windowing mechanism determines DESTID, Address Offset, and Port

5. DMA priority mapped to RapidIO priority

6. Outbound Credit requested

7. Assigns SRCTID (Has all needed RapidIO Header info)

8. If Non-posted transaction, fills out scoreboard information.

9. If posted transaction, return SSTATUS, SID

10. Sends packet header/payload to TX shared buffer

11. Response packets are accepted, with read data sent to FIFO

12. SRCTID used to determine CMSTID, CID

13. DMA response including RDATA, RID, SSTATUS, SID

14. Clear scoreboard

Q :  From the above operational flow (Windowing mechanism determines DESTID, Address Offset, and Port),  it seems DIO supports AMU ? Please confirm. Currently we use type 11 SRIO messaging and DIO type 5 NWRITE_R, non-posted transaction.

RIO AMU capture registers contain these values, do they provide any source information of the error ? How to decode them for back tracing ?

rio_amu_capt0_map 0x5AD1C580

rio_amu_capt1_map 0x00000101

Error responses set a bit in the AMU_INT_ICSR register based on the CPRIVID of the transaction. Each bit can be routed by software configuration through the ICRR to a specific CPU for handling of the error. The CPU can then access the RIO_AMU_ERR_CAPT0, RIO_AMU_ERR_CAPT1 registers which will contain the VBUS address of the non-posted transaction that failed along with the CPRIVID and CMSTID. If a DOORBELL retry response occurred, the INFO field is also captured. The capture register is updated by the peripheral hardware each time an error response is received. Therefore if the capture register is not read in time, there is a possibility that the contents are not current or even belong to the same cpu. The CPRIVID can be read to validate the ownership of the contents.

Thanks,

Q: Is there a relation between CPRIVD # n and Core # n ?

Thanks, I look forward to the other answers. In the meantime, you mentioned an update to the SRIO users guide to include the AMU details. Do you have an ETA for that release. Better yet, can I get a preliminary version now for the customer? It might save on a lot of back and forth questions.

Ganapathi,

Thank you for the reply. 

Bit 19 in the ISDRn register is set and is relevant to the issue. I am still looking for the answers to my questions.

Q:  Does it mean this interrupt occurred due to an  incoming response not targeted for this DSP SRIO ?   If not  what caused the SRIO master to trigger this error behavior please explain ? For example  I see the AMU interrupt bit set due to DDR3 ECC errors  from the silicon errata  (TMS320TCI6616 Communications Infrastructure KeyStone SoC Silicon Errata Silicon Revisions 1.0, 1.0A, 2.0, SPRZ331G)

Q: What are the specific actions need to be taken and to clear this error ?

Can you please let me know?

Thanks,

Jackie

As Ganapathi mentioned, the AMU is not functional in the silicon, so it is very strange that the AMU_ ICSR bit is being set to begin with.  Just a couple clarifying items...

AMU - was going to be used for generating DIO outbound packets with memory windows.  We had issues and it was de-scoped and removed from the spec.

As mentioned above, if the AMU_ISCR bit was set, it means that the packet that was sent (or attempted to be sent) had and error.  So we used the PRIVID of the master who sent the packet, when issuing the interrrupt.  The interrupt could be routed to that master or another master depending on the AMU_ICRR register setting.

To clear the interrupt, simply write 0 to the AMU_ICCR register bit...

RIO_AMU_INT_ICCR Interrupt Condition Clear Register (ICCR) (Address Offset 0x01F8)

Regards,

Travis

 I understand the DIO AMU is not supported by the hardware, also in our system LSU is the initiator for the DIO outbound packets.  Can a core (as per CPRIVID) in a malfunctioned state still generate this error by attempting a write to the garbage window space ? 

I think a draft document of all the AMU register descriptions can be helpful and self-explanatory to know the window mapping details to decode the register values captured in rio_amu_capt0_map and rio_amu_capt1_map and to know more specific error details of the packet that got undelivered.

I verified that non-supported AMU (BLK9_EN) functionality is enabled by default as shown below.

Please disable BLK9_EN.  You should not see an interrupt when this is disabled, as all memory accesses to the device specific AMU memory space will be ignored.  Can you please verify that?

We can't supply any details on the AMU or windowing mechanisms since the function is not supported.

Thanks,

Travis

I did verify disabling the BLK9_EN before and saw no interrupts, but this doesn't help chasing the source of the problem that we are experiencing intermittently a core goes un-responsive from the system perspective when we see this error happens. As the AMU  is enabled by reset default, the SRIO user guide doesn't say instructions either this block is associated with the AMU that silicon doesn't support so user should disable it.

Can you answer the following:

Is this a false error being reported in C6678 similar to the Multicore DSP+ARM KeyStone II errata mentioned in this thread so we can ignore it safely? or

Is it an appropriate error caused by a master attempting a malfunction ? if so we don't have any details to debug and also not reliable about the information captured by this block are valid since the functionality is not yet supported in the silicon.     

Balaji Arumugam said:

As the AMU  is enabled by reset default, the SRIO user guide doesn't say instructions either this block is associated with the AMU that silicon doesn't support so user should disable it.

Yes, that is unfortunate, but correct.

Balaji Arumugam said:

Is this a false error being reported in C6678 similar to the Multicore DSP+ARM KeyStone II errata mentioned in this thread so we can ignore it safely? or

Is it an appropriate error caused by a master attempting a malfunction ? if so we don't have any details to debug and also not reliable about the information captured by this block are valid since the functionality is not yet supported in the silicon.     

I can't say with 100% certainty here, and will need to talk with the IP designer.  The only way that I believe this interrupt would be generated is if a master tries to write to the memory space the AMU occupies in the memory map.  From table 2-2 of http://www.ti.com/lit/ds/symlink/tms320c6678.pdf  I know the memory space allocated for the AMU was 256M, so I believe it corresponds to Logical address range 50000000 - 5FFFFFFF (reserved).  I'm thinking that there could be some master writing to this space causing some sort of lock-up.  Can you verify this is/is not happening?

Regards,

Travis

Sure. As the issue is very intermittent and not particular core or a DSP in the system will have to come back with the details. Thanks !