All too often, the success of a design project hinges on hitting a market window. And a key to hitting a market window is the delicate dance that goes on between the software and hardware design teams. How does the software team validate its work without a hardware prototype? When that hardware is an ASIC or SoC, it could take months for the team to come up with a prototype.
There are, of course, a number of approaches to pre-silicon software validation in the market. There's simulation, whether it's plain-vanilla or hardware-assisted, but simulation is quite slow. You're doing very well if you can get your hardware models to execute at even 100 Hz. There's higher-level modeling in SystemC or C/C++, with custom software models or with instruction-set simulation. Although these methods certainly run faster than simulation of RTL code, they're plagued by the lack of cycle and/or register accuracy because you're working at a pre-RT level.
Then there's emulation and FPGA-based breadboarding. These methods can speed things up. However, if you're looking to help developers write drivers or firmware for a new graphics chip or network processor, how will you get each of them the megabuck emulation systems they'll need?
A software-only answer is needed for the dilemma of pre-silicon software validation. It must run RTL, not a higher-level language (although being able to work at a higher level is not undesirable). It should run on general-purpose computers and in any environment—Solaris, Linux, or Windows. The latter, as it's favored by software developers, is especially important. Plus, it must account for the needs of software developers, who want hardware models that will run bug-for-bug with the real thing, but do so very quickly.
That answer has arrived in the form of Carbon Design Systems' first two products (Fig. 1). One, known as SpeedCompiler, accepts Verilog input and transforms that RTL code (or gate-level representation) into a "Carbonized" model, or linkable object. These objects, in and of themselves, can provide value as secure versions of "golden" RTL and, as such, could serve as a general distribution method for IP.
But their real value is revealed when they're combined with Carbon's second product. The SpeedCompiler's output is the fuel for the DesignPlayer engine. This allows a software development team to combine IP cores, homegrown design blocks, and transactor models representing buses or communication standards into a powerful platform that runs at multiples of up to 200× compared to traditional simulation approaches. This means kilohertz-level performance, not 100 Hz. With DesignPlayer running the Carbonized hardware models, software teams can do development work with an RTL-level model of the target hardware.
Carbonized models are cycle- and register-accurate, eliminating some of the issues related to higher-level modeling. Most importantly, they can easily find their way into the hands of any and all software developers anxiously awaiting a representation of the target hardware for their work. Thanks to Carbon's licensing model, such models can be freely distributed by their licensee to developers.
EVENT BAGGAGE BANISHED The models themselves have no simulation kernel and thus eliminate the baggage associated with event-driven simulation. They also have none of the design-style limitations associated with cycle-based simulation. The timing issues that retard event simulators have also been banished: There's no event queue and no timing wheel. They're also scalable in that execution time maintains a near-linear relationship with size. The run-time image of these models has an extremely small memory footprint, allowing them to remain in cache, which partially accounts for the speed at which they execute.The models come together in the DesignPlayer engine. It unifies software and hardware development by tying in an engine to run the hardware model as well as a link to the user's software development environment. DesignPlayer includes a very high-speed API to allow software to communicate with the hardware model. Drivers for the hardware can be developed in any standard language, including C/C++, assembly, or Java.
Drivers can communicate to the hardware model in DesignPlayer through the API or a socket (Fig. 2a and Fig. 2b). In the latter case, the driver executes as a separate program. Decoupling with sockets enables the driver to run on a different processor than DesignPlayer in a multiple processor configuration, or even on a different networked computer. The user's software debugger works without modification and handles breakpoints, single stepping, reading registers, and all other operations common to software debug.
Carbonized models represent one form of linkable object that can be tied into the environment. Bus transactors are another form. Carbon offers an expanding roster of ready-to-go DesignPlayers for transactors. That roster presently includes Gigabit Ethernet, PCI, PCI-X, PCI Express, SPI-3/4, AGP, DDR, QDR, and USB 2.0.
These transactors create a common communication link between the software and hardware worlds. As a result, the software development environment remains completely independent of the hardware development environment. Software developers continue to use their favorite languages, compilers, and debuggers. But the difference is that DesignPlayer allows them to run their drivers, firmware, and diagnostic software on a model of the target hardware that matches its response perfectly.
A critical aspect of DesignPlayer that is very important to software developers is the fact that it is clock-driven, acting as a slave to, and not a master of, time. "Real hardware does nothing interesting until it's stimulated by software," says Josh Marantz, Carbon's vice president of engineering. "Whereas a simulator takes the other view in which the hardware controls time. In this respect, DesignPlayer behaves exactly like the real hardware it is modeling."
Another critical feature of DesignPlayer is its Configuration Manager, which affords the ability to automatically and dynamically configure the hardware model at run time. A software team may be attempting to anticipate many different hardware configurations.
For example, the team may be checking its software's viability on one version of a switch fabric with 20 nodes and another with 30 nodes. The Configuration Manager handles this hardware configuration seamlessly. It eliminates the need for a plethora of different hardware configurations that would otherwise be required, not to mention the time wasted in hardware recompilation. Configuration Manager allows the hardware team to compile once and then build alternate simulation environments very quickly.
The overall performance gains of Carbon's technology have been borne out by the experiences of early customers. One, a designer of a CPU chip set with 1.5 million gates, was achieving execution speeds in simulation of 112 Hz. With the chip set modeled in DesignPlayer, the resulting execution speed was 2.297 kHz. Another customer's 3-million-gate CPU system ASIC simulated at 93 Hz. The Carbonized version ran in DesignPlayer at 1.091 kHz.
SpeedCompiler is priced at $100,000 while DesignPlayer ranges from $5000 to $15,000 depending on volume. Transactors range from $1000 to $3000 depending on volume. All prices are per-year prices for annual subscriptions. Products are available now.
CARBON DESIGN SYSTEMS INC.www.softwaredrivendesign.com (781) 890-1500