With the inception of 32-bit processors, the ARM processor was used primarily as a core in ASIC products. That changed when Atmel introduced the world's first ARM-based microcontroller standard-product family, the AT91 series.
This development effort grew from Atmel's ASIC organization. As ASIC development tools have improved, Atmel has taken advantage of emerging ASIC trends to ease development of system-on-chip (SOC) standard products.
As geometries decrease gates become less costly. ASIC manufacturing flows and tools, such as scan-based testing, were previously too costly in silicon area for incorporation into standard products. For example, scan- as a percentage of total die area- is no longer significant, especially when compared with the memory densities now included on-chip. This standard ARM processor-based SOC becomes the “chip platform” from which an ASIC can be derived.
Many 32-bit architectures utilize on-chip cache memories to support high processing throughput, differentiating them from 8-bit offerings. Most manufacturers are also looking at ways to speed up their on-chip FLASH memories and some latest-generation devices (such as the AT91RM9200 from Atmel) readily interface to SDRAM as well.
Despite the dramatic increase in functionality of today's standard product offerings, there are a number of sophisticated end-use applications that require migration to ASIC or ASSP due to their unique content and high level of integration and complexity. One example is GPS receivers.
While many GPS receivers utilize ARM's ARM7TDMI processor; there are no generic microcontroller families that include a GPS correlator in the standard peripheral list. This is due largely to the proprietary nature of the correlator IP and processing architecture.
The typical GPS receiver requires a radio frequency receiver (RF front end) with data and program FLASH memory, a baseband processor or correlator with data and program FLASH memory a nd perhaps a wireless processor interface (Bluetooth, Zigbee, etc.) also with data and program FLASH memory.
Because the larger telematics market is in its infancy, a first-to-market product entry with guaranteed functionality is essential to the serious player. Due to the escalating costs of developing an SOC product (NRE, sub-micron mask prep), a risk mitigation path is essential. Given these requirements, the platform methodology has successfully proven effective in meeting these challenges.
Another aspect of the platform methodology is the use of FPGA-based board-level products for prototyping and emulation. In the design of an ARM9 processor-based GPS correlator the ability to emulate the hardware performance of the processor in parallel with the code development effort, provides a dramatic time-savings. By using proven IP on a board platform the risks associated with timing closure, can be minimized by using IP previously built in the target technology. Because change is easily managed in t he platform environment, a new user interface can be swapped out or a code change made with little or no impact to schedule. Multi-cycle projects can be managed with ease.
In the GPS receiver example cited above, different radio frequency receivers could be placed on the board and metrics established for interoperability, such as time-to-first-fix, with reasonable confidence. By provision of standard interface technology, a test set could be emulated and ported to the board if the radio frequency receiver is unavailable.
Few standard-product controllers provide ROM on-board since tailoring the ROM for each customer would be difficult. However, in a fixed-function device like a GPS receiver, utilizing ROM where possible saves valuable silicon area, power, and reduces overall costs.
It is precisely because of this continual increase in functionality that few, if any, of today's SOCs are developed from scratch. Rather, platform-based development methodology builds on existing architectures and pro ven IP that reduces both risk and time-to-market with flexibility beyond what a structured ASIC method can accommodate. Atmel has already used this approach with both internal and external customers with tremendous success.
In the beginning, 32-bit microcontrollers arose from ASIC developments. Now, the newest generation of ASICs more often than not arise from the 32-bit microcontrollers. They're not all that different anymore.
Hank Carey is Director, Product Development, at Atmel Corp., San Jose, Calif.