This post continues the series on prototyping started last week. For a full listing of the articles posted so for, please check out the index. In this post we will examine some of the factors you should consider when looking into the creation of a prototype. Frank Schirrmeister, group director, product marketing for System Development in the System & Software Realization Group at Cadence deserves a lot of the credit for this posting because he came up with the list on which this is based. It is also very reflective of the design article “Virtual Versus Physical Prototyping — Get it Right Faster” posted today which looks at the tradeoffs between virtual and physical prototyping.
Here is a list of some of the factors that should be considered before any type of prototype is considered.
- 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.
No prototyping project should ever be undertaken without considering this list of issues as a minimum. Please post a comment if you can add other considerations to this list. If there are enough of them I will do a second edition of this list with them properly incorporated.Brian Bailey
– keeping you covered
If you found this article to be of interest, visit EDA Designline
where you will find the latest and greatest design, technology, product, and news articles with regard to all aspects of Electronic Design Automation (EDA).
Also, you can obtain a highlights update delivered directly to your inbox by signing up for the EDA Designline weekly newsletter – just Click Here
to request this newsletter using the Manage Newsletters tab (if you aren't already a member you'll be asked to register, but it's free and painless so don't let that stop you [grin]).