• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 219 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.

AM67: AM67 Asynchronous Synchronous Clocking

Nicolas Rancher
Prodigy 115 points

Part Number: AM67

Hello my team is interested in using Asynchronous and Synchronous clocking for SERDES.
How is this appropriately defined in the TRM? I assume that asynchronous clocking utilizies
Separate Reference Clock with Independent Spread (SRIS) and Synchronous is defined by the Common Reference Clock? (I am assuming this defined/handled by the Common Module?).
Am I correct in my assumption, or is there no actual Synchronous clocking for SERDES?

  • 0
    TI__Expert 7245 points

    Greetings Nicholas,

    The SerDes instances themselves are used as a part of an actual interface as essentially a PHY, they're not intended to be used in isolation. I would recommend browsing section 12.2.3.1 SerDes Overview in the AM67 TRM for a general overview. This section has diagrams showing that SERDES0 is muxed between the SGMII2 instance and the USB1 instance (for USB3.0), while the second instance SERDES1 is muxed between PCIe0 and SGMII1. To your question on clocking options, this depends on the actual protocol and if the controller supports it.

    Take for example PCIe0, which is discussed in the previous section 12.2.2 Peripheral Component Interconnect Express (PCIe) Subsystem. In the features portion, you can see that this IP supports Separate Reference Clock with Independent Spread (SRIS). I'm not sure what you mean by "Common Module", I'm assuming you mean some external clock generator? You could also feed a clock on a board to the SoC and whatever device is hooked up on the other end to have a common clock shared between them. The answer for your situation will likely be dependent on what protocols you want to use along with any board design constraints.

    You will also need to be sure your software is in sync with your design choices for what clocking options are expected or supported in any protocol drivers. If you have a software base you're interested in (I believe for this device we have Linux and Android SDKs), I'd recommend filing a targeted ticket asking about driver features or support if the documentation does not have answers for you.

    Sincerely,

    Lucas

  • 0 in reply to Lucas Bowe
    Prodigy 115 points

    From what I am understanding the AM67 can support both? Meaning the SRIS is asynchronous clocking whilst the common clock module is the synchronous clocking. Here are details about the common clock module that is provided in the overview...
    I had not responded in sometime as I believed I had resolved this.

    This is the shot I have from the overview. 

  • 0 in reply to Nicolas Rancher
    TI__Expert 7245 points

    Greetings Nicolas,

    It's probably easier to think of it like below, using PCIe as an example. These are your clocking options:

    1. The SoC and endpoint device run on separate reference clocks (each still PCIe compliant reference clocks, just not supplied from the same source). This clock can be with SSC (SRIS) or without SSC (SRNS). 
    2. The SoC and endpoint device run on the same reference clock which can be with or without SSC. The clock is supplied from an onboard clock generator (which needs to supply a PCIe compliant clock) and fed into both devices.
    3. The SoC and endpoint device run on the same reference clock which can be with or without SSC. The PCIe compliant clock is supplied from the SoC SERDES REFCLK pins, which is then fed into the endpoint device.

    You can only use one of these options at a time, as each have board design implications (whether to route a clock generator, route a connection from the SoC direct to the endpoint, etc.). Option 1 would be asynchronous while 2 and 3 are synchronous. It's likely the choice you ultimately make will depend on whichever protocols you want use along with any board design constraints.

    Sincerely,

    Lucas