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.

C66x sRIO Discovery Timer and Silence Timer Configurations

The discovery timer is specified to be "28 msec +/- 4 msec" for Revision 2.1 and "12 msec +/- 4 msec" for Revision 1.3.
However, it is not described how the DISCOVERY_TIMER register value should be set.

Which clock frequency does the timer value depend upon?

How is the timer value calculated based on the clock frequency and the DISCOVERY_TIMER register value?

Silence timer value is "SRV_CLK period x 410 x SILENCE_TIMER".

What is SRV_CLK? Is it the reference clock, i.e. the clock on the RIOSGMIICLKP/N pins?

Best regards,

Daisuke

 

  • Sorry we need to clean the docs up a bit here, there are legacy references to srv_clk that need to be replaced.  My current understanding is below, but I’m still waiting on confirmation from design.  My only issue is that I can’t get the Discovery timer value in mS to work out with the below equation.

    The discovery timer is set by the PLM_SP(n)_DISCOVERY_TIMER register. ( Note: Values of 0 & 1 are not legal.)  Discovery timer Interval is IP_CLK period X 52429 X DISCOVERY_TIMER.   For rev 2.0 silicon, the IP_CLK is either  a) the internal DMA clock used by the peripheral which is hard coded to CPU fequency/3 or b) it is the fastest of the Serdes based TXBCLKs(1/20th the data rate, i.e. 2.5Gbaud the Serdes TXBCLK is 125Mhz).  The selection of which clock to use here is based on SYS_CLK_SEL and SYS_CLK_VBUSP in the RIO_PER_SET_CNTL1. On pre 2.0 silicon, the IP_CLK is always based on TXBCLK, case b above.  Best performance is using case a above.

    Note also that the RIO_IP_PRESCAL needs to be set correctly for the silence and discovery timers to have the correct values.

    I'll provide more info as I get it.

    Regards,

    Travis

  • Hi Travis,

    I would appreciate your kind cooperation.
    Please continue your support.

    Best regards,

    Daisuke

     

  • Ok, figured it out.  Everything I said above correct, except the equation needs to be modified to read:

    Discovery timer interval =   Prescaled IP_CLK period * 52429 * Discover_Timer,    where the Prescaled IP_CLK period = (IP_CLK period * RIO_IP_PRESCAL value).

    For example, lets say IP_CLK = 156.25Mhz, if I set my RIO_IP_PRESCAL = 16 and Discover_Timer = 5, this yields a Discovery Timer interval of:

    1/156.25e6 * 16 * 52429 * 5 = 26.8mS

    This chart will help pick the value of the prescalar:

    IP_CLK

    Frequency (MHz)

    IP_CLK

    Period (uS)

    RIO_IP_PRESCAL

    Prescaled

    IP_CLK

    period (uS)

    312.5

    0.003

    31

    0.0992

    307.2

    0.003

    31

    0.1009

    250

    0.004

    25

    0.1000

    245.76

    0.004

    25

    0.1017

    156.25

    0.006

    16

    0.1024

    153.6

    0.007

    15

    0.0977

    125

    0.008

    13

    0.1040

    78.125

    0.013

    8

    0.1024

    76.8

    0.013

    8

    0.1042

    62.5

    0.016

    6

    0.0960

    This chart will help you select the Discovery Timer value:

    Default Timer Value (mS)
    12
    28
    Pre Divider
    52429
    52429
    IP_CLK
    Frequency
    (MHz)
    IP_CLK
    Period
    (uS)
     
    Prescale
    Period
    (uS)
    Value for
    12mS
    timer
    Difference
    from 12mS (mS)
    Value for
    28mS
    timer
    Difference
    from 28mS (mS)
    312.5
    0.003
    0.0992
    2
    1.60
    5
    2.00
    307.2
    0.003
    0.1009
    2
    1.42
    5
    1.55
    250
    0.004
    0.1000
    2
    1.51
    5
    1.79
    245.76
    0.004
    0.1017
    2
    1.33
    5
    1.33
    156.25
    0.006
    0.1024
    2
    1.26
    5
    1.16
    153.6
    0.007
    0.0977
    2
    1.76
    5
    2.40
    125
    0.008
    0.1040
    2
    1.09
    5
    0.74
    78.125
    0.013
    0.1024
    2
    1.26
    5
    1.16
    76.8
    0.013
    0.1042
    2
    1.08
    5
    0.69
    62.5
    0.016
    0.0960
    2
    1.93
    6
    2.20
  • Hi Travis,

    Thank you for your kind support. But, some questions remain.

    Does the SRV_CLK mean the Prescaled IP_CLK? If so, the equation of Silence timer interval as follows:

    Silence timer interval = Prescaled IP_CLK period x 410 x SILENCE_TIMER, where the Prescaled IP_CLK period = (IP_CLK period * RIO_IP_PRESCAL value).

    Could you tell me where I can find the SYS_CLK_VBUSP in the RIO_PER_SET_CNTL1? It is not found in the SRIO User's Guide.

    Best regards,

    Daisuke

     

  • Yes you are correct, the silence timer would be treated the same way as the Discovery timer, just a different multiplier.  Your equation is correct.

    SYS_CLK_VBUSP is equivalent to the CPU/3 frequency I mention above.  It is fixed.  So you can choose between that and the TXBCLK frequencies.

    Regards,

    Travis

  • Hi Travis,

    Thank you for your reply.

    How is SYS_CLK_VBUSP chosen?
    SYS_CLK_SEL in PER_SET_CNTL1 register can choose between TXBCLKs, but it can not choose SYS_CLK_VBUSP.

    Best regards,

    Daisuke

     

  • I checked SRIO User's Guide: SPRUGW1B.

  • Bit 9 of RIO_PER_SET_CNTL1 controls this as the following:

    ‘0’ => Used SYS_CLK_SEL to define the clock source SYS_CLK

    ‘1’ => Use vbusp_clk as the clock source for SYS_CLK

    Again, this bit is only valid on rev2.0 silicon and reserved otherwise.

    Regards,

    Travis

  • Hi Travis,

    Thank you for your reply.

    Silicon rev2.0 device has been released, but Bit 9 of RIO_PER_SET_CNTL1 is not described in current SRIO User's Guide "SPRUGW1B".

    Our customer uses the rev2.0 device. They will have a question that Bit 9 is not described in current User's Guide.

    Does next User's Guide describe Bit 9?

    Is '0' the default value of Bit 9?

    Best regards,

    Daisuke

     

  • Yes, it will be in the next rev of doc.  Yes, the default is 0 for bit 9, so it supports the legacy setup with only selecting which TXBCLK to use.

    Regards,

    Travis

  • Hi Travis,

    Thank you for your reply.

    Best regards,

    Daisuke

     

  • Hi all,

    Here is the information about the SRIO Internal Clock.

    http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/248427.aspx

    Best regards,

    Daisuke

     

  • Hello, Daisuke Maeda!

    Thank you for information about SRIO configuration in this threads. I want ask you some question about SRIO registers configuration. Can you tell me that values you set in registers, listed below:

    PER_SET_CNTL =

    SRIO_SERDES_CFGPLL =

    PRESCALAR_SRV_CLK =

    SRIO_SERDES_CFGRX[0-3] =

    SRIO_SERDES_CFGTX[0-3] =

    Daisuke, can you look at this thread (here some details ) http://e2e.ti.com/support/embedded/linux/f/354/t/291192.aspx


    and may be you will give to me some tips or you will asking questions that lead me to solving my problem.

    Thank you!

  • Hi Vladimir,

    I'm sorry but I can't help you because I don't know the registers values used by our customer.
    Most of the registers values that you listed must be appropriate for your board and the values will be different from the values of our customer.

    Can the following documents help you?

    http://www.ti.com/lit/an/sprabi2c/sprabi2c.pdf
    6.5 Serial RapidIO (SRIO)

    http://www.ti.com/lit/an/sprabc1/sprabc1.pdf
    4.3 Recommended SerDes Register Configuration Options
    8 SerDes Configuration common to AIF2, SRIO, and HyperLink

    http://www.rapidio.org/specs/current/rev2.1_spec_stack.zip
    Part 6: Serial Physical Layer Specification (Part6.pdf)

    Best regards,

    Daisuke

     

  • Hi Travis,

    The discovery timer is specified to be "28 msec +/- 4 msec" for Revision 2.1 and "12 msec +/- 4 msec" for Revision 1.3.
    The KeyStone I Devices are RapidIO Interconnect Specification REV2.1.1 compliant.
    For the discovery timer, must "28 msec +/- 4 msec" be always used? Or does it depend on the revision of link partners?

    Best regards,

    Daisuke

     

  • Hi Daisuke,

    Thank you for your answer and links. 

    Vladimir.

  • Hi Travis,

    The discovery timer is specified to be "28 msec +/- 4 msec" for Revision 2.1 and "12 msec +/- 4 msec" for Revision 1.3.
    The KeyStone I Devices are RapidIO Interconnect Specification REV2.1.1 compliant.

    Does the discovery timer depend on the revision of link partners?
    If the revision of link partner is 1.3, is the C66x discovery timer interval set to 12 msec?

    Best regards,

    Daisuke

     

  • This really should be a non-issue with either setting.  I'm not sure of the programmability of all devices, so I would just use the 1.3 number if such a device is being used as the link partner.  Otherwise, use the 2.1 number.

    Regards,

    Travis

  • Hi Travis,

    Thank you for your reply.

    I understand that the same enough discovery timer interval should be used between the link partners and the 1.3 number (12 msec) is enough interval for 2.1 devices.

    Is my understanding correct?

    Best regards,

    Daisuke

     

  • Yes, that is my recommendation, I don't think there should be any problems.  Are you trying this and seeing issues?  If so, you could try setting both to the v2.1 (28ms) setting, but I don't think it should matter.

    Regards,

    Travis

  • Hi Travis,

    Thank you for your reply.

    Our customer does not have any issue about the port initialization. They often see the delineation error.
    They ask this question because they want to meet the SRIO specifications properly.

    I saw the SRIO specifications. When the discovery timer is done, the 4x/2x port initialization fails, that is initialized as 1x port.
    The short timer interval may let initialization always fail. If there is the difference in the timer interval between the link partners, the dead time may be made.

    I could understand that it do not matter.

    Best regards,

    Daisuke

     

  • Your understanding is correct.  When I said it shouldn't matter, I mean the short timer value should really be enough.  A longer timer value is perfectly fine.

    Regards,

    Travis

  • Hi Travis,

    Thank you for your reply.

    Best regards,

    Daisuke