10 Must Knows About Virtual Prototypes

1. What is a virtual prototype?
If you ask a room full of people to define ‘system’, you will get as many answers as there are people in the room. The same is true for virtual prototypes. A virtual prototype defines a model of something that is usually created by one group and used by another with some implied abstraction. It is a prototype that exists as a software model on which analysis can be conducted.

One of the things that EDA does is “pass information around and attempt to make that streamlined,” says Aveek Sarkar, vice president of product engineering and customer support at Ansys-Apache, “We created the chip-power model that is a virtual prototype. It contains information that is created in one environment and can be used by a different set of people.” Within Ansys they also talk about mechanical virtual prototypes.

Atrenta is also busy creating virtual prototypes for power. This is very different from power intent that has received a lot of attention recently. The power model sits beside the functional model and the two work in tandem. “Consider a video encode or decode function where power consumption is very dependent on the prior state,” says Bernard Murphy, chief technology officer at Atrenta. “If not much has changed (because there is not a lot of movement), then there will be little computation. But if a lot has changed, then a lot of computation is required. It is data-dependent.”

We have to be careful about how we use such vague terms as ‘virtual prototype’ and be more specific about the information content or use models that it provides.

When we think about virtual prototypes that are above RTL, minds wander to the Electronic System Level (ESL) and top-down flows. The remainder of this article will concentrate on those models.

2. Function or architecture?
There are two primary purposes associated with ESL virtual prototypes, namely a functional prototype often used for software development and an architectural prototype that enables decisions to be made about the hardware and for its performance to be analyzed. But there is still considerable disagreement about the exact types of models that should be used within each of these prototypes.

A functional prototype “is primarily driven by speed but does not allow much insight into the hardware blocks,” explains Frank Schirrmeister, senior director of product marketing for the System Development Suite at Cadence. “The register interface will be accurate so that the software will be the same as that loaded onto the actual board.”

The architectural prototype exists to “examine bus latency and contention, memory delays, etc.,” continues Schirrmeister. He explains that they are composed of mixed accuracy transaction-level models ranging from RTL, for small portions of the design, all the way to statistical traffic generators or may even use traces captured from real environments.

However, SystemC and TLM have created two abstractions that add to the confusion. The abstractions are called Approximately Timed (AT) and Loosely Timed (LT). “The models are poorly named, but I think people have started to accept and understand them,” says Jon McDonald, technical marketing engineer in the design and creation business at Mentor Graphics. “LT corresponds to functional and AT corresponds to performance model.”

“We have been producing C++ models of our hardware since before SystemC existed,” explains Grant Pierce, president and CEO of Sonics. “When modeling on-chip networks, I would describe three use models:

• Functional models. Here, the network is basically just an address decoder.
• Performance analysis. In most SoC applications you can’t analyze performance without analyzing the memory at a cycle-accurate level. DRAM performance is dependent on address patterns and the relative timing of the transactions. Anything less than cycle accurate tends to have too big an error. The other components, such as processors and I/O, can be modeled at less than cycle accurate and will often use an extracted trace from previous simulations.
• A network provides more than just transport. It contains functionality, such as quality of service, firewalls etc. There are device drivers that are written to interact with the network. We do not see these used in the VP much today, but we foresee increasing usage.”

Before embarking on any virtual prototyping project it is important to define the purpose of the prototype and the abstractions of models that are appropriate for your intended use model.

3. Disconnected Flows
“I don’t believe that anyone is using a complete front-to-back ESL flow,” says Bill Neifert, chief technology officer at Carbon Design Systems.

Adds Tom Anderson, vice president of marketing at Breker Verification Systems: virtual prototypes exist in a vacuum. “The best hope for unifying the virtual prototype is with a model suitable for high-level synthesis (HLS). Today, although both models are often written in SystemC, they tend to be quite different. It’s a hard problem to unify them, and many argue that it cannot be done.”

Neifert agrees. “The people doing HLS are a ready-made source of models for VPs, and yet there are only a couple of people that I know of that are taking their HLS model and plugging them into a VP.”

McDonald explains that “the issues are on the HLS side. The restrictions on coding styles limit the interaction. The virtual prototype can take any model. If the virtual prototype has models for architectural analysis, it is much more difficult to use those models as input to HLS. The model had to be developed specifically for HLS or they will need to be rewritten.”

In order to create a flow, the models must be written with all use cases taken into account. Assuming that a model is appropriate for all functions will lead to problems.

4. Who creates the models?
The main threshold for widespread adoption of virtual prototypes is the availability of, or time to get, the models required. “In the big companies there are teams that do nothing but create system-level models,” explains Neifert. “This is a central group that works with many product groups. In smaller companies it tends to be a couple of people in the hardware group, but they don’t really have the software knowledge. When people from the software team do it, typically the firmware team, they don’t have the hardware knowledge.”

Several prototype vendors talked about their joint efforts with companies such as ARM who produce reference designs. Tom De Schutter, senior product marketing manager for Virtualizer Solutions at Synopsys, says that “for ARM-based designs, we provide reference VDKs based on ARM’s Versatile Express platform, ensuring that available software stacks like Linux and Android that run on the ARM reference board also run on the equivalent VDK.”

Joint initiatives help lower the model creation effort and lower the threshold to obtaining value from virtual prototyping, but companies must budget for model creation efforts for custom IP.

5. When do models get created?
Cadence’s Schirrmeister says, “in the past, virtual prototypes have been a side-thought, if not an after-thought.”

Even in today’s era of IP reuse, not all IP blocks come with the models that users require, so some of the TLM models have to be recreated from RTL or, at the sacrifice of speed, included as RTL.

“The industry is addressing these issues by connecting virtual prototypes with either RTL simulation, emulation or FPGA-based prototyping,” says Schirrmeister. “This is the only way to get to faster adoption rates of pure virtual prototypes. In the longer term, abstract models would have to become a non-optional part of the project flow and would have to serve as the golden reference that today resides in RTL.”

Not only do resources have to be assigned for model creation, they must be carefully placed in the project schedule to ensure the maximum return on the investment.

6. Are more standards required?
Synopsys’ De Schutter feels that “the TLM-2.0 standard has helped significantly in enabling easy connection of different transaction-level models. Additional standards to define power information or capture analysis data might further help to increase the value of the available models.”

Cadence’s Schirrmeister adds to the list of standards work that is required to allow other elements of the development process to become more interoperable. He lists new interfaces for interrupt modeling, enabling seamless integration of models from different companies, application programming interfaces for register introspection that enable tool interoperability to seamlessly display and update register values, debug and implementation, and new approaches for memory-map modeling.

Existing standards assist with model portability, but additional standards are required to perform many of the types of functions that are available at the RT level, plus additional ones would be beneficial at the system level.

7. Will ESL make RTL go away?
“If design entry were to move from RTL to a TLM representation, it would enable a golden reference for hardware implementation and enable software development,” says Schirrmeister. “When this transition is complete, verification can move to the TLM-level and ideally be combined with formal techniques to show that the derived implementation is correct.”

Not so fast says Atrenta’s Murphy. “RTL is not going away even if ESL is successful. When I am buying or acquiring 70% of my IP and I don’t care what is inside of it, what value does ESL bring to the table? The reality today is that it is over the wall between architects and implementation teams. If you stop talking to EDA guys and instead talk to systems companies, you will get a very different view.”

While ESL may enable high-level optimizations to be made and some blocks may utilize a high-level synthesis flow, RTL will remain the abstraction for implementation for a long time.

8. How does the virtual prototype get verified?
On this question there are few complete answers. “Many people are doing it using traffic generators,” says Carbon’s Neifert. “People will stitch together IP blocks and see the interactions. Often they will start with the fabric and then put in the memory controller. Then they may bring in a CPU.”

The most common solution appears to be handwritten test cases to run on the embedded processors. Others note that because a purpose of the virtual prototype may be to bring up the OS and other firmware, the target software is the thing to use.

“A common UVM-based testbench for virtual prototypes and RTL code would eliminate some duplicate effort,” asserts Breker’s Anderson. “Adopting scenario models would eliminate entire stages in the project, including hand-writing tests for the embedded processors in virtual prototypes and RTL simulation.”

“The architectural models can also be used in the hardware verification flow,” notes Mentor’s McDonald, “and the TLM models are plugged into their UVM testbenches.”

The verification flow associated with virtual prototypes is an emerging area. Some solutions are coming to market. In addition, with proper planning, the virtual prototype models can assist with downstream verification tasks.

9. Are models portable?
You would expect that models created using SystemC could be plugged into any framework. “You run into trouble where vendors have started to add in proprietary extensions,” says Neifert. “They do this to try and tie people into their system and some of these systems are SystemC in name only. Models will not run in an OSCI environment.”

This appears to be a common problem. “Model interoperability is one of our biggest challenges, complains McDonald. “The TLM standard has been good at defining the interfaces but there are models from other sources that do not conform to these standards.”

The consensus is that a case can be made for some of these extensions and the standardization process is continuing, but a solid compatibility standard makes models available and ubiquitous for all engineers. If the standard is a moving target, few people will adopt it and it makes it difficult to make all of the models work together. “Anything that you need to do can be done with the standard today, says McDonald. “You may be able to make things a little easier or a little more efficient, but these do not limit the adoption of the standard.”

When putting together a virtual prototype consider the benefits and implied costs associated with using proprietary models. Is portability more important to you, or the improvements that come from extensions?

10. Are virtual prototypes used in domains other than smart phones?
When you look at the list of companies using virtual prototypes today, it contains all of the companies producing smart phones. This is no anomaly explains Neifert. “It all has to do with ARM. As ARM gets adopted in more vertical markets, the methodologies that enabled ARM to be successful will follow. This includes the adoption of virtual prototypes.”

It is clear that other companies also will have to create similar methodologies if they want to compete in those markets. Mentor’s McDonald adds another encouraging example: “My kids are into robots and they were doing an online course. It was an introduction to embedded programming course and it used a virtual model as part of the lab work. They finished up running everything on the virtual model and the physical board.”

ARM dominates the smart phone market and wants their customers to be successful, so has invested in creating the models necessary to support virtual prototypes. It often takes a dominant company in a market to migrate design standards.