FONT SIZE : AAA
There are various forms of prototyping which we can employ in our projects. Available earliest in a project are virtual prototypes. They represent fully functional but loosely-timed software models of SoCs, boards, virtualized IOs and user interfaces, all running on a host-based simulation. Virtual prototypes can execute unmodified production software code on processor instruction set simulators and they run close to real-time. Being fully host-based virtual prototypes they can also offer good system visibility and control, which is especially useful for debug on multicore CPUs. Virtual prototypes can also have virtual user interfaces, allowing real-time interaction with us slow humans. The screenshot excerpts shown in Figure 4 are from a virtual prototype of an OMAP design running on the Synopsys Innovator tool. Here we see not only recognizable simulation windows but also the representation of key controls on the board and input from a virtual camera, in this case linked to a webcam on the host PC running the simulation, all done without hardware. We shall come back to Innovator in chapter 13 when we discuss the linking of an FPGA-based prototype with a virtual simulation.
While virtual prototypes offer very high speed (multiple tens of MIPS) when using loosely-timed models they do not offer the timing accuracy preferred by hardware design teams. More timing-accurate software models can be added to a virtual prototype but then their simulation speed will degrade to the single-digit MIPS range or even lower depending on the mix of cycle-accurate versus loosely-timed models.
However, virtual prototypes are available earliest in the flow, assuming models are available, so they are perfect for early software debugging. Virtual prototypes provide almost complete insight into the behavior of the system and they are also easy to replicate for multiple users.
Figure 4: Pre-Silicon virtual prototype of OMAP design
Finally, because they are created before the RTL, virtual prototypes allow codevelopment of hardware architecture along with early software. For example, extra or different CPUs might be added if the virtual prototype shows that there is not enough processing bandwidth for the product’s concurrent applications.
Related to virtual prototypes are so-called software development kits, or SDKs, of which a very common example is the SDK for developing applications for the Apple iPhone®. This SDK was downloaded more than 100,000 times in the first couple of days of its availability and so we can consider this a very widely available prototyping platform. Although simple in comparison, SDKs offer many of the advantages of full virtual prototypes, however, their accuracy is often more limited because they may not represent the actual registers as accurately as virtual prototypes.
Their aim is to have “just enough accuracy” in order to fool the application into thinking that it is running on the final platform. SDKs allow programming and interfacing over a higher-level application programming interface (API) into the platform. The developed software is usually compiled for the host machine on which the SDK executes and then requires re-compilation to the actual target processor after programmers have verified functionality on the SDK.
Figure 5: Android™ SDK screenshot showing GUI emulation
Available later in the design flow, but still well before real silicon, an FPGA-based prototype also serves as a vehicle for software development and validation. FPGAbased prototypes are fully functional hardware representations of SoCs, boards and IOs. Because they implement the same RTL code as the SoC and run at almost realtime speed with all external interfaces and stimulus connected, they are very accurate. They offer higher system visibility and control than the actual silicon will provide when available but do not match the debug and control capabilities of virtual platforms, or any other simulator, so they are not the first platforms we would choose on which to debug all of our RTL.
The key advantage of FPGA-based prototypes is their ability to run at high speed, yielding tens of MIPS per modeled CPU, while maintaining RTL accuracy. They are typically available later in the design flow than virtual prototypes because RTL needs to be available and relatively mature. Due to the complexity and effort of mapping the RTL to FPGA-based prototypes, it is not really feasible to use them before RTL verification has stabilized. For the same reason, FPGA-based prototypes are not intended for use as hardware/software co-development platforms because at this point in the SoC design flow, the hardware (i.e., the RTL) is pretty much fixed and partially verified. Design teams will be very hesitant to change the hardware architecture by the time the FPGA-based prototype is running, unless some major architectural bottlenecks have been discovered.
Finally, once stable and available, the cost of replication and delivery for FPGAbased prototypes is higher than for software-based virtual platforms, however still considerably cheaper than emulators, which we shall discuss next.
Emulation provides another hardware-based alternative to enable software development but differs from FPGA-based prototyping in that it aims at lower performance but with more automation. Emulators have more automated mapping of RTL into the hardware together with faster compile times, but the execution speed will be lower and typically drop to below the single-MIPS level. The cost of emulation is also often seen as a deterrent to replicating it easily for software development despite the fact that emulators are popular with software engineers because of their ease of use.
As with FPGA-based prototypes, emulators are not realistic platforms for hardwaresoftware co-development because they require the RTL to be available. A more likely use for emulators is as an accelerator for normal RTL simulation and so many consider emulation not as a prototyping platform but as an extension to the normal verification environment; a kind of go-faster simulator. An emulator can actually be used for software development, however, only when the software needs cycleaccuracy and high-visibility into the RTL and can tolerate very slow run speed. Software would need to be limited to short duration runs, such as the boot ROM code, because the slow running speed will mean that runtimes can be very long; certainly too long for long software tasks, such as user applications or OS bring-up.
Finally, after the actual silicon is available, early prototype boards using first silicon samples can enable software development on the actual silicon. Once the chip is in production, very low-cost development boards can be made available. At this point, the prototype will run at real-time speed and full accuracy. Software debug is typically achieved with specific hardware connectors using the JTAG interface and connections to standard software debuggers. While prototype boards using the actual silicon are probably the lowest-cost option, they are available very late in the design flow and allow almost no head start on software development. In addition, the control and debug insight into hardware prototypes is very limited unless specific on-chip instrumentation (OCI) capabilities are made available. In comparison to virtual prototypes, they are also more difficult to replicate – it is much easier to provide a virtual platform for download via the internet then to ship a board and deal with customs, bring-up and potential damages to the physical hardware.
As can be seen by this overview, prototyping is focused on providing early representations of hardware, specifically of chips and their surrounding peripherals. Prototypes are applicable for different use models, which in exchange have an impact on requirements.
Manufacturer:Xilinx
Product Categories: Programmable logic array
Lifecycle:Active Active
RoHS: No RoHS
Manufacturer:Xilinx
Product Categories: CPLDs
Lifecycle:Active Active
RoHS:
Manufacturer:Xilinx
Product Categories: Memory - Configuration Proms for FPGA's
Lifecycle:Obsolete -
RoHS: No RoHS
Manufacturer:Xilinx
Product Categories: Memory - Configuration Proms for FPGA's
Lifecycle:Obsolete -
RoHS: No RoHS
Manufacturer:Xilinx
Product Categories: CPLDs (Complex Programmable Logic Devices)
Lifecycle:Unconfirmed -
RoHS:
Support
