Considering a prototype? Consider these questions first

11/29/2011 11:35 AM EST

• Time of availability – How quickly can the prototype be made available after the start of the project? Clearly this is related to the expected capabilities of the prototype, but in general virtual prototypes will be available first. Model availability may be an issue, in which case hybrid prototypes can be created or model conversation capabilities such as those supplied by Carbon used to avoid remodeling efforts.
• Speed – how fast is it? This is always a concern. In the paper published last week “System Performance Analysis and Software Optimization Using a TLM Virtual Platform” it showed that a virtual prototype modeled at the approximately timed level was 300 times slower that real time whereas a loosely timed model executed faster than real time.
• Accuracy – how detailed is the hardware represented? This is the corollary of the previous bullet. Changing the timing resolution resulted in greater than 300X performance difference. What accuracy do you actually need in order to performed the necessary function?
• Capacity – how big can the executed design be? This is a significant issue for the hardware based prototypes and you have to ensure that sufficient capacity has been purchased. Also allow for additional capacity for debug logic if required.
• Prototyping Development Cost – How much effort needs to be spent to build it in addition to the time spent in the traditional development flow? Virtual prototypes may still be expensive because they are not yet part of the standard flow. Emulation is pretty well understood. FPGA based prototyping from scratch is still a much bigger effort.
• Bring-up Time: While virtual prototype models may need to be debugged and the system bugs worked out, there are also developme4nt costs associated with a physical prototype. Board debug, assembly and other things have to be considered.
• Replication Cost: How much does it cost to replicate the prototype. For virtual prototypes this is almost zero but for FPGA based prototypes and emulators the costs may be a significant addition to the initial outlays.  Software Debug: How easy is it for software to be debugged? Almost all types of prototype are set up to make this fairly easy, but what about the ability to replicate or collect the necessary data to analyze the problem?
• Hardware Debug: How easy is it for hardware be debugged. The various types of prototype can be very different here. Emulators attempt to be as close to the simulation experience as possible whereas for some prototypes, speed may be more important than debug capabilities. This is another tradeoff point in hardware based prototypes. Post silicon prototypes are unlikely to have much capability in this area.
• Execution Control: How flexible can a user start and stop the design, or perform other control functions of the design. Repeatability may also be an issue which is something we expect in a simulation environment but may not be the case with systems connected to live targets.
• System connections: How can the environment be included? Speed conversion and availability of connections play a role here. For some interfaces, virtual connections can be created into the virtual prototyping world.
• Power and thermal analysis: Can I run power analysis and thermal analysis on the prototype? How accurate is it? Are there other specific considerations that you want the prototype to be able to model?
• Environment complexity: How complex are the connections between the different engines, assuming that a hybrid solution is being considered? The more hardware and software engines that are connected, the greater the complexity challenges. This may also be a consideration when connecting into the real world, often requiring speed buffers.