蘑菇视频APP

By Clive Maxfield EEdesign.com January 05, 2004 (8:56 PM EST)

Even with the increasing push towards capturing designs at higher levels of abstraction such as C/C++, the majority of design engineers still prefer to work in their "RTL comfort zone." The problem is that when you are simulating an entire System-on-Chip (SoC) with an embedded processor core, memory, peripherals, and other logic, you are lucky to achieve simulation speeds of more than a couple of Hz (that is, a few cycles of the main system clock for each second in real time).

So my ears pricked up with the December 2003 announcement by new-kid-on-the-block Carbon Design Systems that they have a solution that allows you to run your RTL model at kilohertz (KHz) speeds. Carbon's boast is that they can take your RTL and generate a linkable or executable object that:

* Compiles like a simulator * Runs like an emulator * Deploys like software * Plays like Golden RTL Wow! If it only made our teeth a little whiter we'd have it all!

A typical pre-Carbon design flow

Before we plunge headfirst into Carbon's technology, let's first refresh ourselves as to a typical pre-Carbon SoC design flow. (In reality, of course, there's no such thing as a "typical flow", but we'll consider a somewhat generic example and work our way up from there.)

Let's assume that you create the first pass of your design at a high level of abstraction using SystemC. This representation will probably be in the form of a SystemC "framework" that gathers together a collection of blocks, the contents of which are also specified using SystemC. When verifying the design at this level of abstraction, you might achieve simulation speeds of around 800 KHz.

As the design progresses, you will keep the SystemC framework, but you will start to decompose the blocks into functions and refine these functions into their RTL counterparts. These RTL blocks are the representations that will eventually be synthesized down to form the final implementation in silicon, so you would really like to verify the software portions of the design against these representations. The problem is that once you start to use RTL versions of the hardware, simulation speeds drop to a painful crawl of only a few Hz.

One option is to use hardware-based simulation acceleration and/or emulation to speed things up, but this impacts deployment of the design throughout your company and also to end-users, not the least that only a few people can use an emulator at any one time. What you would really like is a software-based solution that allows you to use your Golden RTL, but to speed up the simulation runs by thousands of times. By removing the need for special emulation hardware, this software-based solution would potentially allow 100s or 1000s of users to be verifying critical foundation software 脩 such as drivers, diagnostics, and firmware 脩 with simulation runs at KHz execution speeds, thereby enabling internal system verification and end-user (customer) validation and development to occur much earlier than traditional methods.

SpeedCompiler and DesignPlayer

And so we turn our attention to the folks at Carbon, who have come up with a rather cunning solution. Carbon's two offerings are called SpeedCompiler and DesignPlayer, both of which run on Linux, Sun Solaris, and Windows 2000/XP. SpeedCompiler takes your Golden RTL and, in just a few minutes, compiles it down into a cycle-accurate and register-accurate DesignPlayer module (Figure 1).

While executing thousands of times faster than the original RTL, DesignPlayer's simulation results match the real hardware "bug-for-bug." DesignPlayer modules are binary compiled objects, thereby protecting your intellectual property (IP) when you distribute them. Having said this, SPEEDPlayer allows you to define which registers and signals you wish to remain visible for debug proposes.

DesignPlayer modules may be generated as standalone executable objects, or as linkable objects that can be called from within any standard simulation and verification environment or into any C/C++ environment like SystemC. For example, instead of replacing a SystemC block with an RTL block in the generic environment discussed earlier, you can now replace it with an equivalent DesignPlayer module. Furthermore, on the basis that DesignPlayer modules are just software objects that can be linked together, this means that DesignPlayers can themselves contain (call) other DesignPlayers ad infinitum.

Rapid and wide deployment

The three key points Carbon likes to emphasize with regards to their approach are:

* It's a software-only solution than can be deployed to hundreds or thousands of users (predominantly embedded software developers and verification engineers). * Due to the fact that this cycle-accurate and register-accurate solution is based on Golden RTL models, it's functionally accurate with regards to the final silicon. * It's fast enough that you can run your software on your hardware representation for milliseconds of real run time. The folks at Carbon say that there are a large number of solutions that can boast one or two of these features, but that their offering is unique in that it's the only solution that can provide all three.

There are all sorts of cases where Carbon's approach is attractive, not the least that it's extremely linear and scalable to designs containing hundreds of millions of gates. As a design gets bigger Carbon's solution becomes more and more attractive. According to the guys and gals at Carbon, one example from a real customer who designs a chip fabric containing hundreds of processor nodes showed a simulation run-time reduction from 8 days using RTL representations to only 8 minutes using DesignPlayer modules!

Or consider a company developing a state-of-the-art graphics chipset. This company's customers need early access to the design so as to develop their software drivers. The great thing about a DesignPlayer module is that, as soon as a new revision becomes available, it can be immediately emailed to developers around the world.

And in the case of IP providers who (a) don't want their RTL running wild and free and (b) would like to provide their customers with a faster verification solution, they can "Carbonize" their IP into a form that users can easily incorporate in their ASIC or SoC environments.

The question on everyone's lips...

Of course is, "How much does it cost?" Well, as I pen these words, a one-year subscription to SpeedCompiler will run you $150,000 per seat. By comparison, each DesignPlayer run-time license goes for $10,000, which may sound like a lot, but Carbon says that it's comparable to an FPGA breadboard. (Note that the $10,000 DesignPlayer run-time license relates to internal development usage by the company generating the IP. The price drops dramatically when you deploy DesignPlayer objects to your customers.)

And a key point that offsets this expense is that having access to this type of solution can collapse a design's overall software development and system verification schedule by several months, which directly equates to "time-to-revenue."

Carbon appears to have covered all of the bases when it comes to such things as verifying embedded drivers, or debugging drivers via socket interface through network to a different computer, or talking to external drivers through an interface like a PCI bus transactor. In short, the Carbon solution supports all of the usual scenario suspects, from driver software running on the host to an instruction set simulator (ISS) used for full source level debug.

Of course there's much more to the story than I've covered here, so if you are interested in finding out more, please feel free to visit Carbon's website and/or email them (tell them you heard about them here ). Until next time, have a good one!

Clive (Max) Maxfield is president of Techbites Interactive, a marketing consultancy firm specializing in high-tech. Author of Bebop to the Boolean Boogie (An Unconventional Guide to Electronics) and co-author of EDA: Where Electronics Begins, Max was once referred to as a "semiconductor design expert" by someone famous who wasn't prompted, coerced, or remunerated in any way.