• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 98 subscribers
  • Views 354 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

What triggers an ILL_TRANS_DECODE ?

Igor Almeida
Intellectual 280 points

I am trying to connect an ML605 Xilinx FPGA dev kit (which contains a SRIO IP core) with the TMDSEVM6670LE Rev 3a. Link bring-up runs correctly, I can exchange MAINTENANCE packets, and I see no errors in SPn_ERR_STAT. However, when I try to send a MESSAGE packet to the DSP, I get an ILL_TRANS_DECODE error and the socket (which is blocking) never unblocks.

My RXU_MAP settings (I use only one rule) are very loose and I barely set any masks. Still, I am getting the access block and I wonder if it could be due to a malformed packet. Since I cannot read what is being sent by the FPGA kit, I would like to know what could cause the peripheral to trigger this error. Maybe a reserved SrcID or DstID; maybe Segment Mapping must be matching? Please list all the cases, it will greatly improve my understanding of the matter.

  • 0
    TI__Mastermind 23525 points

    If you are talking about bit 27 of the RIO_ERR_DET, you can capture the bad packet in the capture registers if you enable the RIO_ERR_EN bit 27.  The conditions that could cause this are described in Table 2-27 of http://www.ti.com/lit/ug/sprugw1b/sprugw1b.pdf.  For messaging look at class 3.

    Regards,

    Travis

  • 0 in reply to tscheck
    Intellectual 280 points

    You probably mean that to enable these captures I must set bit 27 in RIO_ERR_EN instead of *_DET.

    Anyway, some final questions: regarding the CTRL_CAPT register (Table 3-95) in the SRIO UG, what goes inside the Implementation Specific bits (0-15)?

    Thank you in advance, I will test this now.

  • 0 in reply to Igor Almeida
    TI__Mastermind 23525 points

    Yes, I fixed it above.

    I confirmed that those implementation specific bits are not used in our IP.  So treat them as reserved.

    Regards,

    Travis

  • 0 in reply to tscheck
    Intellectual 280 points

    Travis,

    Though the manual gives me the information I needed, it still cannot explain the problem, so please help me look for possible sources of errors.

    This is the output from the SRIO GEL file 0550.TCI6616_8_Srio_v0.13.gel, which I have previously downloaded from this forum (by the way, is there some wiki page or similar concentrating those gel files?):

    C66xx_2: GEL Output:  *******************************************************************************************************
    C66xx_2: GEL Output: ********************************** SRIO LOGICAL/TRANS LAYER ERROR SCAN RESULTS ************************
    C66xx_2: GEL Output: *******************************************************************************************************

    C66xx_2: GEL Output:  Problem(ILL_TRANS_DECODE): Illegal transaction decode (switch or endpoint device) (To clear this bit SW should write 0 to it)
    C66xx_2: GEL Output:  Reason & Solution: 1) For an LSU or the TXU: receives illegal fields in the rsp packet for an IO/msg trans.
    C66xx_2: GEL Output:                     2) For an MAU or the RXU: receives illegal fields in the request packet for an IO/msg trans.

    C66xx_2: GEL Output:  Logical layer Error occurred in transaction from 0x00FF ---> 0x0000

    C66xx_2: GEL Output:  DETAILS OF THE ERRONEOUS PKT:

    C66xx_2: GEL Output:  PKT_TYPE                  ---> Message packet
    C66xx_2: GEL Output:  DIO_XAMSBS ---> 0x00
    C66xx_2: GEL Output:  DIO_ADDRESS_MSB ---> 0x00000000
    C66xx_2: GEL Output:  DIO_ADDRESS_LSB ---> 0x00000000
    C66xx_2: GEL Output:  IMP_SPECIFIC---> 0x0000
    C66xx_2: GEL Output:  For Multi-segmented msgs:
     MSGINFO ---> Letter-2, Mbox-3, SegmentId-0
    C66xx_2: GEL Output:  For Single-segmented msgs:
     MSGINFO ---> Letter-2, Mbox-48

    My RXU_MAP_L register has zeroes for LTR_MASK and MBX_MASK; and my RXU_MAP_H register has ones for DEST_PROM and SRC_PROM; so that EVERY incoming packet should be sent to the queue configured in RXU_MAP_QID (in my case, Queue 707, FlowID 1). Because the SRIO LLD hardcodes some of these values, I had to manually change these registers in the memory browser: is there a more intelligent way? Am I only updating part of the necessary configuration, i.e., to get the mapping to work do I need anything other than RXU_MAP_*?

    In the FPGA, I am setting msgseg = msglen = 0, and another thing I would like to understand is why the GEL file reads the mailbox as 48 (= 0x11 << 4, presumably the msgseg is in the lower 4 bits, which I can almost confirm in [1] page 156 and (maybe) page 86). Anyway, the same ILL_TRANS_DECODE error happens even when sending to mailbox = letter = 0, so I'd assume this is more likely a reporting error on the GEL's part.

    [1] http://www.xilinx.com/support/documentation/ip_documentation/srio_gen2/v1_3/pg007_srio_gen2.pdf

  • 0 in reply to Igor Almeida
    TI__Mastermind 23525 points

    The wiki that has these gels is at:

    http://processors.wiki.ti.com/index.php/Keystone_Device_Architecture  look for Keystone SRIO Debug Gel

    This issue has nothing to do with the RXU mapping, it is a malformed packet of some kind.  If the packet was correctly formatted, but just wasn't mapped to a queue correctly, you would simply get a ERROR message response back to the FPGA.  Is this type 9 or type 11?  Type 11 can't have a msglen = 0.  Did you try 8B, that is the min.

    Regards,

    Travis