Start • Ethernet SoC • I've Been Had! • AX110xx Development Kit • Keil's Been Had 2! • Ethernet Module • Serious Stuff • Sources and PDF

ETHERNET MODULE

Now you know which hardware and software tools you’ll need to be successful with the AX11005. Although the AX11005 is a feature-rich microcontroller, my real interest (and hopefully yours) is the AX11005 Ethernet module. With that, let’s take a look at how it works.

The AX11005 Ethernet module consists of a 10/100-Mbps Ethernet MAC and PHY interface. The thing that really makes the module interesting and different is the TCP/IP offload engine (TOE). Thus, the module is based on a trio of submodules: the TOE, the MAC, and the PHY. Module driver source code for the TOE, MAC, and PHY is included with the AX11005 development package. As I showed you earlier, API calls are mingled in with the TOE and MAC driver source code modules.

The TOE submodule handles all of the TCP/IP offload engine functionality. There are two modes in which the TOE code can execute and both of them support TCP/IP, UDP, ICMP, and IGMP hardware checksum functions. Transparent mode doesn’t support the AX11005’s hardware acceleration functionality, but Nontransparent mode uses the services of the AX11005’s hardware acceleration package. Hardware acceleration in this sense is the automatic handling of the Layer 2 ARP Cache, ARP requests, ARP responses, and the automatic processing of IP packet headers in Layer 3 (see Table 1).

If you have studied and written TCP/IP stacks, you know that lots of code time is absorbed in the handling of packet headers as they pass from layer to layer within the stack. The term “automatic” here with relation to Nontransparent mode means that the AX11005 hardware takes care of the headers instead of your software.

When a socket is established, the TOE submodule grinds out a memory segment that includes a buffer descriptor page (BDP), a receive packet buffer ring (RPBR), and a transmit packet buffer ring (TPBR). If you don’t need to modify the buffer sizes, the TOE submodule will allocate 8 KB of RPBR and 4 KB of TPBR memory space. That’s pretty much in keeping with other buffer allocations I’ve made with other Ethernet engines. There’s enough room for a couple of incoming packets and plenty of space to queue up transmit packets as you so desire. The BDP is fixed at one page of 256 bytes. Transparency mode and buffer memory sizes are statically defined using standard #define constructs in the stoe_cfg.h file, which is part of the TOE submodule code set.

A TOE header is employed regardless of the Transparency mode. Every other Ethernet engine I’ve ever worked with has provided the length of the packet and a pointer to the next packet in some type of header arrangement. The AX11005 is no different. The first 2 bytes of the 6-byte TOE contain the pointer to the next packet. The 12-bit packet length follows the next packet pointer. Other information offered up the TOE deals with packet boundaries and the beginning offset address of the packet’s data payload. The final byte of the TOE header identifies the packet’s protocol. The TOE packet protocol byte is identical to the protocol type found in the IP header. If the packet is not an IP packet, the TOE packet protocol byte is set to 0xFF. The application must make sure the correct protocol type is contained within the TOE header to avoid checksum errors.

Transparent mode will leave the Ethernet header intact so that layers of the stack can process it. The Ethernet header will immediately follow the TOE header if Transparent mode is in play. Nontransparent mode will strip the Ethernet header as the AX11005 hardware performs the header operations. The IP header will be placed immediately behind the TOE header when Nontransparent mode has been selected. The data payload will follow the Ethernet header of IP header depending on the Transparency mode that has been selected by the programmer.

It’s the application’s responsibility to populate the TOE header before passing it to the TOE submodule. The TOE submodule will add the TOE header at the beginning of the transmit packet, store the packet to be transmitted in the TPBR, and kick off the mechanism that will transfer the packet to be transmitted from the TPBR to the MAC layer SRAM.

Incoming packets will have the TOE header placed at the front of the packet by the TCP/IP offload engine. The packet is then stored in the RPBR. After the incoming TOE-headered packet in the RPBR, the application can use the TOE submodule’s basic driver and API calls to parse the TOE header and access the packet data.

The MAC submodule is used to initialize the AX11005 MAC and PHY interfaces to enable normal Ethernet packet transmission and reception. The application can use API calls to handle PHY link change events, set up receive filter modes, and enable wake-up functions such as Magic Packet and external pin wake-up.

The PHY submodule has no API call access. The MAC submodule calls any functions performed by the PHY submodule. The PHY submodule primarily checks and retrieves the PHY Media mode for the MAC submodule.

At first glance, the AX11005 driver code seemed a bit confusing. However, there’s nothing going on here that doesn’t go on in similar implementations. Basically, the application code uses TOE and MAC submodule API calls to crank up the hardware driver firmware in the TOE, MAC, and PHY submodules.