• State TI Thinks Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 3 answers
  • Subscribers 98 subscribers
  • Views 532 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.

AM6548: Test with AM6548 and DP83640 configuration

Kanae
Guru 10085 points
Part Number: AM6548
Other Parts Discussed in Thread: DP83640, AM6442

Hi Support Team,

If a test like Application Report (SNLA098A) is tested with AM6548 and DP83640 configuration,
will the results be equivalent to Application Report (SNLA098A)?
Please  let me know as I do not understand if there are any factors that could change the results,
such as the MAC specifications of AM6548.
CPSW of AM6548 is IEEE1588 compliant, so I expect equivalent results, but is this understanding correct?
　
Also, I have been researching regarding IEEE1588-PTP and have a concern.
How exactly should 1-second in "IEEE 1588 PTP Synchronization Interval"
in Table 1 of the Application Report (SNLA098A) be produced?
If it is supported by the PTP function of AM6548, then there is no problem,
but if it is controlled by software or other means, it is difficult to execute an exact 1-second interval.

Best regards,
Kanae

  • 0
    Guru 10085 points

    Hi Support Team,

    Please inform me about the above question just in time for an answer,
    as it is an important point for our customer to select a device for the next development project.

    Best regards,
    Kanae

  • 0 in reply to Kanae
    Guru 10085 points

    Hi Support Team,

    There is a post at the following site that says
    "You can use any MAC really since the PHY will be doing the HW timestamping.
    However, you need to ensure that the uC you use has IP stack with 1588 capability.
    Please check with our processor group in their forum on a recommended eval board
    and CCS build to run this    ."

    https://e2e.ti.com/support/interface-group/interface/f/interface-forum/782261/dp83640-register-dump-for-snla098a-and-snoa548a

    Am I correct in understanding that the AM6548 MAC (CPSW) is a recommended device since it supports IEEE1588?

    If not recommended, please let me know if there are other devices that would work best.

    Best regards,
    Kanae

  • 0 in reply to Kanae
    Guru 10085 points

    Could someone please support about this thread?

    Kanae

  • 0 in reply to Kanae
    TI__Guru** 116170 points

    I apologize that it is taking us a while to prioritize this E2E thread but currently this is a resourcing issue where out networking experts are tied up until the end of this month.  The application notes referred to in the E2E seems to be created by the PHY team prior to AM65 silicon being available.

     

    For AM65x specific implementation, I would refer to the PTP documentation in the Linux SDK documentation:

    PTP using CPSW/CPTS: https://software-dl.ti.com/processor-sdk-linux/esd/AM65X/07_01_00_17/exports/docs/linux/Foundational_Components/Kernel/Kernel_Drivers/Network/CPSW2g.html

     

    PTP using ICSS/IEP:

    https://software-dl.ti.com/processor-sdk-linux/esd/AM65X/latest/exports/docs/linux/Industrial_Protocols_PTP.html?highlight=ptp

     

    In both the CPSW and ICSS based PTP implementation, the time stamping is done using HW .  The capability is tested using DP83867 which is a newer PHY.

     

    While AM65 can be used for this application, I would recommend the customer to consider using AM6442 device over AM6548. This devices is 16nm part and is supported with latest Linux software offering. It is a more cost and power efficient solution compared to AM65 unless there is some IO functionality that is missing on the AM64x.  

  • 0 in reply to Kanae
    TI__Guru** 116170 points

    I apologize that it is taking us a while to prioritize this E2E thread but currently this is a resourcing issue where out networking experts are tied up until the end of this month.  The application notes referred to in the E2E seems to be created by the PHY team prior to AM65 silicon being available.

     For AM65x specific implementation, I would refer to the PTP documentation in the Linux SDK documentation:

    PTP using CPSW/CPTS: https://software-dl.ti.com/processor-sdk-linux/esd/AM65X/07_01_00_17/exports/docs/linux/Foundational_Components/Kernel/Kernel_Drivers/Network/CPSW2g.html

     PTP using ICSS/IEP:

    https://software-dl.ti.com/processor-sdk-linux/esd/AM65X/latest/exports/docs/linux/Industrial_Protocols_PTP.html?highlight=ptp

     

    In both the CPSW and ICSS based PTP implementation, the time stamping is done using HW .  The capability is tested using DP83867 which is a newer PHY.

     While AM65 can be used for this application, I would recommend the customer to consider using AM6442 device over AM6548. This devices is 16nm part and is supported with latest Linux software offering. It is a more cost and power efficient solution compared to AM65 unless there is some IO functionality that is missing on the AM64x.  

  • 0 in reply to Rahul Prabhu
    Guru 10085 points

    Hi Rahul,

    Thank you for your support.

    From your reply, I understand the following details.

    1.DP83867 has HW timestamps and has been tested with DP83867 in CPSW and ICSS based PTP implementations.

    2.For CPSW and ICSS based PTP implementations, it is recommended to use AM6442 rather than AM6548.

    3.AM6442 is supported by the latest Linux software.


    Please let us know the following points of concern regarding the above answers.

    Q1.I think DP83867 does not have the function to output PPS signal from GPIO.
    Is this understanding correct?

    Q2.Judging from the diagram in the PTP using ICSS/IEP, it seems that the PPS signal is assumed to be output from AM6548 or AM6442.
    Is this understanding correct?

     PTP using ICSS/IEP:
    https://software-dl.ti.com/processor-sdk-linux/esd/AM65X/latest/exports/docs/linux/Industrial_Protocols_PTP.html?highlight=ptp

    Q3. When outputting the PPS signal from the PHY, DP83640 should be selected.
    Is this understanding correct?

    Q4. Regarding the Linux SDK documentation, I think the Linux Kernel is the same for both AM65x and AM64x,
    Is this understanding correct?
    If Not, are you talking about anything other than the Kernel of the latest Linux software?

    Q5 Also, the following are the details that have been confirmed at present stage.
    In this case, AM64x does not have DSS, so I think it is reasonable to choose AM65x.
    Is this understanding correct?

    OSPI: Boot-ROM and connection.
    DDRSS: Connects to DDR3L or LPDDR4.
    GPMC: Connects to FPGA.
    DSS: Connects to LCD (RGB or MIPI).
    I2C: Connects to RTC, CODEC, PLL devices, etc.
    MMCSD: Connects to Wi-Fi modules (SDIO).
    UART: Connects to GPS modules.
    SERDES: Connects to USB-SATA Bridge devices (USB3).
    CPSW2G: Connects to PHY (LAN to PC).
    PRU_ISSG (x2): Connects to PHY for PTP (2 ports required).
    GPIO: Connects to switches, etc.
    ADC: Supply voltage monitoring.

    Best regards,
    Kanae

  • 0 in reply to Kanae
    Guru 10085 points

    Hi Rahul,

    Thank you for your support.
    Please inform me that I need to report back to the customer just when you will reply to me.

    Best regards,
    Kanae

  • 0 in reply to Kanae
    TI__Mastermind 40080 points

    Hi,

    Here some answers to your questions:

    Q1.I think DP83867 does not have the function to output PPS signal from GPIO.
    Is this understanding correct?  That is correct, the itself will produce a PTP signal.

    Q2.Judging from the diagram in the PTP using ICSS/IEP, it seems that the PPS signal is assumed to be output from AM6548 or AM6442.
    Is this understanding correct? That is correct.

    Q3. When outputting the PPS signal from the PHY, DP83640 should be selected.
    Is this understanding correct? Please see answer to Q1, the PHY cannot produce a PPS signal.

    Q4. Regarding the Linux SDK documentation, I think the Linux Kernel is the same for both AM65x and AM64x,
    Is this understanding correct?
    If Not, are you talking about anything other than the Kernel of the latest Linux software?

    The Linux kernels for the devices are from the same source tree. There will be different kernel configuration files and some of the peripherals and thus the drivers can be different. The other consideration is the kernel are at different revisions between the two devices due to different release SDK dates. 

    Q5 Also, the following are the details that have been confirmed at present stage.
    In this case, AM64x does not have DSS, so I think it is reasonable to choose AM65x.
    Is this understanding correct?  There are several interfaces listed in the question. If USB3 and a DSS are required then the AM65x is the one you should use.

    Best Regards,

    Schuyler

  • 0 in reply to Schuyler Patton
    Guru 10085 points

    Hi Schuyler,

    Thank you for your reply.

    Regarding your answer to Q4,

    Schuyler;
    The other consideration is the kernel are at different revisions between the two devices due to different release SDK dates. 

    I cannot find anything different when I check the latest SDK release notes for AM64x and AM65x below.
    What do you mean by differences in revisions?

    AM65x:
    software-dl.ti.com/.../Release_Specific_Release_Notes.html

    AM64x:
    software-dl.ti.com/.../Release_Specific_Release_Notes.html

    Best regards,
    Kanae

  • 0 in reply to Kanae
    TI__Mastermind 40080 points

    Hi,

    You are correct, my mistake. Both SDKs are using the same kernel release tag, kernel commit id etc. as you have pointed out. 

    Best Regards,

    Schuyler

  • 0 in reply to Schuyler Patton
    Guru 10085 points

    Hi Schuyler,

    Thank you for your reply.

    Then I understood that the only difference between AM64x and AM65x SDKs is
    that the kernel configuration files, peripherals and drivers may be different.

    I will share the above answer with my customer.

    Best regards,
    Kanae