• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 99 subscribers
  • Views 1487 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.

C6748 EMAC cores

Dean Hofstetter
Expert 2585 points

Other Parts Discussed in Thread: SYSBIOS, OMAP-L138

We are attempting to use the NDK in an data center environment, therefore we need high reliability and up time.  I'm attempting to understand the NSP for the C6748, as it was written a long time ago and is poorly documented (and poorly written in my opinion).

DSP = C6748
NSP = 1.10.02.09
NDK = 2.24.02.31  (not that it really matters)
SYSBIOS = 6.37.05.35
CCS = V5.5

I've started this question in the C6000 single core forum because they deal directly with how the EMAC works.  Feel free to move to TI RTOS forum if you think that will generate better answers.

1.  C6748 Tech Reference Manual says there are (3) interrupt cores within the control module.  Why (3) interrupt cores?

2.  These (3) interrupt cores are supposed to be mapped into the C6748 Interrupt event IDs.  Core 0 has Interrupt IDs 26 to 29, Core 1 has interrupt IDs 30 to 33, and Core 2 appears to be missing.  What am I missing?

3.  The NSP defines CORENUM = 1, so it appears the NSP/NDK only need 1 of the 3 interrupt cores enabled to do its thing.  Why Core 1 vs. Core 0?  Does it matter?

4.  In addition to the (3) interrupt cores being confusing, the RX and TX side of the EMAC control has 8 channels each.  Why 8 channels for RX and TX?

5.  Through a long and complicated trip through the NSP code, it appears that it only enables 1 channel for both the RX and TX (RXCH1EN and TXCH1EN).  Why only 1 channel, and why channel 1?

Thanks, Dean

  • 0
    TI__Guru* 84110 points
    Dean,

    Since you have very precise questions, it will make support better if you can reference the exact places in a specific document version so we can know the details and context around your questions. It could help some of us, at least.

    It is unlikely that we will have a design team who will be able to answer your questions about 'why' things were designed the way they were done. The C6748 was designed and NDK written long enough ago that there is a lot of user history behind them. This will be our strongest tool to help with your confidence in the reliability of this system in your application. But 'why' will be up to differing interpretations, at best.

    If I understand question #4 correctly, you are referring to the hardware capability of the EMAC to match MAC addresses to 8 Rx and 8 Tx MAC IDs. If I am finding the right question, then the answer to 'why 8' would have to be that it was arbitrarily chosen as a useful number that fit the design constraints and requirements at the time of the design. It could have been 4 or it could have been 16, or any other number, but 8 was chosen as a useful number. I am not sure of any value for your reliability concerns for us to decide on a better number that might have been used instead. If you disagree, please correct me.

    Regards,
    RandyP
  • 0 in reply to RandyP
    Expert 2585 points

    Randy,

    Let me ask the questions slightly differently to see if will help.

    1.  The EMAC controller has (3) interrupt controllers.  The NSP for the C6748 uses core #1.  As far as I can tell the other interrupt cores are unused and not needed (at least for the C6748 implementation).  Is there anything special about core #1?  Why was that chosen over core #0 or core #2?

    2.  This question seem pretty straight forward.  The EMAC has (3) interrupt cores, and according to section 17.2.5.3 in the C6748 Tech Reference manual, "Interrupt in the EMAC control module are routed to three independent interrupt cores which are then mapped to CPU interrupt controllers".  Fast forward to section 6.7.1 in the C6748 datasheet, and I can find the interrupt event IDs for EMAC cores #0 and #1.  Core #2 appears to be missing.  Why?

    3.  Basically repeating the same question as #1.  The C6748 NSP selects core #1, but there is no documentation on why.

    4.  If my system is a single Ethernet PHY, single Ethernet MAC address, would I ever need to activate more than 1 RX / TX channel?  Are the additional channels provided in case you design a system that has multiple Ethernet PHY's (and thus multiple Ethernet MAC addresses)?

    5.  Basically repeating the same question as #4.

    I'm trying to understand the EMAC hardware as best I can before I move questions over to the TI-RTOS forum to discuss certain areas of the NSP code.  The NSP code is required to get the NDK working, yet seems to be an after thought as far as documentation.  The C6748 NSP code looks like it was ripped from some other silicon part, and just enough changes were made to get it working on the C6748.  Comments don't match the code, weird references in the code/comments, memory leaks (see EmacInit), lack of call back functions when error occur (see StatusUpdate), etc.  I could go on and on, but the NSP handed to us from TI is more of a guide on how implement the low level NDK driver for the C6748.  It works, but isn't pretty, and appears to flat out wrong in certain areas.  I need to understand all of these issues if we are going to put the NDK in a 24/7/365 data center environment.

    Thanks, Dean

  • 0 in reply to Dean Hofstetter
    TI__Guru* 84110 points

    Dean,

    After this reply, I will try to stay silent on this thread so you can get better help from someone who knows the EMAC better, if available. Whether you will get software design philosophy questions addressed, I do not know. If you are already working with a TI sales representative or FAE, they may be able to help with addressing your issues more than I can; if not, then stay the course here for best results.

    Dean Hofstetter said:
    If my system is a single Ethernet PHY, single Ethernet MAC address, would I ever need to activate more than 1 RX / TX channel?

    No.

    Dean Hofstetter said:
    Are the additional channels provided in case you design a system that has multiple Ethernet PHY's (and thus multiple Ethernet MAC addresses)?

    Yes, that is a good example of a case where multiple channels would be used.

    If you have identified bugs that need to be addressed, please itemize them separately with enough detail for someone to duplicate and fix the bugs. We will appreciate that very much, as will many other users.

    Regards,
    RandyP

  • 0 in reply to RandyP
    Expert 2585 points
    Randy,

    Thanks for your attempts at answering my questions. I believe you've cleared up the 8 Rx/Tx channels question, and since my application is single PHY / single MAC address, 1 Rx/Tx channel will do. It also appears it doesn't matter which Rx/Tx channel is selected.

    As far as my questions about the EMAC interrupt cores, I tried changing the C6748 NSP code to use core 0 instead of the default core 1. After changing the #define, and the Rx/Tx interrupt ID's for the hardware interrupt vectors, it appeared to work just fine. So core 0 or core 1 doesn't matter. Core 2, while mentioned in the Tech Reference manual, doesn't seem to be supported on the C6748. There are no corresponding core 2 EMAC interrupt ID's found in the interrupt table. So I'm unable to test if core 2 is even installed in the C6748.

    My guess is the EMAC for the C6748 was copied from some existing multicore DSP that had at least 3 cores. Maybe the C6474 or the C6472? Maybe the C6748 EMAC silicon block really does have (3) cores, but they failed to hook up all (3) cores at the interrupt vector level. That way the C6748 Tech Manually is correct, and so is the C6748 datasheet.

    Still can't figure out why you would want multiple DSP cores getting interrupts from 1 peripheral. Take the OMAP-L138, which is pin compatible with the C6748. Maybe the DSP side of the L138 handled all the EMAC interrupts and packet processing, and the ARM side of the L138 just wanted to know what was happening, but didn't act on any packets (no EMAC register reads or writes). Maybe the DSP handled all the RX/TX EMAC packets, and the ARM handled the misc interrupts. Who knows?

    I've got enough answers on my low level deep dive into the EMAC that I can now move on to the NSP code in the RTOS forum.

    Thanks, Dean
  • 0 in reply to Dean Hofstetter
    TI__Mastermind 35645 points

    Hi,

    Glad to receive your opinion in attempting your queries
     
    Thanks for your update.

    Regards,
    Sivaraj K