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.

AM571x silicon errata

Other Parts Discussed in Thread: AM5718

Hi,

I have some questions regarding AM5718 silicon errata.

1. i906   USB3.0 and PCIe Gen2 Electrical Compliance:
   It is written "PCIe Gen2 transmitted signals may slightly exceed the jitter requirements of the electrical specification. " in errata.
   1-1) How is violation of jitter requirement of PCIe Gen2?
   1-2) How about PCIe Gen1 electrical compliance? Is it still violation?
   1-3) Will this errata be fixed by next silicon revision?
  
2. i870   PCIe Unaligned Read Access Issue:
   2-1) If workaround 2. is used, what demerit is expected?
   2-2) Will this errata be fixed by next silicon revision?

3. i909   PCIe Unintentional Translation of Outbound Message TLPs
   3-1) Will this errata be fixed by next silicon revision?
  
4. i878   MPU Lockup with Concurrent DMM and EMIF Accesses:
   4-1) Please show me concrete instance for understanding this issue.For example,MPU writes to EMIF when PCIe, GMAC or DMAC access to EMIF frequently.  
   4-2) In what situation, was this errata occurred ? How access level(percentage?) is needed to reproduce this errata?
   4-3) will this errata be fixed by next silicon revision?
  
5. i899   Ethernet DLR is Not Supported
   5-1) Will this errata be fixed by next silicon revision?

I appreciate your quick reply.

Best regard,

Michi

  • I will forward this to the AM57X team.
  • Hi,

    We don't have information about the plans for future silicon revisions.

    I have contacted the design team to elaborate on your questions. I will update the thread with their feedback as soon as I get any.

    Best Regards,
    Yordan
  • Hi,

    Here is the feedback to the 4th question:
    4. i878 MPU Lockup with Concurrent DMM and EMIF Accesses:
    4-1) Please show me concrete instance for understanding this issue.For example,MPU writes to EMIF when PCIe, GMAC or DMAC access to EMIF frequently.

    The primary use case which matches errata description deals with the MPU making writes to DDR through a configured dmm-tilier aperture SYS path (0x60000000-0x7fffffff) and making concurrent accesses through the MPU’s MA-EMIF path (0x80000000—0xffffffff). If a possible coherency conflict (true or false) is flagged there is the possibility of a deadlock if the MPU is slow to provide its data phase on the initial write.

    The DMM registers are added to the errata as the MPU also accesses the DMM/L3 space on its SYS path which may have a side effect which could conflict with an MA path write.

    4-2) In what situation, was this errata occurred ? How access level(percentage?) is needed to reproduce this errata?
    This issue was seen in heavy graphics use cases where MPU-MA and MPU-DMM-Tilier accesses were happening. The fail time normal use cases was very sparse (many hours or days). A directed pathological use case could be made to fail in a few minutes by writing problematic patterns in a loop.

    4-3) will this errata be fixed by next silicon revision?
    No.
    This exact failure is rare in full HLOS software. With work arounds discussed it has not been reproduced.

    Best Regards,
    Yordan
  • Hi, 

    Another one of the designers sent their feedback: 

    Michi Yama said:
      
    5. i899   Ethernet DLR is Not Supported
       5-1) Will this errata be fixed by next silicon revision?

    "Not currently planned.
    I am waiting the PCIe designers to confirm about the first three questions. 

    Best Regards, 
    Yordan
  • Dear Yordan-san,

    Thank you for your support.

    I would like to ask more quetion to you regarding " i878 MPU Lockup with Concurrent DMM and EMIF Accesses:"

    >> 4-2) In what situation, was this errata occurred ? How access level(percentage?) is needed to reproduce this errata?
    >This issue was seen in heavy graphics use cases where MPU-MA and MPU-DMM-Tilier accesses were happening.
    > The fail time normal use cases was very sparse (many hours or days). A directed pathological use case could be
    > made to fail in a few minutes by writing problematic patterns in a loop.

    If heavy graphics transaction is not seen, does this issue never happen ? Then my customer says that the fail time is many hours in normal use case is high frequency. Could you let me know how percentage of this faiure occurrence?

    >> 4-3) will this errata be fixed by next silicon revision?
    >No.
    >This exact failure is rare in full HLOS software. With work arounds discussed it has not been reproduced.
    How about "Integrity OS"? Is the failure rare in IntegrityOS? My customer think to use Integrity with Am571x.

    I appreciate your quick reply.

    Best regards,
    Michi