SoC Configurable Platforms -> Co-verification tools vital to SoC mix

"Disruptive technology" appears to aptly describe today's system-on-a-chip (SoC) designs, which harbor seemingly limitless transistor capacities. SoC methodology

is continually evolving throughout the microelectronics industry. But SoC projects were initially undertaken only by companies with deep R&D pockets. Early adopters funded tool flows and designs that sometimes surpassed $15 million per project.

The difficulties facing SoC designers remain formidable, partly because the design s require functionality to be implemented in both hardware and software. Some functions, such as peripherals, require special-purpose hardware on chip, and other functions, like networking stacks, are best implemented in software on a general-purpose processor.

To evaluate the effect of different design decisions, users must be able to run large applications on simulated SoC hardware. Hardware/software co-verification tools provide designers with fast software execution and faithful simulation of custom hardware. As a result, co-verification can significantly reduce the time required to design and implement an SoC solution. It is also often the only way to identify whether a bug is caused by hardware or software.

But despite a massive R&D investment in industry and academia, the co-verification tools needed for SoC are slow to gain acceptance within mainstream design flows. Of course, those tools are useful only when an existing processor core represents a large component of the design. And S oCs that use custom processor engines cannot be modeled by co-verification tools.

Co-verification tools are gaining favor for three main reasons. First, there's the ever-increasing pressure to slash time-to-market. Co-verification tools help validate SoC solutions before any hardware is built. Second, there is the gradual transition to increased software complexity. And finally, there is the daunting complexity of overall designs. The integration of intellectual property (IP), DSPs, memory chips and additional functions constitute an essential component in many designs.

Implementing existing IP blocks also poses challenges for SoC designers. Many IP blocks have incompatible interfaces, requiring significant custom glue logic. By synchronizing system hardware and software development throughout the design process with co-verification tools, designers have reported design cycle reductions greater than 30 percent. Traditionally, hardware and software have not been tested together for consistency and accuracy until a prototype is created. Co-verification makes it possible to simultaneously verify hardware and software interactions. The entire design process also changes, because co-verification brings software and hardware teams together earlier in the design cycle.

Configurable processor cores, just like off-the-shelf processor cores, are a component of SoC ASICs and they provide SoC designers with flexible design alternatives. Designers can add custom instructions and coprocessors to significantly increase application performance. Configurable processors and custom instructions can lead to as much as a fifty-times improvement in the performance of key software algorithms.

Configurable processors enable designers to meet performance targets, power budgets and strict cost considerations. In the best-case scenario, a configurable model will produce the entire software tool chain for each configured processor. This includes the compiler, linker and link scripts, instruction set simulat or and debugger tailored for each user's instruction set architecture.

By teaming configurable processors with co-verification tools, designers can make speed, power and code density adjustments on a virtual platform, making it easier to optimize a processor for a particular application.

32-bit processor

Mentor Graphics created the first co-verification platform to model a configurable processor, in this case Tensilica's Xtensa 32-bit configurable processor, widely used in communications and networking applications. The Xtensa's configurable options include-but are not limited to-custom instructions and functional units, instruction and data cache size and optional fast instruction or data RAM or ROM.

The model for the Xtensa processor consists of two components: an instruction set simulator (ISS), which is a fast, cycle-accurate emulation of the processor, and a bus interface model (BIM), which models the processor interface signals of the Xtensa core. The BIM runs wit hin a standard HDL simulator as a component connected to user peripherals and memories.

A console allows designers to set up a memory map for the system and to control how that memory is modeled. The software (ISS) and hardware simulation run as separate processes, communicating through the co-verification environment. The ISS runs an Xtensa program and controls the execution of the model.

The Xtensa Processor Generator allows designers to customize a processor's instruction set, interrupts, memory and peripherals to suit application needs and generate cycle-accurate hardware/software processor support packages (PSPs). The BIM is distributed with an example test bench, including memory models, example programs and scripts, to run co-verification. With it, a designer can be up and running programs in a matter of minutes. The PSPs are created and can then be downloaded from the Tensilica Web site, enabling embedded system developers to optimize software and processor hardware for speed, power a nd feature requirements. Engineers report that there are many design alternatives to consider within the realm of configurable processors, making co-verification tools vital to quickly evaluate the various designs.

Using configurable processors also presents a few twists. Some tasks are easy, like determining the width of the interface to external memory. But others are more difficult, like deciding which functions to build as a dedicated hardware block and those to implement as custom instructions in the processor.

For instance, the Data Encryption Standard (DES) is a common algorithm for data encryption. This algorithm is often implemented in hardware as part of an embedded system-for example, inside an IP router or a set-top box. An alternative is to implement the DES algorithm by adding custom instructions to a configurable processor; the instructions perform the same operations as a dedicated hardware implementation. Adding four instructions to the Xtensa processor leads to an improved D ES algorithm that runs between 40 times and 80 times faster than a highly tuned software implementation on the same processor. The new instructions add about 5,000 gates to the core and do not affect the cycle time of the processor.

Configurable processors attract designers who are pushing technology limits and want better performance at a lower cost. But there is less impetus to change to a configurable solution if a designer is running a low-performance application or has a vested interest in a different processor. Some designers may also balk at partnering with a vendor of configurable processors, since most of these companies are new to the playing field.

Hurdles remain

Many hardware and software engineers are also hesitant about using co-verification tools. Several reasons are cited: the methodology is relatively new, the tools don't support all processors and can be cost prohibitive, plus it takes more than a modicum of time and effort to become proficient with them.

But despite the reluctance by many to migrate to configurable processors and co-verification tools, it appears that the disruption of traditional design methodologies has already begun. Time-to-market pressures alone are driving the need for even more complex designs and faster, more efficient ways to produce silicon.

Because configurable processors and co-verification tools make possible dramatic time-to-market savings, they have become "disruptive" technologies in their own right, and designers who embrace them will position themselves well. Complacency in high-tech may be the 21st century version of leg irons.

Network synchronization relies on CSoC

When Datum's engineering team set out to develop a new family of embedded synchroni zation solutions, it faced many challenges. This family of products, known as TimePieces, was designed to synchronize the transmission of voice, video, and data for a wide array of multiservice applications, including time-division multiplexed, Sonet, asynchronous transfer mode, code-division multiple access and Voice-over-Internet Protocol. The TimePieces chips had to be scalable and auto-configurable to handle constantly changing industry requirements. These chips were designed to work around a core chip known as SmarTiming, which would measure, qualify, and select input references based on system requirements and then output a very stable, accurate and reliable timing signal.

Designed to be used stand-alone or as a timing system, the TimePieces chips communicate through a patent-pending protocol referred to as the TIB (TimePieces Interface Bus). Through the TIB, TimePieces automatically configure interconnected chips into timing systems. This allows the end customer the freedom to utilize individ ual chips to meet a specific need, or build whole systems to meet their sync needs for each application.

Each chip is designed to meet specific portions of the various telecommunications timing standards. When operating as a system, it is possible for the end customer to meet whole timing system specifications. The basic functionality provided by a chip set system includes custom I/Os, Stratum 3 or 3E oscillator, a standard-based timing controller and an 8-bit parallel library communications.

In order to provide the needed functionality and design flexibility, each solution required a minimum of a microcontroller and some type of configurable logic. Because of certain application constraints, Datum chose the standard footprint size for the board to be a 68-pin and an 84-pin PLCC measuring just over an inch square. Datum also needed to develop the TimePieces family quickly in order to meet critical customer demands.

Datum explored the use of a microcontroller and an FPGA but was face d with design issues. A standalone microprocessor was very limited by the RAM and flash storage available on-chip, and with the addition of an FPGA, the design violated the board size constraints laid out in the selection of the standard footprints.

With just over a square inch of board real estate in the largest footprint, the designers were faced with the task of getting as much functionality as possible into the small footprint. With TimePieces aimed at the OEM market, the designs were also cost-sensitive, and most solutions exceeded the cost budget laid out by the marketing team.

By integrating Triscend's E5 Configurable System on Chip (CSoC), Datum was able to get more usable gates than with a microcontroller/FPGA combination, and the design still fit within the small footprint dictated by the PLCC. Triscend's CSoC solution also provided the best time-to-market scenario.

Basically, the Triscend E5 CSoC integrates, on a single device, a performance-enhanced 8032 "Turbo" embedded microcontroller, embedded programmable logic, a high-speed dedicated system bus, and a large block of SRAM intimately connected to the processor and system bus. The E5 provides a highly integrated, fully static single-chip platform that can be quickly optimized for a wide range of embedded systems applications.

The embedded high-performance 8032-based "Turbo" microcontroller is instruction-compatible with other industry standard 8032/52-based devices. Thus, Datum was able to leverage the vast software library for the 8032 architecture.

The embedded SRAM-based Configurable System Logic (CSL) matrix provides "derivative on demand" system customization-up to 40,000 gates. The high-performance configurable logic architecture consists of a highly interconnected matrix of CSL cells. This embedded configurable logic allowed Datum to rapidly evolve product designs to match changing industry protocols. Resources within the matrix provide easy, seamless access to and from the internal system bus.

A large block of fast, byte-wide SRAM provides internal storage for temporary data or for code. Though typically used for data, code can be executed from internal RAM, offering faster access plus security in battery-backed applications.

The E5's IEEE 1149.1 JTAG port offers nearly full access to the microcontroller, peripherals, and CSL functions to aid in debugging. The JTAG interface can become a bus master on the internal CSI bus. During system debugging, the JTAG port also sets up the internal hardware breakpoint unit.

The debug time in a design cycle is usually the most arduous and time-consuming phase of design. Because of the in-circuit testing and development environment provided by Triscend's FastChip development software, Datum was able to spend less time in debugging the design, thereby reducing time-to-market. Utilizing this environment, Datum was able to perform all debugging and development for both hardware and software through a single JTAG port. This was particularly attractive because there is a blur of hardware/software functionality within the TimePieces devices. The ability to have the hardware and software developers utilizing the same development environment aided in shortening the project time.