Virtual prototyping tools speed development for FPGAs with ARM-based SoC subsystems
Applications built using FPGA-based systems require significant software, and it’s important to start software development in parallel with hardware development. Virtual platforms allow pre-silicon software development using high-level models of system hardware and are becoming a critical part of the development tool chain.
The challenges of developing embedded software have grown as more and more of the hardware that the embedded software targets becomes integrated onto silicon. FPGAs are no exception, and they are growing in capacity and complexity. As they do so, the requirements for development are changing, with virtual platforms becoming an important part of the development tool chain.
A virtual prototype (or virtual platform) is an abstract software model of the hardware, and typically comprises instruction-accurate processor models combined with transaction-level models (TLMs) of all peripherals. The abstract models used in virtual prototypes change the “how” of software development by providing a prototype that is fast and responsive enough to run software and connect with physical I/O. Virtual prototypes change the “when” of software development by allowing software development before detailed hardware design is completed.
There are a variety of virtual prototyping tools and methodologies on the market focused on fast development of virtual platforms. In Figure 1, a timeline for an embedded system development project is shown, first with software developed after hardware design is completed and secondly with the use of virtual prototyping to start hardware and software development in parallel. Note the schedule reduction allowed by virtual prototyping, but speed is not its only beneficial aspect. A virtual prototype of the entire system offers a new software development environment where the developer has complete control and visibility into the entire system. Four tools in particular can add valuable depth to virtual prototyping: source code debug and register views, waveform views, memory viewers and maps, and transaction logs.
Case study: Virtual prototype development
In this discussion, the development of a virtual prototype for the Xilinx Zynq-7000 Extensible Processing Platform (EPP) is used as a practical example. The virtual prototyping examples are based on Cadence Virtual System Platform. Figure 2 shows a block diagram for the Zynq-7000 EPP.
A critical part of starting early on the development of the virtual prototype is the development of the models and the connection of the instruction-accurate processor models. The development of this virtual prototype required the integration of an ARM Cortex-A9 MPCore processor model and development of all the peripherals. An automatic model generation tool was used to create the register stub models for all the peripherals by extracting information for the reference specification, as shown in Figure 3. The peripheral models were all developed following the SystemC TLM-2.0 standard, and the processor model integration wraps the processor model in SystemC TLM-2.0. The register stubs, tests, and documentation are automatically generated.
A register stub model includes all the register interfaces of a peripheral, but not the functional behavior. The functional behavior is added by the model developer, extending the stub model to a fully functional model. Oftentimes, early software development can begin with stub models and expand as functionality is added.
Multicore source code debug
Source code debug is required for effective embedded software development, but the virtual prototype environment can extend conventional single stepping by using fast processor models that not only allow single stepping, but CPU register viewing and instruction and register trace recording as well.
For the Xilinx Zynq-7000 EPP platform, multicore debug is required to support the ARM dual-core Cortex-A9 processing subsystem previously highlighted. Because the processor models are integrated with a simulator, single stepping software on multiple cores is possible. As a result, the virtual prototype offers true multicore debugging, where developers can set source breakpoints on any software instruction running on any core. When the breakpoint triggers, they can see not only the state of the core executing the software, but also the state of the other cores in the system. Because virtual prototyping is a simulation, it is possible to stop the entire prototype when any core hits a software breakpoint compared with real hardware where a breakpoint on one core doesn’t have any way to stop other cores.
Many virtual prototyping solutions also extend the concept of register viewing to provide not only the CPU register view, but also register views of all the programmable devices in the system. Source code debug and register view tools highlight register changes when a software breakpoint is triggered and, if needed, the virtual prototype simulator can maintain a synchronized view of each of these registers at the time of a breakpoint on any core or register change. It can also allow the developer to overwrite any register value to verify a programming error and get further along in the code. The power to identify a problem, set a breakpoint, make a change, and continue can save significant time in integrating embedded software by not requiring a software change and recompile until the change is verified to produce the correct result.
Many embedded software developers hear the term “waveform” and immediately tune out because waveforms are intended for hardware developers viewing timing relationships between signals. But a waveform is actually one of the more powerful views that virtual prototyping provides for software developers. Most embedded software developers have had to debug system software issues that require them to add print messages to the software. These print messages are used for a variety of reasons, but one common one is to observe the sequence of software execution and report important state information. As it turns out, waveforms are a better way to visualize the sequence of execution and see how the hardware state changes.
A waveform view tool example is a UART debug session run on the virtual platform for the Xilinx Zynq-7000 EPP where all the registers of the UART are being traced, including the interrupt signal. This makes it easy for the developer to see if the UART driver properly sequences the register changes required to service the interrupt. Another feature of the waveform view is the facility to select a point in time and have the source code and register views return there in other windows, giving them proper context.
Memory viewer and system memory map
Many embedded developer hours have been spent trying to find what caused a change to a memory location that created a software failure. Often, the error occurs well before the failure manifests, so finding where and when the error occurs can be challenging. Virtual prototypes make these types of errors much simpler to find and fix, starting with the ability to watch any memory location for read, write, or read,and write activities to find out when the error occurred. A memory viewer and map offers a convenient way to find the area of interest. This, combined with the ability to view the memory in a variety of formats (including a disassembly view if needed), makes it easy to create a memory view best suited for the debug task.
Transaction smart log
Finally, the virtual prototype transaction log is an abstract view of each hardware transaction that occurs while the software executes. This is more of a hardware view, but still valuable for software debug. It is used to report errors or warnings when the software violates a hardware specification – for example, if the software attempts to write to a read-only register or access a memory location that is not defined.
A transaction log can be smart, allowing the developer to select the types of information to log and further filter the logged information for a particular word, address, or device. These capabilities make it simple to quickly eliminate errors that can be hard for software developers to find because they relate to assumptions or misinterpretations of the hardware operation, or errors like missing registers or hardware models in the prototype. Having the virtual prototype report disconnects between software and hardware saves time. Finding and correcting memory addressing errors is typically time consuming because the behavior resulting from the addressing error is dependent upon the information returned from the addressing error.
Speeding software development with virtual prototyping
The visibility and control that a virtual prototype offers embedded software developers greatly improves their ability to integrate software more quickly. Any system, whether built using FPGAs, SoCs, or both (which requires complex embedded software integration), can benefit from adding virtual prototyping to the development flow. The full control and visibility of a virtual prototype allows more powerful debugging. The four tools described illustrate why virtual prototypes change “how” embedded software is developed. The ability to develop an early model of the system for software development in parallel with detailed hardware development changes “when” embedded software is ready. These two benefits combine to deliver production software at the same time the hardware is delivered.
Cadence Design Systems