Open system platform accelerates SoC development

Such an approach is critically needed for high-performance communication and networking SoCs that typically contain multiple processors, coprocessors and high-speed memory systems.

A key element in the success of such an approach is the use of a methodology based on an open platform-based approach for clock-accurate simulation of SoC hardware and software. The platform, referred to as an Open Simulation Platform (OSP), is built by assimilation of accurate hardware simulation models in C/C++ from various sources (both internal and from external intellectual-property providers) with custom verification harnesses and hardware-software debug tools. An OSP incorporates a clock-accurate simulator of the hardware, referred to as a full-chip simulator that can be delivered in protected form to internal or external embedded software development groups, allowing true concurrent software development on the simulated hardware platform.

There are two primary needs for control-dominated SoCs in an embedded environment. One is the ability to verify specifications with clock accuracy via simulation s early in the design cycle. This requires simulation models of hardware for software development and for projecting performance expectations. The second is the ability to achieve high change productivity from product specifications to design to support the iterative nature of these designs.

Product specification changes are driven both from implementation difficulties and changing marketing requirements during SoC development. New components may have to be developed to get the best SoC performance with the embedded software.

Co-development requires a simulation solution that supports integration of designs supplied by different vendors, embedded software development, and SoC functional and performance verification. Typical hardware-software co-development activity consists of a debug session for embedded driver software running on one CPU or more.

The software developer sets a breakpoint in the code and runs the executable in his or her favorite debugger until the breakpoint is rea ched. At this point, the simulation clock for that CPU is stopped temporarily, to allow the software developer to examine register and memory contents, observe waveforms of the signals at hardware-software interfaces, and observe the activity in the other CPUs.

The origin of functional problems can be traced rapidly to hardware or software using source-code debuggers and timing diagram viewers. Software problems can be fixed immediately. If the problem is hardware-oriented, a fix can be made to the hardware models. By examining the concurrent design flows needed to support co-development, it becomes evident that co-development is an added step to existing methodologies, an investment which design managers need to consider for current and future projects.

In addition to functional verification, system performance can be measured accurately through simulation. Frequently , performance improvements can be driven by small changes such as changing FIFO sizes, prioritization schemes, memory wait states, and so on. Simulation of embedded software with the hardware can eliminate the guesswork in performance changes, allowing early architectural optimization. Different verification scenarios can be executed in parallel on multiple machines to provide the data needed to make SoC optimization decisions to meet application-level performance goals.

OSP bridges the gap between hardware and software development environments, and is a non-disruptive addition to the existing register-transfer level design flow. The use of a single source for the hardware and software models and a single simulation process for integrating hardware and software debug environments makes true hardware/software co-development a reality.

One of the more challenging tasks in creating a simulation platform for hardware-software co-development is the integration of the various platform components. The challenges for doing so arise from the variety of models, tools, internal verification flows and debug environments from different vendors that need to co-exist on the simulation platform. The SoC platform needs to be built and accessed using open standards: API (application program interface) functions that resolve the software architectural problems of the multi-component, multi-tool environment and are freely accessible to hardware and tool developers.

There has been growing interest in the IEEE 1499 standard called OMI (Open Model Interface) for integrating models, simulators, debuggers and external tools. OMI is a simulator-independent and HDL-independent interface between an EDA tool such as a simulator and a black box model of a block of intellectual property. This interface allows interoperable models to be developed, distributed and used with any compliant tool without exposing the internal structure or operation of the model. EDA vendors such as Cadence Design Systems Inc. (San Jose, C alif.) and Denali Software Inc. (Palo Alto, Calif.) are providing OMI-compliant models and environments to facilitate platform assembly and delivery. The use of OMI needs to be proliferated through high-productivity tools. The shortening SoC design cycles demands quick full-chip simulator assembly and delivery and fast turnaround times on bug fixes or enhancements. The adoption rate of using simulation for software development hinges greatly on the availability of high-speed accurate hardware models. Hardware simulation models developed in C or C++ is the natural choice for a simulation platform because of its speed and flexibility for linking with design and debug tools through APIs.

Most system-level testbenches and hardware algorithms are developed in C. CPU architects have recognized the importance of C models and spent resources on developing models for their embedded CPUs. For ease of integration inside a simulation environment and for the best simulation performance, it is very important that all C models be callable from an external C main() function as opposed to requiring an independent simulator — for example, instruction-set simulators (ISS) that run as separate processes.

Since the embedded CPU only comprises roughly 15 percent of the hardware on a typical SoC, the problem of C model availability needs to be addressed for coprocessors and peripherals as well. Hardware designers predominantly use hardware description languages (HDL) such as Verilog and VHDL to develop these components because of the explicit support for timing and concurrency in these languages. With the advent of C++ design languages such as SystemC and Cynlib that use C++ class libraries to extend C language's sequential capabilities to those of HDLs, there has been an impetus toward building support for C++ models, especially for new designs. For existing design IPs, hardware-software co-development is possible only if RTL designs in HDL can be converted to C simulation models. Companies such as Cynergy and F orte Design Systems Inc. (San Jose, Calif.) provide tools to automate the process of converting HDLs into C/C++ through their respective tools, Afterburner and Cynchronizer.

Another key component of an SoC is the memory system. To address the memory bottleneck problem, memory vendors are developing new memory architectures focused on high-bandwidth networking and communication applications. New, fast memory systems have increasingly complex access protocols. Denali Software provides clock- and timing-accurate C models for all commercial memories along with an OMI-based interface for hooking these models into HDL and C simulation as well as commercial testbench tool environments.

The full-chip simulator created from hardware C/C++ models can serve various purposes, such as system verification, embedded and application software verification and system performance profiling. For each of these applications, the model accuracy requirements are different. For instance, system and embedded software verification requires the associated hardware models to be clock-accurate to obtain the correct functional and timing response from the simulation. For application software development, ifunctional accuracy for the CPU and bus is sufficient. Typically, new hardware components designed for control-dominated SoCs will require clock-accurate simulation models. The integration platform should enable rapid substitution of models at different accuracy levels.

The simulation speed of the full-chip simulator depends heavily on the abstraction level of the models used to build the full-chip simulator. Hardware design is a stepwise refinement process, from bit-accurate (functionally accurate) models, to bit- and clock-accurate (interface clock-accurate) models, and finally to bit-, clock-, and internal pin-accurate (RTL-accurate) models.

The simulation environment must support a mix of models at different abstraction levels to obtain the best possible simulation speed for the full-chip simulator early in the design process. For most system and embedded software verification and tasks interface clock-accurate models are sufficient.

Some of the commercial solutions for creating interface clock-accurate models are from Cynergy and Axys Design Automation Inc. (Irvine, Calif.). Cynergy's ArchGen tool allows users to capture the control portion of their micro-architecture in an event-flow graph using an icon-based language set driven through a graphical user interface. The datapath for the design is specified in text form using standard C or HDL. Axys' MaxCore, creates C models from a C-like description of the micro-architecture.

This article is based on excerpts taken from ESC class # 532, SoC hardware-software co-development.