Virtual prototypes for early software development and high-level synthesis tools for hardware implementation are two important new technologies that are raising the abstraction level in electronic systems design. But these tools are traditionally isolated from one another because they require different types of models.
In this interview Mike "Mac" McNamara, vice president of System Level Design at Cadence, explains the modeling requirements for both types of tools, talks about what's needed to adapt virtual prototype models for implementation, and notes how Cadence has demonstrated a connection between virtual prototyping and high-level synthesis as part of TSMC Reference Flow 12.
Q: Mac, what are you seeing today in terms of adoption for high-level synthesis and virtual prototypes?
A: Production usage of high-level synthesis is really picking up now. It started in Japan and Europe, and it's picking up in the U.S., where some major corporations are adopting high-level synthesis as they are recognizing the need to raise the abstraction level of design capture. They require the enhanced speed of verification they get at that level to obtain the kind of increased productivity and reuse they need in the marketplace.
Virtual prototyping is another kind of tool that is becoming more and more essential as embedded software content increases and devices use multi-core architectures. A virtual prototype lets you model hardware to the extent that's needed for the programmer's view. These prototypes are running in the GHz range and you can boot Android in just about real-time speeds and detect many kinds of problems. If a given system has 100 bugs, you can quickly find 80 of them in a virtual platform, and then the remaining 20 become much easier to find with a Palladium [emulator] or on an FPGA-based prototype.
Q: What is the connection between virtual prototypes and high-level synthesis? Can you take the transaction-level models you use in a virtual prototype, and synthesize them?
A: All that's required to boot the software on a virtual prototype is a representation of the design that's sufficient to convince the program that it is really talking to hardware. Such models do not require any more than that; and to make them run quickly, it is important to leave out implementation details that slow down execution and don't affect the software's execution.
For high-level synthesis, however, you have to fill in the rest of the details. A very effective way to combine the efforts is to first build a virtual model of the device and give this to the software team to enable them to bring up the software, fix the bugs they find, and identify any system bottlenecks. Then for the parts of the device where you need to build new RTL, you refine the virtual platform model of that part, adding specification of the behaviors that are not really visible to the program, but are essential for proper hardware functionality.
You can plug that refined model back into the virtual prototype, boot Android again, run apps, and so on, and validate that everything continues to work correctly -- which is fabulous! And then with that confidence, you synthesize the refined model into RTL, which again you can plug back into the virtual platform.
Q: What are some of the hardware details that need to be added for high-level synthesis?
A: One thing that's needed for the hardware model, but perhaps not for the embedded software focused model, is a way of handling error conditions. A model created for software development may not bother with modeling error checking things like parity. Some virtual models may completely omit the specification of internal behavior, so you have to supply the guts of the behavior for high-level synthesis. Where you do have a representation of the behavior, you may need to represent it in such a way that it can be synthesized, and this is where you have to make sure you're writing within a synthesizable subset of the language.
Two things that a high-level synthesis model needs are specification of the computation - what the device is supposed to do - and specification of the communication, which is how you speak to the device. If you have a virtual model, you may abstract away the details of the on chip communication into a pure TLM 2.0 generic payload. When you synthesize this, however, you need the actual specification of the bus that will be used at RTL. Cadence has a technology called Flex Channels that helps with this - it lets you represent a TLM channel either as a generic payload or as a specific protocol such as AXI or AMBA.
Once the model is set up for high-level synthesis, there may be some refinement steps you need to do to achieve the quality of results (QoR) you need. Often there are constraints you can use with your high-level synthesis tool to guide it to implement the design in different ways to get the parallelism and throughput, or the lower power implementation your application needs. You sometimes need to, and want to, do some refinements to the C code itself to make it more easily usable by the high-level synthesis tool.
Q: With the introduction of the System Design Suite, Cadence now provides the Virtual System Platform. If someone wanted to bring a model from that environment into the Cadence C-to-Silicon Compiler, how could that be accomplished?
A: We actually demo this within the Cadence part of the TSMC Reference Flow 12 (announced at DAC 2011), where we provided a virtual prototype running Android on an ARM Cortex-A9 processor with an AXI bus and a number of peripheral interfaces. One of the peripherals is an H.264 codec, which is used to compress and decompress videos on BlueRay Discs, YouTube videos and Adobe Flash Players, as well as in commercial digital broadcast systems.
We first used a physical bridge that mapped the functionality of the codec into services provided by the underlying hardware and software of the host platform upon which our virtual platform is running, and demonstrated booting Android and running video streams. We then replaced the physical bridge with a purely computational model of the H.264 codec modeling the device, and repeated the demonstration. We then substituted that computational model with an actual representation of H.264 in a synthesizable SystemC model, and we again booted Android on that, although more slowly.
Then we synthesized that model to RTL and ran it back into the Virtual System Platform. We used the connected feature of the System Design Suite to run the RTL model of the video codec in a Palladium emulator with the rest of the system in the Virtual System Platform, and again booted up Android and ran the video streams through the system. This got us back to decent speeds.
Q: What kind of refinement was done to the virtual model?
A: We selected AXI transactor in the Flex Channel rather than the generic payload interface to get an actual connection to the bus. We ran our C-to-Silicon high level synthesis tool to generate the RTL. Then we used a transactor to take that RTL interface back up to the transaction level, so this RTL implementation could plug in and speak to the rest of the system.
Q: What kinds of capabilities do you foresee for the future for connecting virtual prototypes and high-level synthesis?
A: I think the concept of a Flex Channel is going to help a lot to close the gap. You'll have a communication port that can go either way - fast for a virtual prototype, or slower with the details needed for high-level synthesis -- but in both cases representing the communication needed for the application.
I serve on the SystemC synthesizable committee of OSCI [Open SystemC Initiative], and we're adding more and more capabilities there as tools get more capable. I think we as an industry will coalesce around a modeling style that will work really well for virtual prototypes and also for high-level synthesis. Such a standard will enable customers to write models in a way that will work across tools.
At Cadence we are pretty excited about the connection between virtual platform and high level synthesis, and perhaps this is why Cadence has asked me to manage both product groups. As an industry, raising abstraction to the system level is one of the things we're doing to extend Moore's Law out for another decade. In order to get the next set of 2X improvements in capacity, we must connect the embedded software programmer to the hardware teams, and we must move verification to the system level by building a robust and trustworthy implementation path from SystemC to GDSII.