Nextreme Structured ASICs: An alternative for designing cost-optimized ARM926EJ processor-based embedded systems

by Narinder Lall, eASIC Corp.
Rod Crawford, ARM

Introduction

Designers of embedded systems are increasingly challenged by the need to balance a number of important economic vectors:

• The system must be quick to get to market – as this impacts both revenue and profitability

• The system needs to be competitive as this affects market share

• The system should not require expensive NREs or minimum order quantities – as this impacts both development time and cost

• The system should be flexible to allow for differentiation so that price premiums can be charged in the market and there is greater margin to withstand competitive price pressures

Traditional IC design options that embedded system designers have had to choose from include fixed hardware devices such as standalone microprocessors, microcontrollers and ASSPs or configurable hardware devices such as FPGAs and cell-based ASICs. In this paper we present a new design option called Nextreme Structured ASICs which provide embedded system designers with a compelling alternative to custom embedded system design.

The first part of this paper objectively analyzes each of the available options in turn to understand what advantages (or disadvantages) they provide in relation to the economic vectors described above, i.e. time to market, development cost, unit (or device) cost and the ability for product differentiation. This will be done using a five point scoring scale ranging from “very poor” to “very good”. The second part discusses how Nextreme Structured ASICs can be designed, programmed and debugged.

Design Options and Tradeoffs

• Option 1: Fixed Hardware Architectures (microprocessors, microcontrollers and ASSPs)

Table 1 shows that these products score “very good” for both time to market and development cost for a number of reasons. First, they are essentially off-the-shelf devices and so are readily available. Second, these products have industry standard ISAs and software tools so the learning curve for designers is short. Third, they are not subject to NRE charges like some custom chips and fourth, these products are also inexpensive, especially ASSPs which are often optimized for the target application. Despite these advantages, these products score poorly when it comes to product differentiation as designers can only customize them through software, as hardware is fixed by the vendor. This characteristic means that these products have a greater tendency to give rise to “me too” embedded solutions, that are not well differentiated and hence, price competition is likely to be strong.

• Option 2: FPGA-based Embedded Systems

Next we will examine FPGAs which have also recently emerged as platform options for building embedded systems. FPGAs score “good” for both time to market and development cost. Like standalone microprocessors, FPGAs are off-the-shelf devices that are readily available, but because both hardware and software can be customized development cycles are typically much longer than those for fixed hardware architecture devices. Another downside with FPGAs is that they typically include vendor proprietary processors and ISAs. Leading FPGA vendors initially attempted to embed hardware processors such as ARM and PowerPC but these have had limited market success to date. In fact, Altera, which originally launched an ARM9™ processor-based family called Excalibur, has since discontinued that device altogether. These early devices were followed swiftly with FPGAs that incorporated proprietary “soft” processor architectures such as NIOS (Altera) and MicroBlaze (Xilinx) which have limited instruction sets but better take advantage of the FPGA’s unique architecture. FPGA vendors have attempted to implement softer industry standard architectures but performance has been sub-standard. For example Actel offers an ARM7TDMI® processor with a peak performance of only 29MHz.

Table 2 – Scorecard Summary for FPGA-based Embedded Systems

FPGAs score “poor” for unit cost. While FPGAs have no NRE charges like some other custom chips, the large amounts of interconnect needed for programmability significantly increases die area making them unsuitable for most high volume applications. However, with the ability to customize both hardware and software, designers can develop differentiated embedded systems using FPGAs as performance/feature/area tradeoffs can be made. This gives FPGAs a “very good” score for product differentiation.

• Option 3: Cell-based ASICs

With cell-based ASICs we have a split analysis as can be seen from this Table 3. Embedded systems built using cell-based ASICs score “very poor” when it comes to time to market and development cost. In addition to lengthy product development times where engineers need to worry about design and also silicon verification, cell-based ASICs have a lengthy tape-out to silicon time that can be many months. Once devices are developed software programs can be tested and debugged. One advantage in the software development stage with cell-based ASICs is that unlike FPGAs there are many demonstrated successes using processors with industry standard ISAs.

Table 3 – Scorecard Summary for Cell-based ASIC Embedded Systems

For development cost, cell-based ASICs also score “very poor”. In addition to expensive hardware and software development tools, cell-based ASICs are also subject to very expensive NREs and high minimum order quantities making them a very risky option for all but the very highest volume designs.

Cell-based ASICs do score “very good” for both unit cost and product differentiation. The ability to customize each layer of the hardware and use industry standard processor architectures with very capable instruction sets provides embedded systems built using cell-based ASICs with unique advantages in both unit cost and product differentiation.

• Option 4: Nextreme Structured ASICs

A new option available for embedded system designers is Nextreme Structured ASICs. These devices use a patented via based routing scheme combined with a FPGA-like Look Up Table (LUT) architecture to deliver the combined advantages of both cellbased ASICs (i.e. low unit cost and power) and FPGAs (i.e. no mask charges or minimum order quantities). With the integration of a firm, industry standard ARM926EJ processor and peripherals, Nextreme Structured ASICs provide designers with a compelling new option for creating and developing customized embedded systems. Table 4 shows the scorecard.

Nextreme Structured ASICs score “good” for time to market. On the plus side, these devices exploit an industry standard ARMv5 ISA and turn around time for receiving custom silicon is only 3-4 weeks. Conversely, like other custom chips development time is likely to be longer than standalone devices as both hardware and software need to be customized. Designers can also use co-design techniques for making performance/ feature/cost trade-offs between implementing tasks in hardware or software. While this is a powerful capability, it can result in more development time over solutions that do not offer this capability.

Nextreme Structured ASICs also score “good” for development cost. Low cost (FPGA like) development tools are available for both hardware and software design, and designers can also access these custom devices with no mask charges or minimum order quantities, again like FPGAs. Unlike cell-based ASICs, designers using Nextreme Structured ASICs do not need to endure the pain of silicon, gate level verification and test.

Nextreme devices score “very good” for both unit cost and product differentiation. As mentioned earlier, they enable performance/feature/cost tradeoffs through hardware and software customization or co-design and while unit cost is not exactly that of an all layer customizable cell-based ASIC, it approaches that cost. That said, even for reasonably high production volumes, the cost-of-ownership for Nextreme Structured ASICs will be lower as unlike cell-based ASICs, as there are no mask charges or minimum order quantities with Nextreme Structured ASICs.

Table 4 – Scorecard Summary for Cell-based ASIC Embedded Systems

In the next section we will first look at the design tools and flow needed for creating a customized ARM926EJ processor-based subsystem onto Nextreme Structured ASICs and then discuss the tools and flows needed for developing and debugging application code.

Creating an ARM926EJ Subsystem on Nextreme Structured ASICs

Figure 1 shows the design flow for creating an ARM926EJ processor-based embedded sub-system onto Nextreme Structured ASICs. To start an ARM926EJ processor implementation you first need an ARM926EJ processor design kit from eASIC and a set of compliant peripherals. This ARM926EJ processor design kit is essentially a behavioral model that includes all the necessary timing models for both pre-and postlayout simulation. Peripherals can be obtained from open source sites or eASIC eZ-IP Partners such as CAST. CAST’s Peripheral IP AMBA (PIP AMBA) package includes a comprehensive range of peripheral IP for building small or large sub-systems. This IP includes timers, a microprocessor interface, an address decoder, APB bridge, parallel IO, an SRAM controller amongst others. To facilitate faster time to market, CAST also provides the necessary software for the cores including boot code, interrupt service routines (ISR), main routine with optional task scheduler, peripheral driver code and hardware level API.

Figure 1 – Design Flow for Creating an ARM626EJ Sub-system on Nextreme Structured ASICs

Coding RTL

RTL formats including Verilog and VHDL are supported. The RTL can include a combination of ARM926EJ processor(s), AMBA® PrimeCell® peripheral IP, interfaces and memory controllers, customized logic and signal processing blocks (e.g. filters, H.264). eASIC provides free front-end design tools for assigning I/Os, generating memories, configuring clocks and checking RTL compatibility with Nextreme silicon.

Simulation and Validation

The flow makes heavy use of industry standard tools from leading EDA vendors. Simulation and validation is done using industry standard tools such as Mentor Graphics ModelSim, Cadence NCSIM and Synopsys VCS. Static timing analysis using sign-off grade tools such as Synopsys’ PrimeTime and Magma QuartzTime and RC Extraction is also done using industry standard tools like Synopsys’ StarRC-Xtract and Magma QuartzRC.

Synthesis

The design flow also makes use of industry standard synthesis tools such as Magma Blast Create SA eASIC which supports both RTL synthesis or netlist entry and Synopsys DC Compiler which also supports both RTL synthesis or netlist entry. Special package and price for Magma Synthesis Blast Create SA eASIC tools are available from eASIC.

Placement and Optimization

Once again this is performed using Magma Blast Create SA. Once the processor, peripherals, logic, interfaces have been placed users require eASIC's free back-end eTools to perform configuration and routing. These eTools also generate the necessary files that are needed for routing, timing analysis, formal verification, ATPG and chip assembly

Device Fabrication

Finally the device needs to be fabricated, assembled and tested. eASIC’s patented via masking routing technology shortens turnaround time for Nextreme Structured ASICs to only 3-4 weeks. Designers can choose from two device options: the SL device and the VL device. The SL device enables logic eCells to be reconfigured using external flash memory making this an ideal device for prototyping. The VL device fixes the contents of logic eCells so that the external flash memory can be removed making this option the most cost-effective for high-volume production. When moving from an SL to a VL device there is no need to revisit timing closure or requalify the device. As mentioned earlier the ARM926EJ processor is a firm processor that consumes 23K eCells which are like FPGA logic cells. This means that it takes up ~45% of a small Nextreme NX750 device and only ~7% of a large NX5000 device leaving ample space for peripherals and customer logic.

Developing and Debugging Applications Software

Figure 2 shows the design flow for developing and debugging software code for the ARM926EJ processor-based embedded sub-system. Once the ARM926EJ processor subsystem has been developed the application software needs to be developed. For this stage designers can tap in to the ecosystem of ARM’s Connnected Community to find the right tools and platforms for their specific task. In addition, ARM RealView® DEVELOP family of tools can be used. These include the following members: RealView Development Suite and RealView ICE.

Figure 2 – Design Flow for Developing and Debugging Software Applications for ARM626EJ-S Processor Sub-systems on Nextreme Structured ASICs

The ARM RealView® Development Suite is used for developing, debugging and deploying applications onto the Nextreme Structured ASIC embedded system. RealView® Development Suite is a complete, end-to-end solution for software development that supports ARM processors and ARM debug technology. It incorporates compilation tools, symbolic debug, profiling and integration with the open-source Eclipse IDE. The RealView® Development Suite enables developers to use Eclipse as a project manager to develop, debug, and manage C and C++ projects their Nextreme Structured ASICs.

Compile

The compilation tools in the RealView® Development Suite provide optimum support for the ARM architecture. They deliver the full set of software components required to build C and C++ applications targeting the ARM926EJ processor including:

• Fully compliant optimizing ISO C/C++ compilers and libraries

• A linker that supports

• ELF and DWARF industry standards for object file and debug table formats

• Seamless interworking of ARM Thumb® and Thumb-2 object code; both of which are supported in the ARM926EJ Nextreme Structured ASIC

• Placement of code and data within sophisticated target memory maps

• Automatic removal of unreferenced code areas

The compilation tools also contain a powerful macro assembler for ARM and Thumb code and an image conversion tool to convert ELF format images into other downloadable and ROMable formats such as Motorola S-Records and Intel Hex. One other area worthy of note is that the compilation tools allow developers to mix-andmatch object code generated by the GNU toolset and the RealView® Development Suite. This is achieved through both toolsets supporting the Application Binary Interface (ABI) for the ARM architecture. Developers who want to run Linux on their Nextreme structured ASIC can now compile large Linux application libraries using the compilation tools, which can lead to significant reduction in code size and increased performance.

Debug

The RVDS debugger allows users to debug one or multiple ARM processors in a Nextreme Structured ASIC using a single debug environment. Multiple windows are available for numerous processors and views. The run control operations start, stop, breakpoint, and single step of each processor can be operated independently or synchronously. A common debug kernel facilitates multi-processor run control debug operations for examining and debugging the interaction of the software running on the different processors on the system.

Cross triggering of multiple processors is supported and enables the synchronous stopping of multiple processors when a breakpoint is hit on any of the processors. These features allow the entire system to be paused to examine the state of each processor, preventing data from being processed (lost) while examining the state of the multi-processor system. The RVDS debugger also supports OS aware debugging for a broad range of RTOS.

A key requirement when debugging a multi-tasking application is watching the interaction between different threads or processes (execution contexts) and the resources they are using. Developers can view the source and states of multiple threads (execution contexts) on multiple processors at once by creating a set of debug windows for each execution context they are interested in. The RVDS debugger supports two kinds of OS aware debug:

• Debug of a halted target system (hereafter termed halted system debug) where everything on the target has stopped either due to a crash or under control of the debugger.

• Debug of a running target system (hereafter termed running system debug) where some or all of the target system continues to run.

Host/Target debug connectivity

RealView ICE and RealView® Trace solutions interoperate with the RealView® Development Suite to offer host/target debug connectivity and non-intrusive trace of software running on a design. RealView ICE is the JTAG run-control unit that can connect the debugger in the RealView® Development Suite directly to the ARM926EJ processor in your Nextreme Structure ASIC. The unit supports both Ethernet and USB-2 connectivity.

In addition to connecting to the RealView® Development Suite debugger, the RealView ICE can also connect to GDB. This can be useful for such things as Linux application debug where the RealView® Development Suite debugger is used to debug the Linux kernel via RealView ICE and GDB/GDB Server can be used to debug Linux applications again using the RealView ICE. The RealView ICE in the latter case serves as a virtual Ethernet connecting for asynchronous debug communications channel (DCC) on the ARM926EJ processor.

RealView Trace is an optional add-on expansion module for RealView ICE and provides non-intrusive real-time tracing of instructions, data and profiling for performance analysis. The debugger in the RealView® Development Suite provides capture and display of a historical, non-intrusive trace of instructions and data accesses in real time. This allows successful debugging of defects that can be otherwise impossible to track down through traditional step and go debugging methods.

Trace capture conditions may be defined using a set of powerful trigger conditions. Once trace capture has occurred, the debugger provides multiple display options to quickly hone in on code hotspots or bugs. Captured trace data may be used to provide an execution profile, enabling developers to quickly analyze critical code sections such as boot time, interrupt latency and task switching overhead.

Summary

This paper has demonstrated a new compelling alternative solution based on Nextreme Structured ASICs, for embedded system design. This solution provides a strong balance of benefits for important economic vectors that embedded system designers are faced with today. Barriers to entry are low as designers can use low cost, industry standard design tools to gain access to Nextreme Structured ASICs.

For more information please visit www.eASIC.com.