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.

About TMS320DM6446's EMAC

Guru 16800 points
Other Parts Discussed in Thread: TMS320DM6446

Hello,

I have two questions for TMS320DM6446's EMAC.

1. How to know the completion of the receive DMA transfer from EMAC to DDR2 of TMS320DM6446?
   In sprue24b, RXPENDn is "receive packet completion interrupt for receive channels 0 through 7".
   Does it mean that the RXPENDn asserts when DMA transfer completes?

2. Does the RXPEND interrupt assert when the MAC receiver block recognize "End of Packet"?
   I want to know when the RXPEND interrupt assert.

Best Regards,

Nomoto

  • Hi Nomoto-san
    This is an old ip and device, our understanding is that

    There are two registers which become important i
    The Rx channel DMA Head Pointer Register
    The Rx channel Completion Pointer Register


    The RxPend will be set to a 1 when the Rx Descriptor is updated at EOF after the descriptor write data is pushed out of the EMAC boundary on the interconnect . Whether EOQ is set or not. If EOQ is set it indicates that the RxDMA will no longer process descriptors until a write to the Rx channel DMA Head Pointer register is written for that channel.
    The RxPend will be set to 0 if the software acknowledged final descriptor address by writing to the Rx channel Completion Pointer Register and that pointer matches the last Rx Descriptor process by the Rx DMA.

    Hope this helps.

    May I ask why the question and what is the customer issue?

    Regards
    Mukul
  • Hello Mukul-san,

    Thank you for your reply.
    Your answer is very helpful and I told it to my customer.
    If there are some feedbacks from my customer, I will consult you again.

    The background is following:
    - Some commands controlling DM6446 were sent from host via Ethernet port.
    - Coming commands to DM6446 were transferred from EMAC to DDR2 by DMA.
    - My customer read DDR2 data by software just after RxPend interrupt (No check of EOQ or EOP).
    - There was no issue before updating firmware.
    - However, after updating firmware (EMAC firmware is not updated), reading DDR2 data timing is faster than transferred data timing from EMAC to DDR2 sometimes.
    - It seems that data transfer is delayed by updating firmware. Maybe, the bus collision occurs by updating firmware.
    - My customer thinks that RxPend interrupt is not enough to know the timing of data transfer from EMAC to DDR2.
    - Then, my cunstomer wants to know when data is arrived at DDR2.

    Best Regards,

    Nomoto

  • Hello Mukul-san,

    Can we read the correct data which is transferred from EMAC to DDR2 surely by checking EOQ bit?
    My customer wants to know the trigger to read the data transferred to DDR2.
    Also, could you explain the sequence how is the data transferred from EMAC (data receive via port) to DDR2?
    (For example, the timing of EMAC data receive, RXPEND interrupt, DMA transfer, End of Queue (EOQ) and data read from DDR2.)

    Best Regards,

    Nomoto

  • It would be good to understand what software customer is using and also where are the EMAC descriptors located (in EMAC RAM or DDR).

    Following are the responses to your new questions to the best of our ability

    Q: Can we read the correct data which is transferred from EMAC to DDR2 surely by checking EOQ bit?
    A: The EOQ bit is an indication that the Rx DMA read the next pointer on this list and it was ‘0’ so the Rx DMA will be stopping after this update.
    It does indicate that all previous data was written, but does not guarantee it landed in DDR if the descriptors are in the EMAC internal RAM (not in DDR)
    Once the EOQ bit is set, any future frames received prior to writing a descriptor to the Rx DMA will be dropped.
    The ownership bit is the correct bit to use to see that the frame for this descriptor has been written.

    Q: We want to know the trigger to read the data transferred to DDR2.
    A: As previously described, when the ownership bit is clear, the descriptor write is complete, and the descriptor data is valid.
    If the frame data was written to the same area (EMAC RAM or DDR) the data is guaranteed to be complete.
    But if the descriptor is in the internal, and the frame data is in the DDR,
    there is a possibility that the data has not landed in the DDR even though the Descriptor write is complete (this can be due to interconnect contention, cache activity etc)

    Things that can help on to make this more robust
    1) Set the priority of EMAC to be higher than the CPU priority (Lower number), this would help such that the EMAC data is written prior to the CPU read.
    2) Place descriptors in in the same memory where the packet will be stored, this guarantees that the previous data is written
    before the CPU can access the descriptor.

    Also, could you explain the sequence how is the data transferred from EMAC (data receive via port) to DDR2?
    (For example, the timing of EMAC data receive, RXPEND interrupt, DMA transfer, End of Queue (EOQ) and data read from DDR2.)

    Not sure what you need here , it will be very difficult to give anything beyond what I have below - it is better to focus on the problem in my opinion
    Receive processing of a single descriptor frame:
    1) Descriptor is read
    2) …
    3) When frame arrives, DMA data to Descriptor pointer
    4) At EOF The last DATA is written
    5) If Descriptor forward pointer is zero, re-read descriptor forward pointer.
    6) If pointer is still zero, DMA SOP, EOP, EOQ and frame length to Rx descriptor else DMA SOP, EOP and frame length to Rx descriptor
    7) When Descriptor DMA completes, set RxPend state.
    8) The interrupt will be generated if pacing allows it.

    From the EMAC point of view, the DATA DMA will always be complete prior to the Descriptor DMA since they use the same interface.
    But if the packet data is in DDR and the descriptor is in the EMAC RAM,
    there is a possibility that the DDR contents is not updated until the bridge gets its turn on the main SCR.