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."
Reprints
