The advent of extreme fine line processes at 130nm or less presents many challenges. On the back end, optimizing a design to manage physical effects such as power, heat, and timing is more daunting than ever. At the front end, implementing a system-on-chip’s (SoC) behavior and features is becoming equally difficult. The early exploration of system architectures is now a critical part of the SoC design process that ensures hardware and software engineers have a well-specified and validated context for their work. Furthermore, the increasing adoption of intellectual property (IP) from multiple sources — legacy, third-party, and newly created — means that systems integration is becoming as significant as the implementation of new design components.
Today’s complex systems can have 20 million or more logic gates and multiple memories. There can also be thousands of lines of software that need to be designed, integrated, and verified for proper functionality and timing. Once created as individual components, everything must be validated as working together as a complete system. The conundrum is that back-end hardware design processes still require great detail and accuracy to enable the flow into physical design. For these fine-grained representations, the total quantity of gates overwhelms traditional simulators: their execution speed for the entire system is too slow for the management of software integration tasks. To address the complexity, designers are adopting new levels of design abstraction in the early parts of the design process. The need for new levels of design abstraction is driving the rapid adoption of electronic system-level (ESL) design in production design flows. By adding another level of abstraction to the design flow, the designer can create a fast simulation model or virtual prototype of the full hardware and software platform to perform architectural exploration, profiling for performance analysis, and early software development and validation.
Figure 1. Early system representation enables the iteration of constraints between hardware and software
Enabling ESL design through standards The move to ESL design is not just another design-entry point. ESL environments enable the user to create a virtual prototype of the system design before the detailed hardware implementation is finalized. These models can be considered part of a golden specification for system behavior, and used throughout the design validation and systems integration process. The early system representation provided by ESL design enables the iteration of design constraints between hardware and software engineering (Figure 1). With embedded software becoming an evermore crucial part of any SoC architecture, this technical exchange enables the embedded software architect to become more involved in overall platform optimization.
Figure 2. The system virtual prototype must support mixed levels of abstraction
As the system-level virtual prototype can be used as a golden model long into the hardware and software development process, it will typically contain design IP in different stages of design refinement. The system virtual prototype must support mixed levels of abstraction — from transactional level models (TLMs) for un-timed instruction-accurate virtual prototypes, to cycle-accurate transactional models, to RTL pin-level descriptions (which are also cycleaccurate (Figure 2). The ability to combine multiple levels of design abstraction in one virtual prototype has several advantages. It provides a way to start architectural analysis and software validation earlier. It also allows software to be validated on the actual hardware implementation model to eliminate hardware-software integration bugs earlier in the design cycle. Unfortunately, despite these advantages, the ESL tools and IP market has traditionally been very fractured. This has largely been due to the lack of plug-and-play standards for ESL models and point tools, and has inhibited the adoption of system-level design techniques. However, standards are now emerging, and it is critical that all tools and IP providers consolidate their support for them. The concept of plug-and-play for ESL flows must support at least three technical aspects: the integration of IP models; the integration of retargetable debugging environments for the support of software development and systems validation; and the flow from ESL design to implementation design environments.
For simulation model interfaces, the OSCI SystemC TLM proposal is a set of language constructs for transaction-level SystemC models. It is useful for linking system models into event simulation, such as for RTL co-simulation with ESL models. However, it does not provide a complete API for plug-and-play integration. For fast virtual prototypes taking advantage of the cycle-based abstraction paradigm, the ARM RealView ESL APIs have been provided openly to the industry.
In the case of unified integration of debugging environments, the debugging interface of the RealView ESL APIs provides target-neutral, multi-core debug integration support. Finally, in the case of linking the ESL environment into downstream implementation tools, the specifications of the SPIRIT Consortium can be used. These XML system description techniques target design integration and configurability exchange moving between design environments, as well as the interfacing of point tools and IP generators into design environments in a language neutral way.
A TLM interface for plug-and-play modeling
To integrate a system virtual prototype with IP from multiple vendors and achieve reasonable user control and visibility of that platform, the standard APIs for model integration must cover not just fast simulation, but debug and system profiling. The ARM RealView ESL APIs are a comprehensive set of APIs for full SystemC ESL design integration encompassing all three aspects of model integration. They can be downloaded from the ARM website (www.arm.com).
ARM models that are integrated into third-party ESL environments are provided with the ARM RealView ESL APIs. The broad adoption of ARM RealView models in the industry means that support for the APIs will be widespread, and this is helping to drive a consolidation of ESL APIs across the industry. Carbon Design System’s SOC-VSP product enables designers to automatically create cycle-accurate models from RTL that comply with these RealView APIs, including the transaction, debugging and profiling interfaces.
By adhering to standard model interfaces, ESL tools can provide a way of moving quickly to soft prototypes that are functionally accurate, while enabling concurrent hardware and software development and integration. A virtual prototype created through ESL design can enable embedded software (ESW) development to begin six months earlier than with traditional flows. The profiling capabilities in the tools and models allow a closer coupling of the hardware and software and give the software developers fast-running models that closely represent the final hardware, especially when they have been created from the actual hardware implementation (RTL). The cycle-accurate models enable the design team to begin implementation of hardware-based software, a stage that used to have to wait on delivery of a working hardware prototype.
Enabling the IP model market
The changes in tools and methodologies are only part of the environment. Designers need models of various abstraction levels to cover the full range of speed and accuracy behaviors in the development cycle. The two most important model types are un-timed or timing-approximate (instruction-based, perhaps with cycle-counting), and cycle-accurate.
The former is primarily for high-speed rapid-prototypes. The un-timed models are not used for performance benchmarking or characterization, but as a platform for software development. The cycle-accurate models are used for benchmarking and detailed architectural exploration, and any development of ‘hardware aware’ software.
A broad spectrum of models with varying degrees of functional and timing accuracy is required in an ESL environment because their additional accuracy ultimately reduces the total throughput of the simulation. Therefore, it is important to choose the correct model for the task at hand.
Figure 3. Choose the correct model for the task at hand
Interfacing the ARM RealView SoC Designer to Carbon’s virtual hardware models VHMs
Carbon Design Systems’ VSP Compiler compiles a Verilog, VHDL, or mixed-language RTL circuit description into a high-performance executable object called a virtual hardware model (VHM). This linkable object exports a pin-level C interface and is completely cycle-accurate both internally and at its interface.
ARM offers RealView Models within SoC Designer that also provide an interface that is fully cycle-accurate. These models have typically been created by hand, not extracted from an RTL implementation directly, thereby enabling the model author to take full advantage of the cycle-based simulation paradigm. The ARM RealView models support a port-oriented simulation interface known as the RealView Cycle-Accurate Simulation Interface (CASI). This simulation interface is part of the publicly available RealView ESL API family that includes simulation, debug and profiling interfaces for integrating models and ESL environments. The ports of the CASI interface consist of individual scalar or vector signals, or complex busses such as the AMBA AHB and AMBA 3 AXI protocols.
Carbon’s SOC-VSP includes a component creation feature which generates a RealView-compliant component from a VHM (which is itself compiled from the implementation RTL). An easy-to-use graphical tool walks the user through this process. A batch tool is also provided.
Because the VHM contains a great deal of information about the design (e.g., inputs, outputs, memories, clocks), the integration process is straightforward and highly automated — typing of long signal names is eliminated, sanity checks are performed throughout the process and so on.
First, the integrator maps the pin-level interface of the VHM to RealView signal and transaction port interfaces. Then the user browses signals and memories in the VHM so they can be exported through the component’s debug interface. Some additional information is gathered, and ultimately all the code and support files needed to bind the native VHM interface to the RealView ESL interfaces are automatically generated. Once bound to the RealView ESL APIs, the full capability of RealView SoC Designer’s automated build and advanced profiling and debug features is enabled with VHM models.
The introduction of the component creation capability enables several flows. A designer may now start an evaluation of a design with a hand-created component that acts as a specification. Once the component is implemented in RTL, the designer can use the VHM transformation process to validate the behavior of the RTL implementation in the full system context.
In another possible design flow, the designer can start with the RTL — from previous designs, third-party IP, or ‘orphan’ IP — and create components. The designer can place various combinations of the components into a system and evaluate the characteristics of the architecture.
For example, it might make sense to use an un-timed model for a system’s CPU, while choosing a model with cycle-accurate timing for a newly developed hardware component. Any additional detail about the CPU would be wasted, whereas assessing the fidelity of the newly developed component is essential (Figure 3).
The ability to transform models across layers of abstraction is a crucial part of the transition from an RTL to an ESL design environment, and the lack of this has been a substantial impediment to ESL flow adoption. Sometimes un-timed, transaction level models for IP are available, but often this is not the case.Many times only RTL is available, either from a third party or internal legacy code.
The compiler component of Carbon Design Systems’ SOC-VSP product creates high-performance, cycle-accurate models of RTL designs. These can be integrated into ESL design and profiling tools like the ARM RealView SoC Designer (see sidebar). This tool facilitates the transition to higher and mixed levels of abstraction by removing the manual and error-prone translation process, while introducing simulation performance improvements.
A verifiably correct methodology
Besides tools, designers need to change other parts of their mindsets, methodologies and flows. For example, to get the most out of ESL design, the design philosophy has to evolve from a designverify- instantiate ‘waterfall’ flow to an iterative design paradigm that incorporates an architectural exploration and optimization in parallel with design implementation. The key to any iterative design paradigm is the ability to link views together to validate their correctness at each stage of the refinement process.
Transaction level verification started as just a way to optimize transactional visualization of RTL simulation, and has advanced to true hierarchical system validation strategies. The development of transactors for linking abstract models to refined implementation is allowing ESL design environments to be directly linked into system verification.
Furthermore, as the adoption of transactors for visualizing and controlling RTL verification advances, hardware designers will become more familiar with the transactional interface concept and can move more readily to more abstract modeling styles. The adoption of common interfaces for transaction level IP is helping to drive the development of standard transactors for multi-level simulation, and therefore the delivery of verification IP at the ESL level.
In summary, ESL is emerging as a viable – indeed necessary – part of SoC design. Its viability is increasing with the emergence and adoption of industry-wide standards.
Central to enabling ESL design today is the existence of full design-chain support, with IP providers providing models of IP at the critical levels of abstraction.
Only the creators and vendors of the original IP have the intimate design knowledge and comprehensive validation suites that can guarantee the correctness of ESL models.
As models will be sourced from the IP vendors, it is critical that they are provided to stable, openly accessible ESL interfaces.With the industry wide adoption of standards for ESL design – the SystemC language, the RealView ESL APIs and the flow from ESL to implementation using the SPIRIT Consortium specifications – we are finally able to bring the ‘ideal’ elements of ESL design optimization into the realm of practical SoC implementation.