|
|
|
|
|
|
||
 |
 |
 |
 |
 |
|
 | |||||
 |
 
|
 |
NetSilicon's 32-bit MCU takes aim at 16-bit slotsBy Bernard Cole
It's candidate for 16-bit MCU killer is a 32 bit ARM7TDMI-based MCU that has been stripped down for smallest die size --- and cost --- without sacrificing performance. The controller, designated the NS7520, is the first in a family of 33- to 55-MHz devices that will be priced at less than $10 each in volume. Some of Motorola's nominally 16-bit MCUs have an internal 32-bit architecture. Other vendors, such as Ubicom Inc., have used advanced processing to achieve clocks rates in excess of 100 MHz and made extensive modifications to the on-chip data and program storage to perform many control and network functions in real time in software rather than hardware. Most 32-bit controller vendors, however, including Motorola and about half a dozen licensees of ARM Ltd.'s real-time and deterministically optimized ARM7TDM1 core, have a different focus. In addition to many non-real-time applications in a range of PDAs and other small-footprint systems, they have targeted environments (such as home networking) and applications (such as network bridges and gateways) that, at the lower levels of the network protocols, must operate in a real-time, deterministic manner.But few 32-bit vendors have gone after the core of the 16-bit MCU market -- not even Ubicom, which recently revealed the architectural details of a 32-bit MCU of original design. Meanwhile, Philips' use of the ARM7TDMI in its new family of 32-bit MCUs has provided a migration path for many controller peripheral functions and software expertise to real-time 32-bit control applications in the lower levels of the network protocol stacks. The Philips devices are scheduled to go into production later this year.</p> Bill Peisel, chief technical officer at NetSilicon, believes it is time to go after the core of the 16-bit business, using the ARM7TDMI as the vehicle. On the one hand, he said, ARM has minimized or removed architectural features such as on-chip memory management and the data and program caches. While useful in a wide range of data-processing applications, such features get in the way of deterministic control functions. On the other hand, he said, ARM was smart enough to incorporate a vectored interrupt controller block into the core. In traditional RISC processor designs, when an interrupt from a device is received, the CPU saves its current working registers and starts an ISR (interrupt service routine) to determine the source of the interrupt. It then transfers execution of the interrupt to a specific ISR designated to process an interrupt from that source. As there can be frequent interrupts from many sources, the cumulative time lost can be significant and can lead to many problems in a real-time system, where interrupts must be serviced within specific time limits in order to preserve the deterministic operation of the system. In a controller with vectored interrupts, however, there is a list of vectors (code addresses) for ISRs that are associated with each interrupt source. When an interrupt is received, the VIC can pass the exact location of the associated code over to the processor immediately so that the processor can access the code without delay, thus preserving real-time operation.
Reducing die size The trick, said Peisel, is to retain as much of this control functionality as possible while reducing the die size enough to match 16-bit microcontrollers in price. The first step was to include only that functionality necessary for the majority of real-time microcontroller functions. Much of what was left on the chip is familiar to any engineer versed in 16-bit designs, Peisel said, including: two serial ports, a 28 channel interrupt controller with edge and level triggering, watch dog and timer interrpts, two 27 bit programmable timers, a 16 channel general purpose I/O, HDLC/UART and SPI support, and a 11 internal, 2 external channel DMA controller. Also left on chip were capabilities that most 16 bit MCUs can't match: a 10/100 Ethernet MAC, and a dynamically sizable 8,16,32 bit external bus interface and 256Mbytes of directly accessible memory address space. To reduce the die size sufficiently to match 16-bit MCU pricing models, the company also shifted to a new fabrication partner and a new process (Toshiba and its 0.18-micron CMOS process, vs. Atmel's 0.25-micron CMOS). That shift, in combination with the reduction in architectural complexity, led NetSilicon to reduce the die area 30 to 40 percent, sufficient to fit into a 177-pin BGA, vs. the previous, 208-pin BGA. "What that means is that we can be very aggressive on pricing from the outset with plenty of room left for further price reductions," he said. Another benefit of the new process was a core that operates on only 1.5 volts and at 3.3 volts on the I/O, on a par with or lower than most 16 bit MCUs. One functional block that Peisel and his engineers decided to improve significantly, after only a little internal debate, he said, was the size of the CPU's receive/transfer buffers, important in the efficiency of an MCU in the processing of a packet. They kept the original 2k byte receive buffer size, which is about 120 times the size of that on most 16 bit MCUs, and increased the size transmit buffer from 128 bytes to 512 bytes, six times larger than the typical 16 bit MCU. To further enhance the performance of the buffers Peisel and his engineers improved the device's DMA channel structure to reduce the latency time when switching from one channel handling input data streams to another handling output data streams. Go to www.netsilicon.com for more information on this product.
Butv for more information about the issues, competitive products and technologies discussed
in this story, go to the iAppliance Web Views
page and call up the associatively-linked XML/Java Web
map of the iApplianceWeb site and search for product information since the
beginning of 2002.
|
|
| |||||
Terms and Conditions Privacy Statement | ||||||||||
