 |
|
Mixed-Abstraction Virtual System Prototypes Close SOC Design GapsContributor: Carbon Design Systems, Inc. April 14, 2006 -- System-on-chip (SOC) designs are ow so complex that engineers can no longer architect a product at the familiar register transfer level (RTL). Electronic system level (ESL) tools and methodologies typically work at higher levels of design abstraction to help manage the complexity problem. Abstraction is necessary to architect an optimized hardware and software design to increase execution speed, minimize power consumption, and achieve the highest possible level of functionality. In addition, ESL tools can provide many orders of magnitude of increased simulation performance to enable design validation to keep up with design complexity. To meet both cost and schedule objectives, design teams are reusing previously designed modules, purchasing third-party intellectual property (IP), and implementing functions in software. The software content of SOCs has grown substantially such that many design teams now spend more time on software development than on hardware design. It is increasingly important to provide programmers with a system prototype as soon as possible to allow them to debug their code while much of the hardware development is still taking place. ESL-based SOC designWhen working at the system level, architects build a model of the entire system in software using specific hardware modeling languages such as SystemC. To increase the simulation performance of the system model, many details are initially left out because they are not relevant to the problem being solved at the time. Using ESL tools and virtual system prototypes lets a design team explore and validate the system architecture and avoid serious mistakes that generally would not be visible until well into the implementation phase. During this phase of the design, architects decide which functions they will implement in hardware and which in software. System architects also do profiling and performance analysis of the design. They test bus communication protocols to ensure that throughput and latency targets are met. Several EDA vendors are addressing the ESL market with tools that let engineer model the system at the transaction level. Transaction level models (TLM) typically involve abstraction of the data and control information that is exchanged over the internal system buses, as well as abstraction of the implementation details within the design blocks. A bus transaction could represent a burst read as one unit of operation, regardless of the number of bus cycles actually required to perform this transaction. Taking a slightly more detailed approach, the ARM RealView SoC Designer tool defines transactions on a cycle-by-cycle basis. Performance is gained by abstracting away the details of the control signals on the bus.
ARM also provides cycle accurate models of its 32-bit cores. The company make two different versions of its SystemC, cycle-based models available. Cycle accurate (CA) models accurately model the internal pipelines in the processor core and maintain bus cycle fidelity. SOC architects seeking accurate profiling and benchmarking data can employ cycle accurate models as a fast and highly accurate representation of their ARM processor IP. Cycle approximate (CX) models do not model the internal pipeline behavior and idle cycles on the bus may be eliminated for better simulation performance. System architects can use these high-speed SystemC models to create virtual prototypes for hardware and software development. Software engineers benefit from the RealView Developer Suite (RDVS) tools to compile and debug software on a virtual prototype of the processor core. Although the ESL approach provides a robust environment for design exploration and definition, there are some gaps in the overall SoC hardware and software design flow (Figure 1).
One of the best and most common ways to shorten development times is through reuse of proven design modules. Engineers reuse functional blocks from previous designs (legacy RTL) or acquire IP from third-party vendors. One of the barriers to ESL adoption has been the lack of behavioral/TL models for these existing RTL blocks. System architects must use existing models that were written in a traditional HDL, like Verilog or VHDL, or take the time to manually create behavioral C/SystemC models for all of the legacy blocks. Although HDL event-based simulators can handle RTL models together with TL models, simulation execution speed is much too slow to allow architectural exploration or firmware development and validation. The first gap occurs early in the design cycle, when system architects and firmware developers need a way to quickly incorporate all the existing RTL design blocks in a high performance system model. Recent studies indicate that the cost of verifying that a design works as specified can be as much as 70% of the cost of the development of a new product. The most time-consuming part of SoC development is the integration and validation of the software blocks with the hardware subsystem. The traditional approach is to wait to have a functional prototype of the hardware before starting software validation. This approach results in the project taking too much time for the present market conditions. Some electronic systems developers use hardware emulation, FPGA prototypes, or abstract simulation models of the system to allow software engineers to start verifying the code before the hardware is available. All of these approaches have limitations. Hardware emulators are expensive and require designers to develop hardware models that are specific to the emulator, thus increasing the amount of work required from hardware engineers. Both FPGA prototypes and emulators require that all of the RTL be available, and therefore, these approaches come too late in the design cycle (the first gap in Figure 1). A number of other ESL vendors offer services to provide idealized abstract models of processor cores and peripheral components. Developing such models is time-consuming and expensive. Working from a data sheet specification, third-party vendors can build a model that simulates the behavior of the processor as seen from the outside, but cannot reproduce the internal architecture. The lack of proper modeling of the internal architecture results in a lack of accuracy that impacts the validity of simulating real time software using the model. In general, these abstract system models are not cycle-accurate, trading off accuracy for simulation performance. As a result, software engineers cannot use these models to fully verify embedded firmware, since time is either absent or only approximated to the instruction cycle interval in these models. To validate hardware-dependent firmware, engineers must use a cycle-accurate model of the processor and all the peripheral components. After chip tape-out, companies often find that field support of an SOC product is expensive because they do not have a user friendly, deployable model of the product that they can use to explore the integration of the design into a new product or to allow for evaluation of the product by a prospective customer (the third gap in Figure 1). A fully functional, cycle accurate C/SystemC based model of the entire system would obviate these problems. SOC design teams must have the greatest possible freedom to use pre-existing modules and to implement functional blocks using their preferred HDL. At the same time, it is important to provide the fastest simulation throughput possible and the ability to integrate hardware and software as early as possible in the development schedule. Carbon Design Systems solves all of the design flow gap problems by providing a rapid path to incorporation of RTL designs in a fast SystemC based simulation environment. SOC-VSP is tightly integrated with ARM RealView SoC Designer to enable design teams to build a hardware accurate model of the complete system. This virtual system prototype supports architectural exploration and the verification of both the hardware and the software portions of the SoC. Figure 2 shows a high-level view of a virtual system prototype that includes RTL models, ARM processor models, peripheral models, and SystemC TLMs.
System architects can use Carbon's SOC-VSP product to leverage all existing RTL design blocks for use in the system model to enable earlier architectural exploration and profiling. SOC-VSP lets the architect compile synthesizable Verilog, VHDL or mixed language RTL models into a highly optimized C executable object called a Virtual Hardware Model (VHM). The VHM is a cycle- and register-accurate representation of the RTL model with extremely fast simulation performance. A VHM has the bus-cycle accuracy needed to do precise performance modeling of the entire system. When a RTL model is compiled using SOC-VSP, the resulting VHM is called a "Carbonized" model. The SOC-VSP Component Wizard is used to create a RealView component wrapper for the VHM. Throughout the firmware development and new RTL implementation process, SOC-VSP can be used to "dial-in" the hardware accuracy needed for firmware validation. As soon as new RTL is available, a Carbon VHM can be swapped into the system model in place of an abstract behavioral model. There are none of the delays associated with FPGA prototypes and commercial emulators. The hardware-accurate Carbon models enable hardware-dependent firmware and driver code to be validated before hardware prototypes can be available. The SOC-VSP and RealView SoC Designer virtual system prototype is a software solution that has fast bring-up; hardware and software debug visibility; and can be deployed to the whole SoC design team. In addition, after tape-out the virtual prototype can be deployed to internal and external customers to enable them to get an early start on SoC integration and application development. SOC-VSP Integration with ARM RealView SoC DesignerStandard buses provide the communication mechanism among the various functional blocks in a design. Engineers need models that duplicate the bus protocol and timing at the cycle-accurate transaction level in order to have an accurate picture of the internal communication system. Without it, they cannot measure the efficiency of partitioning logic functions among various blocks. Transactors translate a high-level abstracted view of bus protocol operations-reads, writes, burst transfers, idle, busy, reset, interrupts-into the proper sequence of signal transitions for each operation, over a defined number of clock cycles. Transactors allow Carbonized RTL models (VHMs) to easily interface to the system bus at the transaction level. Carbon SOC-VSP includes transactors for the AMBA bus protocols- AHB, APB, and AXI. Carbon also provides an extensive library of additional bus protocol models (PCI, PCI-X, USB2.0, Ethernet, etc.) that enable end-to-end flow-through testing of the SOC. For example, transaction-level traffic can be injected on a PCI port and operated upon by the SOC such that it generates output traffic on an Ethernet port. The SOC-VSP Component Wizard is invoked from the RealView SoC Designer GUI to lead the user through the RealView component creation process. The wizard accesses the SOC-VSP compile database file for the Carbon VHM and automatically populates the component definition with all of the top-level ports, as well as internal signal, register and memory information. The user specifies clocks, resets and the specific bus protocol used for any transaction level interfaces (e.g. AHB or AXI). The appropriate bus protocol transactor is connected to the VHM, raising the level of abstraction from RTL pin-level to transaction level. The wizard generates the required RealView API (MxSI/CASI, MxDI/CADI, MxPI/CAPI) interface file for the component. The result is a transaction level Carbon component that is added to a RealView library. From there it can be dragged and dropped into a system model, just like any other RealView library model. Figure 3 shows a Carbon component in a RealView SoC Designer system model with an AHB bus interface.
Figure 3. RealView SoC Designer with Carbonized Component RealView SoC Designer provides extensive firmware debug facilities, including single-stepping, software breakpoints, memory and register access, etc. The integration of SOC-VSP with RealView SoC Designer lets engineers use these same powerful debug functions with Carbonized RTL models. Carbon fully supports the MxDI and CADI interface APIs provided by RealView SoC Designer that allow engineers to perform the following operations on Carbon VHMs during simulation:
RealView SOC Designer and SOC-VSP also lets engineers save and restore the complete system state at any point during system simulation. Such a facility can save hours or days of simulation time because a designer can stop a simulation, save the logic state of the design, troubleshoot a particular bug, fix the problem and restart the simulation without having to start from time zero. Such a function is very valuable when debugging a real time operating system since it often saves the time required to simulate booting the system every time the engineer has to fix an application bug. State information for the Carbon VHM is saved to the same stream file used by SoC Designer, so there are no file management issues. SOC-VSP and RealView SoC Designer have the simulation performance to execute on the order of 10 billion clock cycles in one day's time. This is the speed needed to execute and validate low-level firmware and software drivers, as well as operating system (OS) boot code. Carbon VHM performance derives from several sources. First, the Carbon RTL compiler includes hundreds of local and global performance optimizations that are used to create the VHM. Second, the VHM is a cycle-based simulation model that runs many times faster than event-based RTL simulation models. Third, the Carbon VHM is integrated with a bus protocol transactor that provides a transaction level interface to the system bus. System execution at the transaction level provides additional performance benefits by raising the level of abstraction of system-level communication. Fourth, the VHM is callable on-demand, so that it only executes internal operations when necessary. In a high speed system simulation, this capability allows optimal overall system performance. And fifth, there are no co-simulation bottlenecks; Carbon VHMs execute as slave models in the RealView system simulation environment. | |||||||||||||||||||||||||||||||||||||
Reprinted from SOCcentral.com, your first stop for ASIC, FPGA, EDA, and IP news and design information. | |||||||||||||||||||||||||||||||||||||
