Efficient System-on-Chip Development using Atmel’s CAP...

11

Atmel Corporation • 2325 Orchard Parkway • San Jose, CA 95131 TEL (408) 441-0311 • FAX (408) 487-2600 • Web Site: http://www.atmel.com

Efficient System-on-Chip Development using Atmel’s CAP Customizable Microcontroller

By Peter Bishop, Communications Manager, Atmel Rousset

Summary Considerations of cost, size and power consumption require that many electronic applications are built around a System-on-Chip (SoC) that integrates most or all of the functionality of the application onto a single integrated circuit. However, the complexity of these devices makes them increasingly difficult to develop and validate economically in a timescale that meets the time-to-market pressures of the application. SoCs incorporate programmable elements (notably microcontrollers) that make their software content at least as expensive and time-consuming to develop as their hardware.

Using Atmel’s CAP™ customizable microcontroller (MCU) based on the industry-standard ARM® processor with on-chip memories and industry-standard interfaces, and incorporating a metal programmable block (MP Block) for additional processor(s), application-specific logic and non-standard interfaces, represents a practical approach to SoC development that addresses all these issues. Design time is reduced by the integration of pre-qualified IP (intellectual property) hardware/software modules from Atmel or from specialist third parties, the short physical design stage for metal placement & routing, and by parallel hardware/software development, facilitated by the extensive support available for the industry-standard ARM architecture. Fabrication time is reduced by holding a stock of pre-fabricated base wafers, and only adding the metal layers for each customized product. Development cost is reduced by the minimal design effort required to integrate the application-specific logic and the reduced number of masks required for fabrication.

The design flow for the customizable microcontroller facilitates the implementation of complex algorithms in the MP Block, by the use of high-level tools and pre-defined hardware and software functional blocks. The CAP design flow also takes into account the requirements for functional validation and design-for-test (DFT), both of which are essential when developing complex system-on-chip-based applications. An emulation board comprising the processor, memories, peripherals and standard interfaces on a single IC together with an FPGA (field programmable gate array) representing the MP Block enables at-speed parallel hardware/software testing and increases the chances of right-first-time silicon and software.

EFFICIENT SYSTEM-ON-CHIP DEVELOPMENT USING ATMEL’S CAP CUSTOMIZABLE MICROCONTROLLER

2 6364B –CASIC –04/08

Table of Contents CAP Architecture Overview ...................................................................... 3

CAP Architecture Features ....................................................................... 5 ARM Processor .............................................................................................................5 Multiple Parallel Internal Data Paths ..............................................................................5 Internal/External Memories ............................................................................................5 System Peripherals/Interfaces .......................................................................................6 System Controller...........................................................................................................6 Peripherals/Interfaces ....................................................................................................9 Metal Programmable Block ..........................................................................................10

CAP Design/Fabrication Flow................................................................. 11

CAP Design Flow Steps .......................................................................... 12 Atmel: Customizable Microcontroller and Software Device Driver Development ........14 Application Developer: System Specification and Hardware/Software Partitioning.....14 Application Developer/Third Party Design House: Development of Hardware and Software Modules for Optimized Algorithm Execution.................................................14 Application Developer/Third Party Design House: Customization of MP Block, Hardware Synthesis/Simulation ...................................................................................15 Application Developer/Third Party Design House: MP Block Design for Test .............17 Application Developer/Third Party Design House: Integration of Application-Specific Software and Operating System, Software Simulation ................................................18 Application Developer/Third Party Design House: Emulation on FPGA-based Emulation Board...........................................................................................................19 Application Developer: Validation of Software Running on the ARM Processor .........21 Application Developer: Validation of Application-Specific Logic in the FPGA .............21 Atmel: Physical Design and Prototype Fabrication ......................................................24 Application Developer: Final Software Development and Application Validation ........24 Atmel: Volume Fabrication ...........................................................................................24 Application Developer: Volume Assembly of Application.............................................24

CAP-based SoC Design and Fabrication: Evaluation........................... 25

Conclusion ............................................................................................... 25


3 6364B –CASIC –04/08

CAP Architecture Overview As illustrated in Figure 1, the CAP customizable microcontroller is built around an industry-standard ARM7™ or ARM9™ processor core and associated multi-layer AHB (AMBA™ High-speed Bus) matrix that connects the on-chip SRAM and ROM, external bus interface and system peripherals, with a bridge to the energy-efficient APB (AMBA Peripheral Bus) for the system controller and lower-speed peripherals. A central architectural feature is the distributed DMA (direct memory access) that, together with the parallel data paths provided by the AHB matrix, gives the device an extremely high internal data bandwidth. Peripheral-to-memory transfers take place with minimal processor intervention, enabling the device to support multiple high-speed external interfaces without degrading processor performance for application tasks. The MP Block features multiple DMA ports so that application-specific logic implemented on it can benefit from this high internal data bandwidth.

An extensive set of industry-standard peripherals and interfaces (including USB Host and Device, Ethernet, CAN, MCI, SPI, LCD Controller, Image Sensor Interface) covers the user interface, networking/connectivity and storage requirements of most applications. Additional instances of these peripherals, or other peripherals/interfaces, can be implemented in the MP Block. The MP Block cell density is comparable to that of the standard cell density of the fixed portion of the device, and incorporates multiple distributed SRAM (Static RAM) and DPRAM (Dual-Port RAM) blocks for the local memory requirements of application-specific IP.

A sophisticated system controller integrates all aspects of system and power management on-chip. It controls system startup and shutdown. It provides multiple clock sources and peripheral enable lines so that each functional block can be run at the minimum clock frequency required to support the application, or put in idle mode if not required. This keeps the device power consumption to a minimum under all conditions of use.

To complement the mostly digital functionality provided by the CAP, Atmel can supply analog companion chips for power/battery management, high-end audio and sensor interfacing. These devices use CMOS mixed-signal technology that has been adapted to their precise requirements.


4 6364B –CASIC –04/08

System Controller

Advanced Int CtrlPower Mgt Ctrl

Reset Ctrl

Prog Int TimerWatchdog TimerReal Time Timer

Debug UnitPIO Ctrl

PLLOsc

Backup RegistersShutdown Ctrl

RCOsc

TWI

USART

SPI

CAN Controller

SSC

Multi-Channel ADC

PWM Controller

Timer/Counter

MCI AC97 Controller

PIO

PIO

PIO

PIO

In Circuit Emulator

JTAG

Bus Interface

ARM9Processor

InstrCache

DataCache

MMU

External Bus Interface

SDR/DDRController

Burst CellularMemory Ctrl

Static MemoryController

Compact/NAND FlashECC

DMA

DMA

DMA

DMA

DMA

USB Host

USB HS Device

Trans

Trans

10/100 EthernetMAC

LCD Controller

Image SensorInterface

MetalProgrammable

Block

Mul

ti-C

hann

elA

HB

Inte

rfaceDPR

RAM

Mul

ti-La

yer A

HB

Mat

rix

ROM SRAM

PeripheralBridge

Multi-ChannelPeripheral DMA

PDC

PDC

PDC

PDC

PDC

PDC

PDC

APB

PIO

DMA Controller

Figure 1. CAP ARM9-based Customizable Microcontroller Architecture


5 6364B –CASIC –04/08

CAP Architecture Features ARM Processor

The embedded ARM7 or ARM9 processor brings all the advantages of the industry standard for 32-bit RISC microcontrollers, including code compatibility across the entire family, a wide choice of development tools and extensive application support. A second ARM core can be implemented in the MP Block if required. Key features of the ARM architecture are single-cycle execution for most instructions and the compressed 16-bit Thumb code subset that significantly reduces the memory footprint required for application code.

The ARM9 core features instruction and data cache memories that accelerate code execution. A future a tightly coupled memory (TCM) option will guarantee deterministic performance for critical real-time sequences when implemented with an ARM11™ core with enhanced processing and integral DSP capabilities that is in the CAP roadmap.

Multiple Parallel Internal Data Paths

The device’s highly parallel internal bus architecture with distributed DMA has been developed in the light of many years’ experience in ARM-based microcontroller standard products. It takes into account the requirement to support multiple high-speed external networking/communications interfaces at the same time as running compute-intensive application code. Building around the multi-layer AHB matrix, Atmel has added distributed DMA channels for system peripherals (including the MP Block) and memories, and a peripheral DMA controller (PDC) in parallel with the AHB/APB Bridge that links to PDC channels on all the APB serial peripherals.

This architecture provides multiple parallel internal data paths that can be allocated and relinquished as required. It almost entirely frees the processor from internal or external data transfer tasks, and provides an extremely high internal data bandwidth for peripheral-to-memory (internal or external) or peripheral-to-peripheral transfers.

Internal/External Memories

The on-chip ROM is used for a default boot routine supplied by Atmel that systematically interrogates external memories for a valid system boot program. Alternatively the device can be booted directly from an external memory depending on a control input setting at power-up. In addition, the application developer may provide application-specific ROM code as part of the customization of the device.

The embedded SRAM (Static RAM) is single-cycle accessible at full bus matrix speed. It is used for operational code modules and data that are swapped from external memories by the boot routine or an operating system. The MP Block integrates multiple distributed SRAM and DPRAM (Dual-Port RAM) blocks that can be tightly coupled to the application-specific logic modules that they serve.

The EBI (External Bus Interface) provides a full 32-bit data bus for external memories. It includes dedicated controllers for static memory, burst cellular memory, CompactFlash® and SDRAM/DDRAM. It features error correction code (ECC) for NAND Flash. Additionally the SPI interfaces directly with DataFlash® memory modules, the MCI links to SD Memory


6 6364B –CASIC –04/08

Cards and the TWI to serial EEPROM. The aim is to provide a seamless interface for whatever memory configuration is required by the particular application.

System Peripherals/Interfaces

The system peripherals are connected via dedicated DMA channels to the AHB matrix. Most have bus master privilege and are thus able to initiate data transfers, and transfer data at full bus speed with minimal processor overhead.

The USB Host Port (UHP) interfaces a host application with the USB channel. It implements the OHCI (Open Host Controller Interface) protocol as well as USB v2.0 Full-speed and Low-speed protocols. It integrates a root hub and two transceivers on downstream ports. The USB Device Port (UDP) implements the USB V2.0 High-speed protocol via an embedded UTMI+ (USB Transceiver Macrocell Interface) compliant transceiver. Bringing the USB transceivers on-chip reduces the external device count.

The 10/100 Ethernet MAC (Media Access Controller) operates at either 10 or 100 Mbits/sec, conforming to the IEEE® 802.3 standard. It supports full and half duplex transfers, with an MII (Media Independent Interface) or RMII (Reduced Media Independent Interface, with a lower external pin count to simplify PHY design) to the external physical layer.

The LCD Controller supports a graphical user interface (GUI). With resolution up to 2048X2048 pixels, it features a virtual frame buffer larger than the screen size that permits smooth scanning of a screen-sized window. It supports single- and dual-scan 16-bit/pixel color and 16 gray-level monochrome passive STN-LCD (Super Twist Nematic Liquid Crystal Display) panels, as well as single-scan active 24-bit/pixel TFT LCD (Thin Film Transistor LCD) panels.

The Image Sensor Interface supports an external image capture IC with a resolution of up to 2048X2048 pixels and a programmable frame capture rate. It conforms to the ITU-R BT.601/656 8-bit standard for digital inter-operability of video/TV systems.

System Controller

The CAP System Controller (Figure 2) collects together all the functional elements that control the interrupt handling, reset, startup/shutdown, timing, power management and parallel I/O control of the device. It also provides a debug interface to the ARM core via the Debug Unit.


7 6364B –CASIC –04/08

AdvancedInterrupt

Controller

Debug Unit

Periodic Interval Timer

Warchdog Timer

Reset Controller

Real-Time Timer

Shutdown Controller

PowerManagementCoontroller

PIO Controller

VDDCorePoR

VDDBUPoR

Slow ClockOsc

MainOsc

PLL A

PLL B

VoltageController

BackupRegisters

ARM9Processor

EmbeddedPeripherals

System Controller

VDDBUPowered

VDDCorePowered

Peripheral/System Controller

InterruptRequests

NormalInterruptRequest

ProcessorReset

ProcessorClock

FastInterruptRequest

PeripheralClocks

PeripheralReset

PeripheralInterrupt

Requests

ProcessorClock

MainClock

AHB Matrix

PeripheralResetMain

Clock

ProgrammableClocks

Slow Clock

Main Clock

Main Clock

Slow Clock

Debug InterruptRequest

PIT InterruptRequest

WatchdogInterrupt Request

RTT InterruptSlow Clock

RTT Alarm

Reset ControllerInterrupt Request

Processor Reset

Peripheral ResetBackup Reset

Reset

Shutdown

Wakeup

XIN32

XOUT32

XIN

XOUT

PLLRCA

PLLRCB

PIOA

PIOB

PIOC

PIOD

PeripheralI/O

Debug Tx/Rx

Clock Generator

Figure 2. CAP System Controller


8 6364B –CASIC –04/08

The Advanced Interrupt Controller (AIC) complements the basic two-level interrupt architecture of the ARM core, thereby significantly enhancing the device’s real-time performance. The AIC provides 32 prioritized, vectored and individually maskable interrupt sources, including seven from the MP Block, that reduce to a minimum the processor overhead when responding to an interrupt. Interrupts can be programmed to be edge- or level-sensitive, active high or low. Fast interrupts are routed directly to the nFIQ (Fast Interrupt Request) interrupt line of the ARM processor; normal interrupts have an 8-level priority scheme with the highest-priority interrupt at any given time driving the processor’s nIRQ (Normal Interrupt Request) interrupt line. Lower-priority pending interrupts are queued until the processor is available to handle them.

The Reset Controller uses inputs from two Power-on-Reset (PoR) cells (for the main and backup power supplies) as well as from the software, watchdog and user resets, to generate the required control sequence for a system reset.

Powered by the backup power supply, the Shutdown Controller ensures that the device starts up and shuts down in a deterministic manner when the main power supply is switched on or off. It includes a set of general-purpose Backup Registers that can be programmed to store vital configuration or operational data during system shutdown.

The Clock Generator embeds oscillators for the main and slow clocks, and two PLLs (Phase Locked Loops) that provide higher clock frequencies. These outputs are used by the Power Management Controller to provide the various system clocks.

The Power Management Controller (PMC) provides clocks to the processor, bus matrix, peripherals and MP Block, as well as four programmable clock sources, in order to support one of five operation modes:

1. Normal mode, with processor, bus matrix, peripherals and MP Block running at a programmable frequency (up to 200 MHz for the ARM9 processor; up to 100 MHz for the bus matrix, MP Block and peripherals);

2. Slow clock mode with processor, bus matrix, peripherals and MP Block running at slow clock frequency (32.768 KHz);

3. Idle mode with the processor stopped waiting for an interrupt;

4. Standby mode, a mixture of idle and backup mode, with the processor stopped waiting for an interrupt and peripherals and MP Block running under backup power at slow clock frequency;

5. Backup mode, with the main power supply off, and the slow clock running under backup power.

Selecting the appropriate operation mode enables the system to minimize power consumption under all conditions of operation.

The multiple on-chip Timers include a Real-Time Timer that uses the slow clock to count elapsed seconds, a Periodic Interval Timer that uses the main clock to provide the operating system’s scheduler interrupt, and a Watchdog Timer (WDT) that can be used to prevent system lock-up if the software becomes trapped in an endless loop. The WDT is built around a down counter with a period of up to 16 seconds that generates a reset if it reaches the count limit without having been interrupted.


9 6364B –CASIC –04/08

The System Controller also includes the four Parallel I/O Controllers each of which multiplexes up to 32 peripheral I/Os with general-purpose input/output lines. Each I/O line can be programmed to generate an interrupt on state change and is provided with a glitch filter. A pin data status register provides visibility of the level of each I/O pin at any time.

Peripherals/Interfaces

The APB interconnects an extensive set of peripherals and external interfaces designed to meet the requirements of a wide range of applications. All the serial peripherals/interfaces integrate a Peripheral DMA Controller (PDC) channel that, for a minimum silicon overhead, enables data transfers to be made via the PDC to any other system resource (peripheral, external interface or on- or off-chip memory) at full bus speed with minimal processor intervention.

Industry-standard interfaces include a 1 Mbit/sec 16-mailbox CAN (Controller Area Network) 2.0A and 2.0B-compliant controller for automotive and industrial applications, and a double-channel MCI (Multimedia Card Interface). Each MCI channel can support one MultiMediaCard bus (up to 30 cards) or one SD Memory Card or one SDIO Card.

General-purpose serial interfaces include a TWI (Two Wire Interface) compatible with standard two-wire serial memory, and a USART that supports 5- to 9-bit full duplex synchronous or asynchronous serial communications. Its multiple features include a programmable baud rate generator, parity generation and error detection, and support for the ISO7816 T=0 or T=1 protocol for interfacing with Smart Cards.

The SPI (Serial Peripheral Interface) supports communication with a wide range of external serial devices, including co-processors, serial memories such as DataFlash and 3-wire EEPROM, ADCs, DACs, LCD Controllers, CAN Controllers and sensors. Up to 15 devices can be linked at any one time. The SSC (Synchronous Serial Controller) provides serial synchronous communication links used in audio and telecom applications. It contains independent transmitter and receiver channels and a common clock divider. The 4-channel PWM (Pulse Width Modulation) Controller, incorporating a 16-bit counter per channel, provides control signals with a programmable duty cycle for a wide range of industrial applications such as electric motor control. The three 16-bit Timer/Counter channels have a wide variety of uses, including frequency measurement, event counting, interval measurement, pulse generation and delay timing.

The AC97 Controller, conforming to AC97 Component Specification V2.2, incorporates three transmit and three receive channels designed to link to an external analog device such as an audio or modem Codec (Encoder/Decoder). The 8-channel 10-bit ADC (Analog-to-Digital Converter) enables the device to accept analog inputs from a variety of sources, reducing the external chip count.


10 6364B –CASIC –04/08

Metal Programmable Block

The CAP metal programmable block (MP Block) is constructed using Atmel’s Metal Programmable Cell Fabric (MPCF) technology. It has a gate density that approaches the density of the standard cells that implement the fixed portion of the device. See Figure 3. It has sufficient capacity to implement a second ARM processor core or Atmel’s proprietary AVR® RISC processor, a digital signal processor (DSP), additional standard (or non-standard) interfaces and complex logic blocks such as GPS correlators. It has a number of internal features and dedicated external connections that enhance its efficiency for implementing application-specific logic elements. Internally, it has multiple distributed Single- and Dual-Port RAM blocks that can be tightly coupled to the logic elements that require them.

Figure 3. Metal Programmable Block Gate Density: D-type Flip-Flop Implemented in MP Block (left) and in Standard Cells (right), in 0.13-micron CMOS Technology

The external connections of the CAP MP Block (Figure 4) include:

Multiple parallel Master and Slave connections to the AHB Bus Matrix that, together with dedicated DMA channels, can be configured to create high-bandwidth data links to application-specific logic elements. If APB peripherals are required in the MP Block, an AHB/APB Bridge and Peripheral DMA Controller (PDC) can be built into it in order to provide the required interfaces.

A set of interrupt lines that enable application-specific logic elements to generate interrupts that are handled by the Advanced Interrupt Controller.

A set of Peripheral Enable lines that permit application-specific logic to enable or disable peripherals in the fixed portion of the device.

Two parallel sets of dedicated I/O ports that provide a large number of external I/Os for the application-specific logic elements. A range of electrical characteristics is available for the I/Os connected to the MP Block.


11 6364B –CASIC –04/08

A multiplexed connection to the USB Device Transceiver. This enables a second USB Device Port to be implemented in the MP Block.

The MP Block is supplied by all the clocks originating from the Clock Generator and Power Management Controller. This gives the maximum flexibility in clocking the application-specific logic elements implemented in it.


Single-PortRAM

Dual-PortRAM

USBDeviceTrans-ceiver

Clocks

PeripheralEnables

Interrupts DMAAHB Matrix

MastersAHB Matrix

Slaves

MPIOA MPIOB

MP Block Scan Wrapper

DeviceBoundary Scan

Figure 4. CAP Metal Programmable Block Interfaces

CAP Design/Fabrication Flow The objective of the design flow associated with the CAP is to develop an application-specific System-on-Chip – both hardware and software – in the shortest possible time, at a reasonable cost, with a high probability of right-first-time silicon and software. This is achieved due to a number of characteristics of the CAP design/fabrication flow:

Parallel hardware/software development. The design flow is adapted for parallel hardware/software development, to address one of the major obstacles to rapid System-on-Chip development.

Efficient implementation of complex algorithms. The hardware/software partitioning of complex algorithm execution can optimized by the use of high-level hardware and software design tools, supported by libraries of pre-defined signal processing functions. The outputs from these tools integrate seamlessly into the following steps of the CAP design flow.

Rapid integration of application-specific hardware into CAP. The application-specific hardware is designed in RTL (register transfer language, generally Verilog). These RTL


12 6364B –CASIC –04/08

modules are integrated into the code template for the MP Block that already contains the AHB interfaces, DMA channels, I/O channels, etc.

Rapid integration of application-specific software with device drivers and operating system. Device drivers are supplied for all the peripherals/interfaces in the fixed portion of the device. These can also serve as templates for equivalent drivers for the peripherals/interfaces defined in the MP Block. A number of industry-leading operating systems have already been ported onto the CAP architecture. Integration of these software modules with the application code modules and the user interface for the application can be done in parallel with hardware development.

Incorporation of design-for-test features. Scan paths are already present in the fixed portion of the design. A template in the CAP design kit makes it easy to insert complementary scan paths into the MP Block, and then do automatic test pattern generation (ATPG) and test simulation in order to prepare a set of post-fabrication test vectors with a high level of fault coverage.

At-speed emulation of hardware/software before physical design/mask fabrication. The emulation board implements fixed portion of the CAP on a single chip with an FPGA for the MP Block. This enables the hardware and at least the low-level software of the application-specific device to be emulated at close to operational speed, and errors to be corrected at no cost.

Functional validation. Industry-standard development tools make use of the in-circuit emulation (ICE) features of the ARM core, and embedded logic analyzers (ELA) inserted into the MP Block. These greatly facilitate functional validation.

Rapid placement & routing, only metal layers. The placement & routing of the metal layers of MP Block is done rapidly, using an established floorplan.

Rapid, low-cost mask fabrication. Only the masks for the metal layers of the device are required.

Rapid fabrication, only metal layers. A stock of pre-fabricated blanks of the CAP is the starting point for the fabrication of each application-specific device. Only the metal layers need to be added.

CAP Design Flow Steps The steps of the CAP design flow are illustrated in Figure 5. It is a highly collaborative process, shared between the application developer, an accredited third-party design house, a third party supplier for the operating system, if required, and Atmel. The steps are described in the following paragraphs.


13 6364B –CASIC –04/08

OperatingSystem

SpecifyApplication

Define ApplicationHardware/Software

Architecture

Hardware/SoftwareVerification on

Application Prototypeor Development Board

Integrate CAPand Software

into Application

Integrate Application-

specific Hardwareinto MP Block

IntegrateApplication Software

Modules/ Drivers/Operating System

Hardware and Low-levelSoftware Emulation on CAP FPGA-based

Emulation Platform

Hardware/SoftwareCo-simulation

PrototypeCAP Fabrication

MP Block Place & Route

ApplicationSoftware

Development

VolumeCAP Fabrication

SoftwareTest

Final SoftwareDebug/Test

Synthesis/FunctionalSimulation

MP BlockScan Insertion/

ATPG/ Test Simulation

SoftwareSimulation

Processor/ Memories/

Peripherals/ Interfaces

with Scan Paths

DeviceDrivers

CAP Hardware Blocks

CAPSoftware Modules

Design Application-specific

HardwareBlocks

DesignApplication-specific

SoftwareModules

CAP Application Development Flow

ApplicationDeveloper

Atmel

Third Party Design House/Application Developer/

Atmel

Third Party Supplier

CAPFixed Portionwith Boundary

Scan

Trace/Debug

Figure 5. CAP Design Flow


14 6364B –CASIC –04/08

Atmel: Customizable Microcontroller and Software Device Driver Development

As described in the first part of this document, Atmel has developed a CAP customizable microcontroller based on the industry-standard ARM7 and ARM9 processor cores. It incorporates a wide range of peripherals and industry-standard interfaces, all of which are supported by software device drivers and protocol stacks. The metal programmable block has sufficient capacity for additional processors, DSP cores, functional modules such as GPS correlators and additional instances of peripherals/interfaces. This architecture is the result of more than ten years’ experience in MCU-based ASICs and standard products. All its constituent blocks have been qualified, characterized and validated in multiple applications. It represents a design resource that reduces by a significant factor the design effort required for the application-specific device.

Application Developer: System Specification and Hardware/Software Partitioning

The starting point of the application development flow is the specification of the required system, and the partitioning of its functionality between hardware and software, taking into account the architecture of the CAP and the possibilities for implementing the application-specific functionality in the MP Block. The general guideline is hardware for performance, software for flexibility, but in practice there is considerable scope for variation of this partitioning. One of the major benefits of the CAP design flow is that the hardware/software partitioning can be validated and, if necessary, corrected at the emulation phase, before committing the hardware to silicon. This can save the time and expense of silicon re-spin.

Application Developer/Third Party Design House: Development of Hardware and Software Modules for Optimized Algorithm Execution

High-level tools for algorithm implementation, such as MATLAB® and Simulink® from The MathWorks®, can be integrated seamlessly into the CAP application development flow. They enable the hardware and software required for the algorithm implementation to be developed and simulated rapidly and efficiently in parallel, before integrated into the following steps of the CAP design flow. See Figure 6.


15 6364B –CASIC –04/08

PartitionAlgorithmHardware/Software

HardwareFunctional

BlockLibrary

SoftwareMathematical

FunctionLibrary

DevelopHardware for

AlgorithmExecution*

DevelopSoftware for

AlgorithmExecution**

HardwareSimulation*

SoftwareSimulation**

Output Hardware HDL

Code*

OutputSoftware C/C++

Code**

* using, for example,Simulink from

The MathWorks

** using, for example,MATLAB from

The MathWorks

HardwareDevelopment

Flow

SoftwareDevelopment

Flow

To CAP Design Flow

Figure 6. CAP Algorithm Execution Design Flow

On the software side, the algorithm can be specified in mathematical format using the MATLAB toolset. MATLAB provides extensive libraries of the basic equations for signal processing that can be combined with application-specific functions in a high-level programming language that has been developed for this purpose. The algorithm under development can be partially or completely simulated at any stage for verification. The output from this phase is C/C++ code that drives the ARM processor, its peripherals and the application-specific functions to be implemented in the MP Block.

On the hardware side, a tool such as Simulink provides an extensive library of pre-defined signal processing functions. Application-specific functions can be defined in mathematical format using MATLAB and then imported into Simulink. These are integrated into the design in schematic format, to build up the algorithm processing hardware that is specifically required for the application. The hardware configuration under development can be simulated at any stage, and modified with no cost penalty. The output from this high-level development phase is automatically generated HDL code for the hardware that will be mapped first onto the FPGA and then into the CAP MP Block.

Application Developer/Third Party Design House: Customization of MP Block, Hardware Synthesis/Simulation

The task of customizing the MP Block is generally shared between the application developer and a qualified third-party design house. The first phase is to develop application-specific hardware blocks and associated software drivers. High-level tools for algorithm implementation can be used as described in the previous paragraph; alternatively the hardware blocks are coded directly in Verilog RTL and the software in C, C++ or ARM assembly language.


16 6364B –CASIC –04/08

The task of integrating the application-specific blocks into the MP Block is facilitated by the placeholder instantiations of functional blocks already written into a template for the MP Block RTL code that is supplied by Atmel. Separate templates are provided for AHB master/slave devices and for APB slaves. DMA or PDC connectivity is pre-programmed in some blocks. See the code extract in Figure 7 below for an example of an APB-connected function with PDC connectivity.

//////////////////////////////////////////////////////////////////////////// // mpapb0: // PORTS: // psel_mpapb0 (APB select) // mpapb0_config_clock (APB configuration clock) // pwrite (APB write) // paddr (APB address - 14 bits) // pwdata (APB write data bus) // mpapb0_channel_rx_end (from PDC - rx buffer full) // mpapb0_channel_tx_end (from PDC - tx buffer full) // mpapb0_rx_buffer_full (from PDC - both rx buffers full) // mpapb0_tx_buffer_empty (from PDC - both rx buffers full) // prdata (APB read data bus) // mpapb0_size (to PDC - rx/tx transfer size) // mpapb0_rx_rdy (to PDC - rx ready) // mpapb0_tx_rdy (to PDC - tx ready) // mpirq0 (Interrupt to AIC) // // Replace empty module with user-defined logic // APB0 apb_pdc_empty i_apb0 ( //-- INPUTS .nreset(nreset_r_apb), .pclock(mp_pclocks[0]), .config_clock(mpapb0_config_clock), .psel(psel_mpapb0), .pwrite(pwrite), .paddr(paddr), .pwdata(pwdata), .rx_end(mpapb0_channel_rx_end), .tx_end(mpapb0_channel_tx_end), .rx_buffer_full(mpapb0_rx_buffer_full), .tx_buffer_empty(mpapb0_tx_buffer_empty), //-- OUTPUTS .prdata(p_d_from_mpapb0), .rx_size(mpapb0_size), .tx_size(), .rx_rdy(mpapb0_rx_rdy), .tx_rdy(mpapb0_tx_rdy), .apb_irq(mpirq0) );

Figure 7. RTL Code for Placeholder Instantiation of APB-connected Function in MP Block

When the RTL code for the functions in the MP Block has been integrated it is validated for compatibility with the CAP architecture. The RTL code is then synthesized using process-specific target libraries supplied by Atmel and functional simulations are performed on the entire device.


17 6364B –CASIC –04/08

Application Developer/Third Party Design House: MP Block Design for Test

The fixed portion of the CAP is provided with scan paths and built-in self-test (BIST) circuitry for the embedded memories, including those in the MP Block. In order to bring the MP Block up to the same level of testability as the fixed portion of the device, a set of scan paths is inserted into it, separated by clock domain. See Figure 8 for details.

Fixed Block Boundary Scan Path

Fixed Block Clock Domain 2

Fixed Block Scan Path





MP Block Scan Wrapper

MP Block Clock Domain 1

MP Block Scan Path

MP Block Clock Domain 2

MP Block ClockDomain 3

MP Block Boundary Scan Path

Connection Fixed/MPBlock Boundary Scan Paths

Con

nect

ion

Fixe

d/M

PB

lock

Bou

ndar

y S

can

Pat

h

Scan Path created by Atmel Scan Path created by Application Designer

Fixed Block


SRAM

BIST

ROM

BIST

SRAM

BIST

DP-RAMBIST

Figure 8. CAP Scan Paths

Using a descriptor file for these scan chains, and those for the fixed portion of the device, an automatic test pattern generation (ATPG) step and test simulation using these vectors provides a set of test vectors for post-fabrication tests. This ensures a high level of fault coverage for the manufactured devices.


18 6364B –CASIC –04/08

Application Developer/Third Party Design House: Integration of Application-Specific Software and Operating System, Software Simulation

In parallel with the hardware integration, the application developer works together with the third-party design house to integrate the software suite that corresponds to the hardware. As shown in Figure 9, the low-level device drivers for the fixed portion of the device are supplied by Atmel, and those for the MP Block originate from the application developer or third-party design house. These are integrated with the application modules that program the MCU, its peripherals/interfaces and the functional modules that have been implemented in the MP Block. As described in a previous paragraph, application code modules can be developed using high-level tools for algorithm implementation. If an operating system is required, a pre-ported version is obtained from a qualified third party and integrated into the software suite. An example is the Microsoft® Windows® CE® Board Support Package (BSP) from Adeneo.

User Interface

ApplicationModule

ApplicationModule

ApplicationModule

OperatingSystem

DeviceDriver

DeviceDriver

DeviceDriver

DeviceDriver

DeviceDriver

DeviceDriver

MP Block Platform Peripherals/Interfaces

Graphical User Interface

Customer/Third Party Design House

Third Party Supplier

Atmel

MCU

Ope

ratin

g Sy

stem

Cal

ls

Figure 9. CAP Software Structure

The software suite is tested using industry-standard development tools, such as the KickStart version of the IAR Embedded Workbench® for ARM. Optionally, hardware/software co-simulation may be carried out at this stage if the required tools are available.


19 6364B –CASIC –04/08

Application Developer/Third Party Design House: Emulation on FPGA-based Emulation Board

A key step in the design flow is the emulation of the hardware and at least the low-level software on a CAP emulation board. As illustrated in Figure 10, the CAP emulation board includes a full complement of memories, standard interfaces and network connections together with additional connections that can be configured for the requirements of the application.

CAP

FPGA

FPGAConfig

Memory

PowerSupply

Serial

Debug

US

BH

ost/Dev

Ethernet

I2SA

C97

AD

CM

CI

CA

NIm

age

Sen

sor I

/fFP

GA

Ext

FPG

AU

SB

LCD

Ctrl

Touc

h S

cree

n C

trlP

IOLE

DK

eybo

ard

3XUSBDevice

4X4Keyboard

UserLEDsPowerLED

EthernetP

hyC

AN

Drivers

2XUSBHostUSB

Device

CANBus

Ethernet

2XSD/MMC/

DataFlash

StereoAudioCodec

StereoAudioCodec

Headphone/Line Out

Line InMicrophone

LCDDisplay

Touc

hS

cree

n I/f

AnalogInputs

Image Sensor Inputs

ParallelI/O

FPGAI/O

SerialDebug I/O

StereoAnalog In

StereoAnalog Out

CAP Emulation Board

TouchScreenInput

External Bus Interface

Memory

SDRAMBCRAMMobile DDRAMNOR FlashNAND Flash

Figure 10. CAP Emulation Board Architecture

Specifically:

The fixed portion of the CAP is implemented as single chip with a bonded-out FPGA interface in the MP Block.

A high-density FPGA emulates MP Block including embedded memories and external I/Os.


20 6364B –CASIC –04/08

An FPGA configuration memory contains the compiled HDL code for the MP Block.

The EBI and the external connection from the FPGA are connected to a wide selection of memories on an extension board: SDRAM, Mobile DDRAM, Burst Cellular RAM, NOR Flash, NAND Flash, etc. These are loaded with the software suite and reference data for the application.

All standard Interfaces (CAN, USB, Ethernet, I2S, AC97, ADC, MCI, etc.) are routed through transceivers/phys/codecs to external connections. This enables full test/debug of the external interfaces and networking/communication links of the device.

All elements of the Graphical User Interface (GUI) are connected to on-board devices or interfaces: LCD, keyboard, touch screen interface, etc. This enables the basic elements of the GUI to be tested on-board.

External PIO and FPGA input/outputs are provided for connection to application-specific external devices, and the implementation of non-standard interfaces. The FPGA I/Os include a three-port USB device.

A serial debug I/O connects to the PC that runs a set of industry-standard application development/debug tools.

The CAP emulation board (Figure 11) runs at close to the operating frequency of the final device (the MCU that implements the fixed portion of the device runs at the CAP clock frequency; the FPGA runs more slowly). This enables at-speed testing of the device, both the MCU and standard interfaces in the fixed portion and the functions implemented in the MP Block, together with all the software that has been developed up to this point. At a minimum this includes the device drivers, operating system port and the application code modules that control the functions implemented in the MP Block. Corrections can be made to the software or MP Block hardware elements of the device at no cost penalty.

Figure 11. CAP Emulation Board


21 6364B –CASIC –04/08

The emulation steps are as follows:

Connect the emulation board to a PC running industry-standard development/debug tools.

Re-synthesize the MP Block RTL code including the application-specific modules for the FPGA. The Quartus® 2 Web Edition tools from Altera® can be used for FPGA programming.

Program the FPGA using this synthesized MP Block code.

Compile the software suite for the MCU and peripherals/interfaces as implemented on the emulation board.

Load the application software and operating system onto an appropriate subset of the on-board memories.

Run the application software on the emulation board. Validate the operation of the hardware and software using the validation tools described below.

Debug and correct errors as required.

Experience indicates that this emulation step almost always highlights errors in the hardware and/or software, or the hardware/software interface of the device. The ability correct and re-test the complete design of the device at this stage is a major factor in reducing the design time and cost, and increases the probability of right-first-time silicon and software. An additional benefit is that the emulated version of the final design can be used as the starting point for future design iterations, at a substantial saving of design effort.

Application Developer: Validation of Software Running on the ARM Processor

A JTAG emulator from Atmel or an accredited third-party supplier provides a JTAG-to-USB interface that connects the CAP-ICE JTAG port from the ARM processor on the CAP emulation board to the PC being used to develop and debug the software that runs on the ARM processor. A USB driver for this device enables it to be seamlessly integrated into the application development tools. These enable the software under development to be compiled and run, either at full speed between breakpoints or watchpoints, or under single stepping, while internal registers, signals and memories in the ARM processor and address space (including control registers for peripherals and interfaces) are non-intrusively monitored. This data can be viewed in a variety of formats to aid comprehension.

Application Developer: Validation of Application-Specific Logic in the FPGA

It is essential to provide the same level of traceability for signals and registers implemented in the MP Block as for those in the ARM processor. This is achieved while the MP Block is mirrored in the FPGA during the emulation phase, using either or both of the techniques described below.


22 6364B –CASIC –04/08

1) Tracing Internal Signals by Additional FPGA Bond-Outs

The simplest approach to FPGA debug is to designate internal signals to be monitored as external I/Os. The generous provision of FPGA I/O signals in the CAP emulation board should provide spare capacity for these signals in most cases. However, if sufficient un-allocated I/Os are not available, multiplexing with non-essential operational signals in a test mode is a possibility. This should be treated with caution as it modifies the logical structure of the FPGA relative to the operational version that will be transformed into the MP Block, and can affect the timing of signals on critical paths.

Test signals designated in this way can be examined with logic analyzer or fed, via a suitable interface, into software development tools running on a PC.

2) Instancing Trace Logic in the FPGA

An approach to FPGA debug that comes close to the level provided for the processor core is to use tools provided by the FPGA supplier to instance a number of embedded logic analyzers (ELA) and a JTAG hub into the FPGA. Each ELA is associated with a signal to be traced, together with clocks and triggers. For each ELA, conditions can be specified for the capture of a signal trace depending on the states or transitions of the clock and trigger. The data gathered by each ELA is buffered in one of the internal SRAM blocks that are an integral part of the FPGA fabric. The traced data is gathered in a JTAG hub that is also instanced in the FPGA, and linked to its JTAG port that is carried to an external connection on the CAP emulation board. The ELAs and JTAG hub consume FPGA gates, but are independent of the operational hardware modules that are implemented in the FPGA. They have minimal effect on the timing of operational signals.


23 6364B –CASIC –04/08

EmbeddedLogic

Analyzsers

TracedSignals/Clocks/Triggers

ELA

ELA

ELA

ELA

ELA

ELA

ELA

ELA

JTAGHub

FPGATo FPGAJTAGPort

FilteringLogic

Figure 12. Embedded Logic Analyzers and JTAG Hub in FPGA

In many cases extremely large quantities of traced data are generated by this approach. Some development tools allow for the insertion of filtering logic between the ELAs and the JTAG hub in order to pre-process the traced data, and reduce its volume to manageable proportions.

The FPGA JTAG signal is connected, via an interface provided by the FPGA supplier, to the PC that runs the FPGA development tools. This can be the same PC that is being used for the ARM software development if it has sufficient processing power. The FPGA development tools enable these traced signals to be displayed in various formats and stored for detailed analysis.

The combination of processor and FPGA trace facilities provides the application developer with a fine-grained picture of the behavior of the system-on-chip under development under realistic conditions of operation. In particular interrupt handling and the co-ordination of the different processing elements in the system can be examined in a way that is impossible to simulate. The FPGA emulation usually runs at a lower clock frequency than the fabricated


24 6364B –CASIC –04/08

device, and the probe circuitry can have some impact on the detailed timing of operational signals, but nevertheless the insight provided by these tools is extremely valuable for hardware and software co-validation.

Atmel: Physical Design and Prototype Fabrication

The placement and routing step is carried out by a dedicated team at Atmel, using the established floorplan for the fixed portion of the device and the MP Block. Only the metal layers of the MP Block are placed & routed. A post-layout simulation ensures that no timing constraints have been violated.

Prototype fabrication is likewise limited to the metal layers, drawing on a stock of pre-fabricated base wafers. The fabrication cycle is much more rapid than that for an all-layer product. Exhaustive pre- and post-packaging tests ensure, using the automatically generated test vectors described in a previous paragraph, that the fabricated devices conform to their simulated behavior.

Application Developer: Final Software Development and Application Validation

In parallel with the P&R and prototype fabrication, the application developer is able to complete the application software development, and then test the full software suite on a board hosting the prototype device. Once the device and the software have been validated in the target application, the application developer formally approves the product for volume fabrication.

Atmel: Volume Fabrication

Atmel initiates fabrication of the device in whatever volumes are ordered by the application developer, based on a rolling forecast. By maintaining a minimum stock level of blank wafers, Atmel is able to respond rapidly to variations in application developer demand.

If the volume requirements for the device justify the investment, the complete netlist of the device can be re-mapped onto a full standard cell design, bringing the advantages of reduced die size, enhanced performance at lower power consumption.

Application Developer: Volume Assembly of Application

The application developer integrates the devices and software, together with any companion chips (analog, power/battery management, nonvolatile memory, etc) supplied by Atmel, into the application.

Feedback from use of the application in the field almost always gives rise to requirements for an upgrade to the device. Such upgrades can be rapidly implemented at minimum cost using the design flow, or a subset of it, as described in previous sections. Of particular benefit is the re-use of the emulation board to investigate and test upgrades.


25 6364B –CASIC –04/08

CAP-based SoC Design and Fabrication: Evaluation Atmel’s CAP customizable microcontroller with a metal programmable block comes close to the performance, power consumption and physical size of an equivalent device using standard cell CMOS technology. It has significant performance, power consumption and price advantages over an FPGA, and advantages over standard-cell technology in terms of:

Time-to-market. This is substantially reduced by limiting the design phase to the personalization of the MP Block, place&route to the metal layers of the MP Block, and fabrication to metal layers only.

Design cost. This is reduced by the re-use of the processor core and fixed peripherals/interfaces, and the limited design effort required for the personalization of the MP Block. There is a major saving in mask costs, which are limited to metal masks.

Parallel hardware/software design. The design flow is tailored for parallel hardware/software design. This prevents the software development from becoming a bottleneck. In particular the emulation board enables the hardware and low-level software to be validated at close to operational speed before committing the design to silicon. This gives increased confidence in right-first-time silicon and software.

Conclusion Atmel’s CAP customizable microcontroller serves as an architecture platform for efficient development, validation and upgrade of an application-specific System-on-Chip. The design flow based on its use addresses most of the issues of System-on-Chip design, contributing to lower development cost and risk, and increasing the chances of right-first-time silicon and software.

Editor's Notes About Atmel Corporation

Atmel is a worldwide leader in the design and manufacture of microcontrollers, advanced logic, mixed-signal, nonvolatile memory and radio frequency (RF) components. Leveraging one of the industry's broadest intellectual property (IP) technology portfolios, Atmel is able to provide the electronics industry with complete system solutions focused on consumer, industrial, security, communications, computing and automotive markets.

Further information on the CAP product line can be obtained from Atmel’s Web site at www.atmel.com/at91cap/.

Contact: Peter Bishop, Communications Manager, Atmel Rousset, France, Tel: (+33) (0)4 42 53 61 50, e-mail: [email protected]

© 2008 Atmel Corporation. All Rights Reserved. Atmel®, logo and combinations thereof, AVR®, Dataflash® and others, are registered trademarks, CAP™ and others are trademarks of Atmel Corporation or its subsidiaries. ARM® and others are registered trademarks or trademarks of ARM Ltd. Windows® and others are registered trademarks of Microsoft Corporation in the US and other countries. Other terms and product names may be trademarks of others.

Efficient System-on-Chip Development using Atmel’s CAP...

Documents

Transcript of Efficient System-on-Chip Development using Atmel’s CAP...