Ethernet MAC addresses on the C6678

The base address for all IP's are defined in the Data Manual.  You can find it on the TMS320C6678 product page (first link.)

Best Regards,
Chad

I have that document; the addresses of the MAC registers are not in it as far as I can see.

The closest I can find is a register called MACID1. The description (unhelpfully) only states "value is indeterminate". and "A range will be assigned to this device.". When? By whom or what? From the little information provided and the fact that there are 48 bits, I deduce this holds the MAC address of the device and NOT the base address for the MAC registers.

I tried to be clear in my post by explicitly mentioning some of the registers I am interested in "(including TX0HDP, RX0HDP., RXINTSTATMASKED,...)".

Searching that document does not locate any reference to, for example, TX0HDP. How do I find where these registers are?

If, as I am beginning to suspect, the handling of the Ethernet on these devices is completely different from other C6000 devices (even though the MAC devices are mentioned in , where is the documentation that describes how to access the Ethernet? The document sprugv9b might be relevant, but I cannot find anything in it about actually sending packets.

Ok, let's take a step back.  The Memory Map (table 2-2) of the data manual provides the base address, while the user guides have the specific offsets for the registers.  In the case of the Ethernet related ones that's the Network Coprocessor address 0x0200 0000.  The Network Coprocessor is made up of multiple components, the GigE is one component - It has an addition offset of 0x90000 (see table 2-1 of the NetCP UG SPRUGZ6.PDF) so the base offset for the GigE registers is 0x0290 0000.

Can I ask you what document you're getting the registers you are referring to from?  Specifically TX0HDP, RX0HDP and RXINTSTATMASKED? 

As for the MACID1 and MACID2 registers defined within the Data Manual.  Between them they hold the MAC Address that is programmed into the device.  Each device will have a unique MAC Address as would be expected.

Best Regards,
Chad

I think it's now clear that my suspicion is correct: the 6678 has a completely different Ethernet programming interface to that of earlier processors (such as the 6472). This seems to be in contradiction to the document spruhh1 which describes the same interface as in the 6472 and claims it is for the Keystone architecture. My existing (working) Ethernet drivers are based on that and I was hoping not to have to rewrite them from scratch.

Given this change in mechanism, can you point me at any TI documentation that shows clearly how to send a packet out on the Ethernet and read one back without assuming a raft of existing software? I have read everything I can find and all the documents jump around in either exquisite low-level detail or information-free sound-bytes without giving any functional overview or straightforward examples of how to drive the device. In particular, neither sprugv9b nor spruz6t seem to state how to transmit or receive packets.

I have also looked at what TI source examples I can find but they are all written in such a convoluted fashion that I find it impossible to trace what's going on.

To avoid wasting your time, please note that I use neither CSL nor BIOS.

Regards,

Peter

Peter,

I now see the confusion.  We have Keystone devices with NetCP integrated, where NetCP is incorporates Switch and GigE interface and we have Keystone devices with only an EMAC interface integrated.

The Keystone devices with NetCP integrated such as C6678 and the NetCP uses the GigE interface and NetCP documentation (SPRUGV9 and SPRUGS4) this is the documentation referenced in the Data Manual for the device.  You'll want to use this documentation.  Also, you'll probably want to find the example code provided in the MCSDK for this.

The Keystone devices with EMAC only (no NetCP) which is only the C6657/55/54 devices will use the EMAC UG SPRUHH1.  This is very similar to that used in C6472 but is not what's used on C6678.

Best Regards,
Chad

Perhaps you should make this clear in the relevant documents so others aren't confused.

Just to add to the confusion: http://www.ti.com/lit/ug/sprugs4/sprugs4.pdf

Sorry! We couldn't find your page.

Where is this document?

Also, the examples in the MSDK are far from clear, involving calls to functions for which no source appears to be available.

I have very specific requirements that certainly do not need the layer upon layer of complex software that seems to be involved in all the examples. Perhaps sprugs4 will contain the information I require, but after my experience with other documents in this area, I'm not at all hopeful.

I have managed to locate a copy of sprugs4 and it appears that my fears were justified.

In that document I read "To ease the task of programming the packet accelerator (PA) by abstracting many of the hardware details, a low level driver (LLD) software package has been generated for use with the PA. Included with the PA LLD are firmware images that must be loaded onto the PDSPs before using the PA. Due to interdependencies between the firmware and the PA LLD, all users must use the PA LLD."

As far as I can tell, this is saying that all your users are now required to use BIOS! The whole point of my work is to provide a unified multiprocessor environment that does not involve the unnecessary complexities and inefficiencies of BIOS.

How am I supposed to get access to the Ethernet peripheral without using BIOS?

If you look on the Product Page TMS320C6678 you should find all the relevant documentation.  If you look in the Data Manual, you should find links to all the relevant documentation.

Also, that link is a direct link to an old revision of the SPRUGS4 document.  A generic link to the document that will redirect to the latest version is http://www.ti.com/lit/pdf/SPRUGS4 also putting SPRUGS4 into the search engine on the page will find the document.  This is also the format of the link provided in the Data Manual and should be the same format in all documentation referring to the document.  If you found the link you used in a document, please let me know which one so I can make sure it gets corrected.

Best Regards,
Chad

Google SPRUGS4.pfd and try to follow the first link that appears.

Yes, it looks like Javier posted an direct link (which was actually a valid link in June when he posted it) if you look at the latest UG, it was released in July.  It's a new revision.  Again looking on the product page or the data manual is going to give you the latest version or putting the SPRU# into the search engine will get you the latest version.

I apologize for this, it's easiest to copy paste the link from the browser after opening the document in the browser but what is shown in the browser is the direct link and not the indirect link and so it's often copy and pasted in a reply and it's good until the next version.  This is one of the reason's I ofter refer people to the product page TMS320C6678 as it will always have the indirect link and grab the latest version.

I've also asked Javier to step in on this thread to try to help you out regarding simplified implementation that you've requested.

Best Regards,

Chad

It seems that PA LLD doesn't actually access the Ethernet: "With the exception of some initial setup functions, the module does not communicate directly with the sub-system. The output of the module is a formatted data block along with a destination address". As my data is already formatted, this module seems to be irrelevant.

I am now left with my original question (slightly modified). Given a properly-formatted packet, how do I send it to the Ethernet? Every document I read says a little about the process and then leaves you guessing by assuming you know everything about some other component in the chain. Is there any document anywhere that gives a straightforward picture of how you send packets to the Ethernet without assuming ANY TI software is involved? I'll leave the corresponding problem of reading to later.

The older devices (e.g., 6472) have a fairly clear description of the MAC and its registers, so sending and receiving packets wasn't a problem. With the C6678 it looks like an order of magnitude of complexity (at least)  has been added without the corresponding requirement for a clear description of what's going on.

It seems to me that an overview of the process should have been the very first thing to be documented, and yet, as so often happens, the documentation drops into gory details at the first opportunity. I am left with the feeling that the documents were written to show how much the writer knows and not to satisfy the needs of those reading them. I would be delighted if such a document exists, but I have been unable to find it.

Your reply arrived just as I was making my latest post.

I am grateful to you for passing this on to someone who can give some insight into how the device is supposed to be accessed.

Hi Peter,

I understand that you want to be able to use NetCP in the most straightforward manner as possible. NetCP is a very good as well as complex IP so bear with me here as I try to be as concise yet complete as possible in my explanation.

NetCP is comprised of three major sub-systems: Packet Accelator (UG: SPRUGS4A) , Security Accelerator (UG: SPRUGY6A also referred sometimes as Crypto) and Gigabit Ethernet Switch (UG: SRPUGV9B). There is an additional UG:  SPRUGZ6, which gives the entire overview of NetCP. I recommend starting with this. If you search in google or in TI's advance search for "NetCP spry186" you will also find an intersting white paper on NetCP which explains the philosphy behind the IP. It is not a UG nor it is meant to understand how it is used, yet it is good food for thought you might be interested in.

The Packet Accelarator and Security Accelerator as you will see in the UG's are comprimsed primarily of PDSP processors. These processors run TI proprietary firmware which implement the different features of network classification (PA) and encryption/decryption (SA). Because this firmware is propietary and because it is very complex to use in a "raw register" approach they are accompanied by Low Level Drivers (LLDs). The LLDs are not coupled with BIOS, so you DON"T need BIOS to use them. However, the PA LLD is found inside the MCSDK package, subsequently inside the Product Development Kit (PDK). The SA LLD can be found here http://software-dl.ti.com/sdoemb/sdoemb_public_sw/salld/ (this link should not change, and should be updated as new releases come out). If you have any issues in the near future with this link please let us know so that we can correct it.

These LLD's provide API's to program the PA and SA. Examples, can be found in the LLD directories along with Unit Tests. The Unit Tests are more complete, yet more complex. Thus, I always recommend starting with the examples and as you move forward with your implementation use the unit tests to see how additional features are implemented. Again, any help you need in navigating through them you can let us know.

Unto the Gigabit Etherent. This is the only IP which does not require an LLD. This is a straightforward 3-port switch (2 SGMII, 1 "Host"). It has an Address Lookup Engine which implements the forwarding decisions. To get started with this IP I suggest to look into the PA LLD emacExample. This example can be found on the PDK under [PDK_INSTALLPATH]\packages\ti\drv\exampleProjects. The only caveat of this example is that if you are using the EVM, it does not program the PHY. However, in the post linked below I give instructions on how to modify the code to use the GBE along with the PHY on the EVM's. I provide a self-contained code that programs GBE and I show how to modify the PA emacExample in order to incorporate it (please refer to the June 20'th post). If you wish not to use PA at all and only GBE I can also guide you to modify this example for bypassing PA.

http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/p/196299/700615.aspx#700615

Hope this clarifies your doubts and points you in the right direction.

Sincerely,

Javier

Thanks for the extra information which I shall look at tomorrow.

Perhaps it might help if I explain what I am doing. We produce a multiprocessor/multicore development suite that has been running for over 20 years on processors including the C62, C67, C64...). One of its main strengths is in automatically doing much of the tedious housekeeping associated with multiprocessor work and providing a simple but extremely powerful and flexible model for designing and building applications. I can already generate applications for the C6678 but loading and running them has proven to be a huge problem. Most of the board-level hardware we have targetted in the past has had manufacturer-supplied host interfaces for communication between the processors and the host PC. Where this was not available, we always had the fallback of using a JTAG interface via CCS. Unfortunately with CCS5 the interface no longer works (Java being ditched in favour of JavaScript, and even that being broken). The only other sensible way to talk to the hardware is to use the Ethernet. I already have a loader that is working (modulo problems with the EVM6678L and its failure to be able to send BOOTP packets and load programs with the same switch settings - but that's the subject of a separate set of posts).

All that remains is to achieve communication between the running application and our host server program. All I need is the simplest possible point-to-point link so I can send data between the PC and one processor/core. I don't need or want anything fancy. I already have working Ethernet code for the C6472, so I have the packets I need to send already formatted and so have no need for what I understand to be the functionality of the LLD. Almost all of the remaining functionality will also be of no interest to me: forget encryption and all the other clever things. The simpler the better is my rule. What I really need is to be able to drop packets onto the Ethernet and receive incoming packets with interrupts marking their departure and reception. One of my concerns at the moment is that from what I've read, I get the feeling that double-copying of the data is going to be required; I've seen nothing that hints at the reconstruction of packets from separate fragments as is possible on the 6472 (but that could be the fact that I've seen no low-level information at all in that area). Even if that is needed, it would be better than nothing.

I hope that allows you to suggest the simplest possible solution as all the examples I have looked at so far are orders of magnitude too complicated.

Hi Peter,

I understand you have legacy code from C64x family of products and want to port to C66x (Keystone) family. Keyston architecture is a leap forward in multi-core design. Everything looks a bit more complex, well, because it is, but not without its advantages. One of its main advantages is the introduction of a Multicore navigator or "Packet DMA" that leverages a hardware based queue manager for communicating between cores and heavily shared resources such as the Network Co-Processor. That is why I suggested NetCP SPRY186 white paper as a good read to understand the philosophy behind this IP and this new architecture. I also suggest the Multi-core navigator UG (sprugr9e).

The simple single-port EMAC from C64 products has been replaced in Keystone (except in 6657) with a multi-port Gigabit-Switch sub-system. No longer do we have TX HDP & RX HDP with direct interrupts to the core. The Gigabit-Switch talks to the core thorugh the Multicore Navigator which manages the linked descriptors. There are interrupt mechanisms from the multicore navigator to let the core know when packets are ready for processing, but they do not come directly from the GBE. More on this in sprugr9e UG. Using the multicore navigator does not require the use of an LLD, although it is much eaiser to use with the LLD. Functionalities such as the accumulator firmware to allow for managing of packet arrival into the queues and interrupting the cores does require the LLD.

So, that is why the legacy code from C64x products is not going to work "as is" on C66x Gigabit-Ethernet. Some modification will need to go into the code.

WRT to PA LLD. Certainly you may bypass this IP if you are not interested in using it. I can show you in the emacExample on PA LLD how to do this. However, the functionality of this LLD is not to format 802.3 frames. The real power of PA comes in the from-network direction, It's main purpose is to classify incoming L2/L3/L4 headers and based on user programmed route information it will distribute the packets to different queues. This helps on accelerating the load balancing of tasks (note I say tasks becaue they may or may not necessarily run on multiple cores) as well as accelerating the processing of packets itself. PA LLD goes beyond that and it allows to some extent, the manipultion of packets, extracting information from packets into descriptors, verifying cheksum etc.

Hope this clarifies things for you a bit better. Still I recommend emacExample from PA LLD as a starting point because it already has the constructs for the multi-core navigator and it very easy to plug in the GBE code I provided which is straight raw-register programming. .

Regards,

Javier

Thanks for that. I think "a bit more complex" is quite an understatement. This never-ending and uncontrolled explosion in complexity will, I fear, lead eventually to a train wreck...but that's another story. I am under no delusion that the low-level parts of my code will need to be rewritten; I have got used to having to do that over the years as the C6000 has evolved (DMA -> EDMA -> EDMA3 -> ???, for example, forever adding more features but never addressing the fundamental flaws).

I am now fairly certain that the PA LLD offers me nothing. I have two types of packet coming in from the host to ONE core; no other cores need access to this Ethernet device. As my reading of the various documents suggests that I am going to be forced to double-copy the data (please correct me if I'm wrong) those two types of packet can be combined into one, so classification is a null operation. Also, no load balancing or checksum verification is necessary - if a dedicated point-to-point link is unreliable there's not much point in continuing.

I have looked at the example you suggested and it should be a useful starting point - and much easier to follow when all the *(volatile unsigned int)(base_expression+offset) clutter is replaced with structure accesses!

I would be grateful if you could show me how you would remove the PA LLD from the example.

So, all I need is to be able to write one type of packet to one host address and read one type of packet back (on interrupts).

To understand how the Ethernet is used, I have tried running the example C:\ti\pdk_C6678_1_0_0_21\packages\ti\drv\pa\example\emacExample.

This builds and runs, but generates no observable activity on the Ethernet. It detects no errors during setup and then sends out 10 packets. It then loops forever waiting to receive something - although I'm not surprised nothing comes in.

The Readme file is confusing. It starts: "In order for the example to work successfully, i.e. to be able to send/receive data packets from the wire  the following configuration needs to be done in the simulator:". However, at the end of that file it says: "The deafult test configuration is for silicon only."

I have tried several changes (changing port numbers, MAC addresses, etc.) but nothing makes the Ethernet twitch.

Is this example for the simulator only? Should it work on the real silicon?  Should it put packets on the Ethernet? Is there another example that does put packets on the Ethernet?

but

After a deafening silence on this thread, I have managed to get the example to run. This was by removing all TI software, downloading again, and reinstalling from scratch.

Once the example was running in loopback mode, I tried making it exchange packets with a PC program. The PC sees the correct packets coming from the DSP, but no packets being sent to the DSP are received. Wireshark shows all packets on the wire.

The code of the example has explicit MAC address and other assumptions built into it in several places, and I suspect that one or more is lurking somewhere and causing input packets to be rejected. The complexity of the device makes it extremely difficult to trace everything to see where the packet may be being discarded (if it is being received at all).

Has anyone else managed to get this example to do anything except work in loopback mode? What it the complete list of things that need to be changed to achieve this?

Hey...

I have exactly the same problem....! Did you get your project running?

Hi,

After a lot of messing around I got some cut-down code from TI and managed to massage it into something that was useful to me.

If you would like a copy of the project I ended up with and the corresponding host program (probably too big to post here) drop me an email (psr@3L.com) and I'll send it to you.