There once was a time when system design was completely serial. Entire hardware platforms were designed, prototyped, debugged, and virtually completed before any software development began. Of course, such methodologies corresponded to the days of much broader market windows. The very idea of such a quaint approach is enough to make one snicker.
Today, it’s quite different. Those market windows have narrowed to a sliver. Hardware development typically lags far behind software, but no one can afford to wait for hardware prototypes to begin shaking out the system’s drivers, operating system, and bus protocols. It’s become imperative for the software-development process to begin as early as possible so the software and hardware can be verified together.
But how is this to be done when silicon is essentially unavailable, or at best difficult to gain access to? Additionally, in this early stage of a system design cycle, the final specifications are a moving target. There’s the problem of setting up a testbench for the device. Often, the information on which you’ll base debug and performance analysis is incomplete. And on top of all of that, the hardware platform itself includes heterogeneous multicores with complex interconnect, memory hierarchy, and multiple dependent software stacks.
Fortunately for design teams, the means by which software can be effectively verified for a substantially non-existent hardware platform have come a long way. To be sure, one part of the solution has been an increased reliance on so-called platform systems-on-a-chip (SoCs), a genericized hardware architecture that draws from an established, known-good IP portfolio. Such methodologies can help stack the deck in favor of the design team when it comes to software development.
But for those intrepid souls looking to build on a customized hardware platform, hardware/software co-design generally entails assembling a highly abstract model of the hardware platform. There are a number of approaches to this methodology. Additionally, emulation technology has improved substantially in recent years, making it easier to run more clock cycles’ worth of simulation with slightly more detailed models. And, standardization activity of late has helped the industry get on the same page with its modeling.
HIGH-LEVEL DECISIONS
An increasingly popular way to attack the co-design problem is to start at as high a level of abstraction as possible. In this way, issues of hardware/software partitioning and which implementation vehicle is best for the algorithms you’re starting from can be handled concurrently.
The MathWorks’ concept of model-based design takes just this sort of approach, providing a means to automatically generate and verify production code for embedded processors. To that end, the company’s family of products comprises a systemlevel flow that begins with design, simulation, and validation of system models in Matlab and Simulink (Fig. 1).
With the Real-Time Workshop and Real-Time Workshop Embedded Coder, design teams can automatically generate production code for embedded processors. These tools provide the C-code generation foundation, and the targets provide target-specific code-generation extensions.
Meanwhile, the MathWorks’ Link products, such as Link for Code Composer Studio or Link for Tasking, enable engineers to test, debug, and verify the embedded software directly against the original executable specification. On the hardware side, using Link for ModelSim, engineers can verify the HDL code to be implemented on an FPGA or as an ASIC against the original executable specification.
MODEL MAKING
Hardware/software co-design has become one of the primary applications of electronic system-level tools and methodologies. Several EDA companies have developed fairly sophisticated flows for creating platform models for a given architecture.
Carbon Design Systems provides a catalog of tools for generating cycle-accurate models directly from the “golden” RTL representation of a design. This RTL can be written in Verilog, in VHDL, or in a mixed-language style. Socalled “Carbonized” models are optimized for high performance, running significantly faster in simulation than the RTL itself.
For model validation, Carbon’s flow allows users to verify individual hardware models by debugging them against the original HDL testbench. Models created with Carbon’s Model Studio can be easily integrated into existing reference test suites to verify the cycle accuracy of interfaces. All of the industry-standard simulators can be used, including Mentor’s Questa, Synopsys’ VCS, and Cadence’s NC-Sim.
When it’s time to assemble individual models into a platform, Carbon’s models lend themselves to integration with system-level integration environments such as CoWare’s Platform Architect and others. They’re also easily integrated with legacy RTL IP at cycle level. At this point in Carbon’s flow, users can replace early system models with accurate cycle models compiled from the actual RTL.
Continued on page 2
Reprints
