Circuit Cellar
 
2006-12-31   Ethernet on a Chip
 
  Circuit [2006-12-31]
报导内容:
This month, Fred describes his recent work with the ASIX Electronics AX11005 development kit. Using a Keil C compiler and some Digital Core Design hardware, he created a powerful Ethernet development suite that now enables him to produce some pretty exciting Ethernet-based equipment.

by Fred Eady

Start • Ethernet SoC • I've Been Had! • AX110xx Development Kit • Keil's Been Had 2! • Ethernet Module •Serious Stuff • Sources and PDF I recall standing in a room full of Token Ring equipment some years ago and one of my coworkers looked at all of the new stuff we had just installed and said, “Ethernet is dead.” We both should have turned around and took a closer look at the new Ethernet stuff the other guys were installing on the other side of the room. Why? That “dead” Ethernet equipment is still in use to this day, while the Token Ring stuff is nowhere to be found.

Ethernet technology has come a long way since then. It has become faster and can travel over many types of media. In essence, the core of Ethernet technology hasn't really changed that much over the years. However, the way Ethernet is used changes daily. For instance, Ethernet is now being incorporated into embedded devices just as regularly as RS-232. In fact, Ethernet is more and more becoming a familiar resident on microcontroller silicon. We're all watching the Ethernet-on-microcontroller revolution happen with all-in-one parts emerging from Microchip Technology, Freescale Semiconductor, and ASIX Electronics, to name only a few.

Thanks to the folks at ASIX Electronics. During this go-round, I got to take a look at its new AX110xx development kit, which is based on the new AX11005 single-chip microcontroller with TCP/IP and 10/100-Mbps fast Ethernet MAC/PHY.

ETHERNET SoC

The AX11005 is designed to do a bit more than just service Ethernet frames. The core of the AX11005 is a fast (up to 100 MHz) 100% binary-compatible clone of the venerable 8051. The 19-bit flat program addressing mode uses the 80C390 instruction set to enable bankless 0- to 512-KB access of on-chip program flash memory. The AX11005 can also execute instructions using 16-bit large program addressing mode, which calls on the 80C51 instruction set. A 16-KB SRAM area is used for program flash memory mirroring. In addition, 32 KB of on-chip user SRAM is allocated in the external data memory area.

It almost seems as though the AX11005's 10/100 Ethernet capability is an afterthought because the microcontroller supports a 1-Wire interface, three RS-232 ports, I²C, PWM, counter/timers, three SPI masters, a SPI slave, and 16 bits of general-purpose I/O. The idea behind the multitude of communications interfaces is to put the AX11005 into an application space that can convert RS-232 serial data to Ethernet frames or communicate with a ZigBee radio via the SPI port and bidirectionally transfer data between the ZigBee PAN and Ethernet link. With its many ways of communicating, the AX11005 is powerful enough to act as a network processor serving other link-attached or physically attached microcontrollers.

A single 3.3-VDC power source powers the AX11005. Keeping with the system-on-a-chip (SoC) concept, an on-chip 1.8-VDC regulator feeds the CPU core. The AX11005 requires only a single 25-MHz crystal for all of its internal clock generation processes. There's even a built-in, on-chip, power-on-reset circuit.

The AX11005 will most likely find itself embedded in an install-it-and-forget-about-it environment, so simple methods of upgrading the SoC's firmware must be available. The AX11005 can accept updates by way of the Ethernet port or the UART. You can also use the UART to program the device.

I'm particularly interested in the TCP/IP offload engine (see Figure 1). But before I delve into that, let's look at what it takes to support the AX11005.

Figure 1—If you ignore the TCP/IP offload engine and the 10/100-Mbps MAC, the AX11005 looks like a high-end microcontroller. Here you see 32 bits of general-purpose I/O, which is correct for the AX11005's big brother, the AX11015. The AX11005 supports only 16 bits of I/O.

(Click here to enlarge) Figure 1—If you ignore the TCP/IP offload engine and the 10/100-Mbps MAC, the AX11005 looks like a high-end microcontroller. Here you see 32 bits of general-purpose I/O, which is correct for the AX11005's big brother, the AX11015. The AX11005 supports only 16 bits of I/O. I'VE BEEN HAD!

From what I've seen thus far, the AX11005 is a pretty heavy little microcontroller. It would be close to impossible to attempt to apply an application to the AX11005 hardware without a good debugging system. The AX11005 doesn't disappoint. It comes standard with an on-chip in-circuit emulator feature that's designed to interface with a piece of external ICE hardware. The task assigned to the ICE is to manage communications between the AX11005's on-chip ICE circuitry and a software debugger application running on a PC. The external ICE hardware that mates with the AX11005's on-chip ICE circuitry is called the Hardware Assisted Debugger (HAD). The latest version of HAD is called HAD2. As you can see in Photo 1, I've been HAD.

Photo 1—The HAD2 is powered by the USB port and manages communications between the AX11005 on-chip ICE circuitry and the debugging application running on a companion PC.

(Click here to enlarge) Photo 1—The HAD2 is powered by the USB port and manages communications between the AX11005 on-chip ICE circuitry and the debugging application running on a companion PC. Powered by the USB port, the HAD2 uses USB Full Speed technology to interface the AX11005's internal debugging system to the debugging application running behind the USB interface on a PC. My HAD2 hardware is from Digital Core Design, which also supplied the Windows-based debugging application software. The HAD2 and Windows debugging software come bundled together. The HAD2 debugging software package is fully compatible with all existing 8051/80390 C compilers and assemblers. In addition to debug duty, the debugging software can be used as a software simulator too.

The HAD2 package was originally designed for SoC designers that needed the capability of debugging applications before they were to be committed to silicon. It's pretty obvious now that the AX11005 contains a Digital Core Design (DCD) 8051/80390 IP Core, because the AX11005's DCD IP Core is specifically designed to work with the HAD2 and the DCD Debug IP Core. This mix of IP cores and the HAD2 is called DCD on Chip Debug System (DoCD).

The Debug IP Core is a real-time hardware debugger that enables a full nonintrusive view of the on-chip registers, memories, and peripherals associated with the DCD IP Core, which is the 8051/80390 IP core in this case. The DoCD debugging system doesn't require any resources from the target. Thus, all of the target device's features and peripherals can be accessed during the debug phase. As you've already ascertained, the DoCD system is complete and needs nothing else in the way of features to make it better. But it does get better. You can also use the DoCD system to program the target device's program flash memory.

AX110xx DEVELOPMENT KIT

I have an AX11005 part, so you can safely assume that all of the pre-silicon work on it has been done. That means you can use the HAD2 in conjunction with the AX11005's debug IP Core. To help facilitate faster prototype cycles, ASIX offers the AX11005 development kit.

My AX11005 development board is shown in Photo 2. All of the microcontroller's bells and whistles are accessible by pin or connector. The schematic diagram for the AX11005 development board is six pages deep. So, instead of trying to nudge the schematic into this column, I posted it on the Circuit Cellar FTP site for easy access.

Photo 2—This is one busy board. The HAD2 connects using the shrouded and keyed pins below the Ethernet magnetics. Move down below the eight-position dipswitch and note the inclusion of screw terminals to facilitate RS-485. The AX11005 boot EEPROM can be seen in the upper-left corner.

(Click here to enlarge) Photo 2—This is one busy board. The HAD2 connects using the shrouded and keyed pins below the Ethernet magnetics. Move down below the eight-position dipswitch and note the inclusion of screw terminals to facilitate RS-485. The AX11005 boot EEPROM can be seen in the upper-left corner. Although the AX11005 is an awesome piece of silicon, the kit's real strength lies in the abundance of AX110xx software modules and utility programs. There is a source code module supplied for every AX11005 peripheral. AX11005 utility programs that come with the kit include a flash memory programming utility, HEX2BIN utilities for both DOS and Windows, and a TFTP/DHCP server application (just to name a few).

My AX11005 development board came preloaded with a TCP/IP stack and sample code for what the ASIX folks call a “lightweight” TCP/IP stack. It came on the kit's CD-ROM. A comprehensive software user's guide goes into detail about connecting your application to the software modules' internal API function calls. For instance, to use the AX11005's TCP/IP offload engine to set the IP address, all that needs to be coded is a call to the STOE_SetIPAddr() function. STOE refers to an API call that works against the TCP/IP offload engine. The source code also uses stoe (lowercase) to delineate driver calls from API calls. Examples of the API and driver calls I've referenced are shown in the top part of Listing 1.

The only hardware change you will have to make to give the HAD2 access to the AX11005 is a bit change within the Atmel AT24C02B EEPROM. Bit 7 of the byte located at address 0x01 within the AT24C02B determines if the CPU debugger pins are muxed to the Ethernet status LEDs or to the HAD2. The default state of bit 7 is a one, which muxes in the Ethernet status LEDs. It's easy to lash up a little PIC I²C interface and change the bit. I used a MicroEngineering Labs LAB-XUSB, which already has the socket laid in for an I²C EEPROM (see Photo 3).

Photo 3—The MicroEngineering Labs LAB-XUSB shown here was really designed to get you started with embedded USB. I was elated to see an I²C EEPROM socket on this board. It that meant I didn't have to fire up the soldering iron and build up the EEPROM circuitry from scratch.

(Click here to enlarge) Photo 3—The MicroEngineering Labs LAB-XUSB shown here was really designed to get you started with embedded USB. I was elated to see an I²C EEPROM socket on this board. It that meant I didn't have to fire up the soldering iron and build up the EEPROM circuitry from scratch. With a little bit of help from my Custom Computer Services PIC C compiler, I had the EEPROM bit banged to zero in a couple of minutes. The compiler is great for stuff like this because it's fully tilted toward the PIC architecture. It includes built-in PIC-specific functions that take most of the effort out of coding things like I²C, SPI, and RS-232. My little bit-twiddling C code is shown in the lower portion of Listing 1.

KEIL'S BEEN HAD2!

The AX11005 software guide tells you up front that Keil's C development tools were used to craft the AX11005 software drivers, so it would be a wise decision to continue to use Keil's C platform for your development work. One advantage of sticking with the C tools is that the Keil C tool suite natively supports all of the AX11005/8051/80390 stuff that you need to drive AX11005 code. In addition, when you initially install the DoCD drivers, the necessary HAD2 drivers and support files are automatically inserted into the Keil C tool suite framework.

Adding the DoCD drivers to the Keil µVision IDE pulls everything together into a single seamless AX11005 development environment. The µVision IDE incorporates the DoCD drivers into its debugging system and enables the AX11005 application programmer to edit, compile, program, run, and debug without having to leave the µVision window.

Showing you a screenshot of a debug screen full of little windows and data would be confusing at best. So, Photo 4 is a screenshot of the Load window that supports the AX11005 inside the µVision environment. This should give you an idea of how smooth the DoCD/µVision really is.

Photo 4—This is a shot of the Flash Download Setup window that is found within the µVision set-up dialog area. The check boxes make this window self-explanatory.

(Click here to enlarge) Photo 4—This is a shot of the Flash Download Setup window that is found within the µVision set-up dialog area. The check boxes make this window self-explanatory. 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.

SERIOUS STUFF

The AX11005 development kit is very comprehensive. When you drop the Keil C compiler and the DoCD hardware into the AX11005 development kit mix, you create a potent Ethernet development suite that will enable you to produce some pretty heady Ethernet-based equipment.

Personally, I've got some ZigBee ideas that I would like to apply to the AX11005. If I can pull them off, you'll see them in a future article. From what I've seen thus far, the AX11005 development kit isn't complicated. It's embedded.

SOURCES AND PDF

Download the PDF of this article.
Fred Eady (fred@edtp.com) has more than 20 years of experience as a systems engineer. He has worked with computers and communication systems large and small, simple and complex. His forte is embedded-systems design and communications.

PROJECT FILES

To download the schematics for the AX11005 development board, go
toftp://ftp.circuitcellar.com/pub/Circuit_Cellar/2006/197.
SOURCES
AX11005 Development kit
ASIX Electronics Corp.
www.asix.com.tw

PICC C Compiler
CCS, Inc.
www.ccsinfo.com

DoCD HAD2 Debugger
Digital Core Design
www.dcd.pl

PK51 C Compiler
Keil
www.keil.com

LAB-XUSB Board
MicroEngineering Labs
www.melabs.com
 
此文章源自《 Circuit Cellar》网站:
 
     http://www.circuitcellar.com/library/print/1206/Eady-197/index.htm