• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 98 subscribers
  • Views 1133 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.

Keystone SRIO control symbol

KAZUHITO KONDO
Intellectual 285 points

Hello,

Could you tell me SRIO control symbol for Keystone?

I inspected a wave form of SRIO output data from Keystone by the digital signal analyzer. I saw the control symbol which is enclosed by blue line in attached file. It's "K28.0 80 E3 87". Sometimes I can see it after PORT_OK.

"K28.0" is written the following description by SRIO-UG/2.1.2.3 Control Symbols. "This use of special characters provides an early warning of the contents of the control symbol." Does an early warning mean low signal integrity?

Also "80 E3 87" seems that the stype1 in 2nd byte is '011' and the cmd in 3rd byte is '100'. The stype1 is Restart-from-retry, but the cmd is Reserved. I didn't see that cmd is '000'. What does it mean?

Regards

  • 0
    TI__Genius 13235 points

    Hi Kazuhito, 

    You can find further description of the control symbols in the Rapid IO Part 6: LP-Serial Physical Layer Specification. This can be found in revision 2.1 for TI's implementation.

    RapidIO specifation page: http://www.rapidio.org/specs/current

    RapidIO revision 2.1 (direct link): http://www.rapidio.org/specs/current/rev2.1_spec_stack.zip

    KAZUHITO KONDO said:
    "K28.0" is written the following description by SRIO-UG/2.1.2.3 Control Symbols. "This use of special characters provides an early warning of the contents of the control symbol." Does an early warning mean low signal integrity?

    K28.0 is a special character that signifies a 'start of control symbol'. This character delimits a control symbol that does not contain a packet delimiter.

    KAZUHITO KONDO said:
    Also "80 E3 87" seems that the stype1 in 2nd byte is '011' and the cmd in 3rd byte is '100'. The stype1 is Restart-from-retry, but the cmd is Reserved. I didn't see that cmd is '000'. What does it mean?

    Based on the Rapid IO spec, it looks like the cmd should be 0b000 for stype1 0b011 (restart-from-retry), as you stated. I noticed you mentioned 'low signal integrity' in your post, is this something you believe your system is encountering? Could this be causing an error in the data captured?

    I'll research further to determine what having a cmd value not equal to 0b000 for the restart-from-retry (0b011) stype1 means. Let me know if you have any addition information to provide on this issue in the meantime. If you have any other questions, feel free to post those as well.

    Thanks,

    Clinton

  • 0 in reply to Clinton Rodgers
    Intellectual 285 points

    Hello Clinton

    Thank you for your kind reply.

    It seems that there aren't any errors and retries. Sending K28.0 and sending restart-from-retry don't mean low signal integrity, do they?

    I have never seen 0b000 for cmd in stype1 0b011, but I sometimes see 0b100 for cmd in restart-from-retry after PORT_OK. I'd like to know reason why sending 0b100.

    Regards,
    Kazuhito

  • 0 in reply to KAZUHITO KONDO
    TI__Genius 13235 points

    Hi Kazuhito,

    A cmd value of0b100 does seem unusual for an stype1 0b011 (Restart-from-retry). As stated in the documentation, cmd should be 0b000 for that stype1.

    Could you provide some insight into how you are capturing the SRIO data? Do you have a digital signal analyzer that can perform the 8b10b decode? This is how the packets are coded at the physical layer when they are transmitted.

    Could you also provide some more details into your setup?

    1. Which Keystone device are you using?
    2. What is the Keystone device connected to?
    3. What code are you running on the devices?
    4. Where are you taking these measurements?

    Thanks,

    Clinton

  • 0 in reply to Clinton Rodgers
    Intellectual 285 points

    Hi Clinton,

    We use Digital Signal Analyzer performing the 8b10b decode.

    The device is TCI6614 connected to FPGA. The software is based on SRIO example code in PDK. The measuring point is between FPGA and AC coupling condenser. It means FPGA is receiving side.

    Regards,
    Kazuhito


  • 0 in reply to KAZUHITO KONDO
    TI__Genius 13235 points

    Hi Kazuhito,

    Thanks for the additional information. Which SRIO example are you using? Which PDK version do you have?

    You also mentioned that you sometimes see this after a 'port ok', can you comment on the frequency of how often you see this control symbol? Have you seen any other symbols that appear corrupted? Does the example work? Is there any unexpected behavior that occurs in the example?

    I'm researching what the implications of the cmd field not being 0b000 for an stype1 of 0b011.

    Thanks,

    Clinton

  • 0 in reply to Clinton Rodgers
    Intellectual 285 points

    Hi Clinton,

    Thanks a lot. It turned out that a root source is in FPGA. FPGA sent illegal response to Keyston. Then Keystone sent corrupt control symbol. I can't understand Keystone sent corrupt control symbol. But fixed FPGA and Keystone behaved correct communication. I think it's OK.

    Regards
    Kazuhito