System-level design matures

For a long time, users of electronic system level (ESL) design have sought methods to quickly capture the basic structure of a new system-on-chip (SoC) or silicon intellectual property (IP) component early in the design process. Logic and functional flaws are still the predominant reason for SoC respins. This is driving ESL adoption. Fast-executing transaction-level system models can uncover these types of operational and architectural defects early in the design process. ESL thus provides a way to eliminate the dominant risk in ASIC design today.

1.1 Bridging the Model Gap:

The Need for Multiple Levels of Abstraction When we look at the complete design flow, we find modern large SoC designs need models for a wide range of uses at the system level:

• Models of the new design for architectural exploration;
• Models of existing IP for reuse in architectural exploration;
• Models for the software team so firmware development can start early;
• Models for the hardware designers, for verification of the component implementation;
• Models for system verification against the system level design;
• Models for third parties who may be developing part of the hardware or firmware, or who may be customers wanting early visibility.

Not all of these models are at the same level of abstraction. Component hardware verification uses traditional RTL models that can show signal strengths and intra-cycle timing. Software developers need much faster models for realistic software development, but do not need so much timing accuracy. Figure 1 shows the range of modeling needs graphically.

Figure 1. Spectrum of SoC representations: hard and soft prototypes

1.2 The features of a mature ESL design flow

Recent developments in model interface standardization are making ESL design and tool-flow integration significantly less painful. In the case of the language and design environment- neutral exchange of architectural specifications, the meta-data schema and database APIs of The SPIRIT Consortium are gaining strong traction in the industry. In the case of model interoperability, IEEE 1666 for SystemC defines a common base language for model authoring and the specification of interfaces.

The features of a complete ESL tool flow are now well understood:

1. It must be based on a TLM-aware graphical design environment.
2. It must incorporate validation checks (e.g., Do bus widths match? Are address maps disjointed?).
3. It must include the ability to execute, debug and profile the complete system to facilitate architectural exploration, software development and system verification.
4. It must include the ability to convert design models from a low-level of abstraction to higher levels of abstraction.
5. Its implementation extensions will need to include the ability to convert design models from a higher level of abstraction to lower levels of abstraction.
6. It must be able to show that models at different levels of abstraction are equivalent.
7. It must include the ability for models at different levels of abstraction to work together.

1.3 A brief description of the tools

1.3.1 ARM RealView SoC Designer

The RealView SoC Designer tool includes strong support for standards that help drive adoption of ESL. SoC Designer is the first production ESL tool to support the IP-XACT specifications from The SPIRIT Consortium with import and export of system design files. The tool is also OSCI SystemC compliant, including support for the OSCI TLM standard and the SCV (SystemC Verification) Library. The tool supports the powerful and freely available RealView ESL APIs for AMBA Certified CC (Cycle Callable) transaction modeling of the ARM AMBA interconnect specification.

The SoC Designer tool is divided into two main functional areas: Prototype creation and simulation.

Figure 2. SoC Designer Canvas window for platform prototype creation

1.3.1.1 Prototyping with the SoC Designer

Using the schematic capture capabilities of the tool, system architects can rapidly prototype platform designs in the SoC Designer Canvas window (Figure 2) from component building blocks in the tool’s IP library. The graphical environment gives the user a powerful hands-on method for placing, connecting and configuring components into a complex SoC design. Native support for the RealView ESL APIs yields cycle-accurate prototyping of AMBA transaction-level interconnects with the ease of graphically connecting component ports, while the memory map for multi-layer and multi-region interconnects can be viewed and configured from a single point in the tool’s Memory Map Editor.

Several model library options are available for the SoC Designer tool, including both processor and non-processor IP from ARM as well as from other IP vendors, including Ceva, Infineon Technologies, LSI Logic and MIPS.

1.3.1.2 Simulating with SoC Designer

The SoC Designer Simulator can be launched from the SoC Designer Canvas to explore a current platform in design. It can be run in batch mode for regression testing and validation. Or it can be run standalone as a target for software development. The simulator includes an optimized hybrid cycle-based and event-driven kernel. The cyclebased kernel executes on average 10X the performance of the OSCI reference SystemC simulator. Profiling windows allow the designer to examine transactional and statistical data about the running system

1.3.2 Tension VTOC with VTRAC technology

Tenison VTOC takes RTL designs and converts them to SystemC and C++ models at higher levels of abstraction: At its heart, VTOC is a synthesis technology. The same detailed dataflow analysis used by traditional synthesis engines is used to raise the level of abstraction of the model (Figure 3). The resulting models are two-value and cycle-accurate.

VTOC Validate is used to show equivalence between model behavior at the RTL level and the cycle-accurate, two-value level of VTOC.

1.4 Integrating the tools into a modeling flow

The ESL design flow must enable the architect to move smoothly between fast cycle-accurate models built specifically for architectural design and firmware integration, and models extracted directly from the RTL.

For cycle-accurate models extracted automatically from the RTL, such as VTOC models:

• Every clock edge is modeled;
• Every top-level asynchronous path through the model is modeled;
• The value of every state-holding register is preserved on every clock edge and every asynchronous path;
• Multiple delta-cycle evaluation of the design is faithfully modeled.

At the other end of the cycle-accurate spectrum, intra-cycle functionality is assumed valid and the results of computation or communication are presented only on the positive cycle boundary. This cycle abstraction enables models to be much faster than event-driven cycle-accurate models. This is because, for IP such as bus components and processor cores, there is a very high utilization of bus interfaces, so the need for updates to data on these interfaces on every clock cycle is highly probable. It is more efficient to assume the need to assess the state of the interface on each clock than to maintain an event queue.

This is the basis of the ARM RealView ESL APIs, and the interfaces natively supported in the RealView SoC Designer tool. For the cycle-based execution of the ARM RealView ESL APIs:

• Only the active clock edge is modeled;
• Top level asynchronous paths through the model are not modeled;
• A small subset of the internal state is preserved—quite commonly just the top level ports;
• There is only a single delta-cycle for each full clock cycle.

1.5 Customer experiences of ESL

The following real examples are from customers of the joint ARM/Tenison solution where the deployment of this ESL strategy revealed system bugs that would have been extremely difficult to locate in a traditional RTL simulation.

1.5.1 PCI bus performance

The hardware implementation of a novel and very high performance PCI bus was in progress. The team used Tenison VTOC to create a cycle-accurate model of the latest design each night for use by the software team during driver development. These models were deployed within SoC Designer for system simulation. To test the performance of the device drivers, the software team instantiated three instances of the cycle-accurate model on three workstations and connected them together over Ethernet. They then tried running traffic through the bus.

Figure 3. Overall system simulation speed increases as individual models become more abstract

It was at this point they realized that the hardware implementation was so efficient that the firmware could not keep up, no matter how efficiently coded.

They were able to influence the design team, who introduced appropriate delays in clearing registers for the implementation. Here, a rich ESL development environment allowed feedback loops to run efficiently between teams throughout the design flow. In this case, the software team was validating some assumptions made during architectural exploration with the actual implementation. Spotting this error avoided a respin.

1.5.2 Protocol Compliance of AHB Implemenation

A customer recently implemented a peripheral with an AMBA 2.0 AHB master interface. This had originally been designed as a TLM in the RealView SoC Designer tool, and tested with a transactional testbench implementing slaves to the AHB interface, providing a stream of read and write data on the bus.

To test the actual implementation, the RTL was converted by VTOC with VTRAC. This yielded a model with a transaction-level interface for incorporation within the SoC Designer tool.

System verification runs quickly showed there was a mistake in the RTL implementation. In its bus arbitration, the master was asserting the address signal (HADDR) in the same cycle as the bus grant (HGRANT) signal. The AHB 2.0 protocol requires a one cycle delay before asserting the address signal.

Because VTRAC is based on a formal specification of the AMBA 2.0 AHB protocol, it could detect this non-compliance, and advise on the cause of the problem (section 3.11 of the AMBA 2.0 spec). This problem would probably have been found by traditional testing, but only through the construction of an exhaustive set of test vectors for various AHB sequences. By using an ESL methodology with mixed abstraction, the testbench complexity and the time taken to find the problem were greatly reduced.

2. Conclusions

Traditional system level design cannot scale to modern designs with 100 million gates or more. This can be seen in today’s high rate of respins due to failures in the functional and logical verification of chip implementations.

We summarized the problem as:

How do we bridge the gap between the highly abstract view provided by traditional system-level design and the detailed implementation in RTL? An ESL methodology adds tool-based rigor to traditional systemlevel design. Central to this is ability to model a system at multiple levels of abstraction.

The emergence of standards means that ESL tools can now interwork effectively, allowing a complete ESL flow to be used for commercial chip development.

An ESL methodology reduces the risk of respins and shortens design time. Like any new flow, it introduces new challenges. In this paper, we have illustrated some of those challenges, based on our customer experience with the ARM RealView SoC Designer tool and Tenison VTOC with VTRAC technology.

We have described how challenges have been met, and highlighted the positive benefits to be gained from ESL design methodologies. As a result, customers are successful in designing ever more complex chips, on ever shorter timescales, with ever fewer respins.

ARM
110 Fulbourn Road
Cambridge
CB1 9NJ
UK
T: +44 (0)1223 400400
W: www.arm.com

ARC International acquired Tenison Design Automation in 2007.