By Bill Murray
Leading system and semiconductor designers have used virtual platforms (VP) for some years to develop, analyze, optimize and validate system-level hardware architecture. The resulting “golden” model – the virtual system prototype (VSP) – is then used as the executable specification for downstream hardware implementation. But are virtual platforms fulfilling the long-standing promise of electronic system level (ESL) design – true hardware/software co-development? In this first part of a two-part article, we ask experts at AMCC, Freescale, General Dynamics, Infineon, Sarnoff, STMicroelectronics and Wind River how they use virtual platforms, and compare their experience with the original expectations of a decade ago.
Firstly, what is a virtual platform? According to the book ESL Design and Verification: A Prescription for Electronic System Level Design Methodology, it is a system level model that characterizes real system behavior. It operates at the level of processor instructions, function calls, memory accesses and data packet transfers, as opposed to the bit-accurate, nanosecond-accurate logic transitions of a register transfer level (RTL) model.
And what were those expectations of a decade ago? They were that you could co-develop hardware and software in a virtual environment, and then do nearly everything with the resulting virtual system prototype (also called an “executable specification”) that you could do with the system itself – except drop it on your foot. In fact, the virtual platform should be able to do more. With its greater controllability and observability, it should be considerably easier to test and debug than real hardware.
Virtual system prototyping has three principal use cases:
- System architecture development, analysis, optimization and validation.
- Software development, validation and debug using co-developed hardware models.
- Hardware development, verification and debug using co-developed software.
The expected results of these use cases included:
- A system architecture that meets performance and cost goals with optimized HW/SW partitioning and optimized hardware architecture before progressing to hardware implementation. Optimized hardware architecture would also act as a “golden” reference for RTL implementation.
- Hardware/software (HW/SW) co-development that produces application and system software before a real hardware prototype becomes available.
- Faster hardware implementation, verification and debug, and faster HW/SW co-verification and debug, than at RTL.
- Easier component and silicon intellectual property (IP) reuse.
- Faster HW/SW integration and debug, with links to real hardware such as system, peripheral, and debug hardware.
The ultimate expected benefit was that the virtual platform would enable the design of very complex products – far more complex than single-processor systems and chips – with reduced time to market and reduced design cost. So what is the reality?
General Dynamics (GD) uses virtual platform technology to integrate and test software developed on existing hardware, but may use it in the future for system hardware development. The company started by applying the technology towards the back end of its system design flow. According to Kent Carver, avionics systems engineer with GD’s Advanced Information Systems/Integrated Space Systems group, the virtual platform developed is a mission operations training simulator for the National Aeronautics and Space Administration (NASA) operators who “fly” satellites on a day-to-day basis.
“We already had a hot bench, which is essentially a satellite on a bench. It’s used for software development, running the test scripts that we use to test the satellite,” said Carver. One of the problems of a hardware system is controllability. “NASA wanted a software simulation model rather than a real-time system, which they really can’t stop and where they can’t inject faults very easily.”
Consequently, GD adopted a virtual platform technology that had been used already on the Iridium satellite program. “We modeled the entire hot bench and delivered the software model in less time and at less cost than that required by the real hardware,” said Carver, “and it’s a lot more flexible for NASA to use.”
The virtual platform design technology provider supplied GD with a model of the RAD750 (a radiation-hardened PowerPC), allowing the GD design team to focus resources on the system’s register-level and interface behavior. The result? “We dropped a binary image of the flight software developed for the RAD750 PowerPC into the simulator, and it worked first time in real time without any changes,” noted Carver. “The software didn’t know that it wasn’t running on a real PowerPC.”
GD also used the satellite virtual platform model to communicate with a real payload – a camera – over a Mil-Std-1553 serial interface. “The camera didn’t know that it was running through the simulation,” said Carver. “And you don’t have to simulate everything – you can get to the outside world through other interfaces.”
The hot bench on each program “is a highly-used resource with every subsystem design team trying to get ready for integration and test,” continued Carver, “there is a limited number of hot benches, so they are used round-the-clock. We distributed copies of the system model – mainly to flight software developers for development and testing – and freed up the real hot bench to the designers who needed the real hardware.”
In this case, the hot bench design-time savings were negligible, because the real hardware was already operative. The quantitative benefit of using a virtual platform was the time and material cost saving of not having to manufacture multiple hardware benches. The qualitative benefit was that it enabled NASA to do something that it couldn’t do adequately with real hardware – inject faults, understand system failure mechanisms and how the operators respond to those failures.
Towards the end of the program, “NASA introduced some new fault management – some fairly detailed failures that you couldn’t do with real hardware, because you didn’t want to break the real hardware,” said Carver. “It was necessary to demonstrate that the fault management software reacted as specified and, even more importantly, that it didn’t do something else.” The system model’s enhanced controllability and observability enabled GD to undertake much broader software fault coverage and stress testing than would have been possible with real hardware.
“Now that we’ve seen the value of the virtual platform on the back end, we see how we can pull that into the front end. For future use, we can give a system model to the flight software development team, and they could get all the way through acceptance tests without ever having seen real hardware. We’ll still need the real hardware for testing, but the software team wouldn’t have to wait on the real hardware to start development,” Carver said. “Each developer can be given a soft bench at low cost – and we can eliminate the night shift.”
Another future use that GD is actively considering is system hardware modeling and validation prior to building the hardware. This would “enable us to evaluate some new technologies that we’d like to integrate before we spend a lot of time and effort building new hardware,” noted Carver.
The Communications Solution Business Group of Infineon Technologies develops and uses SystemC-based virtual platforms for complex system-on-chip (SoC) design, and also provides the models to system customers. According to Dr. Christoph Kutter, the group’s senior vice president of product and system development, “the original motivation was to speed SoC development. The established serial process of hardware development followed by software development was not fast enough and not efficient enough. We pushed the virtual platform methodology because it enables concurrent engineering – we co-develop hardware, firmware and software.”
There are collateral benefits. “The system-level tests that we run on the virtual platform can be applied to the silicon,” said Kutter, and “some system customers use the models to accelerate their own product development.”
The group develops SoCs that contain multiple heterogeneous cores. An example is the S-GOLD3H, which can execute multiple wireless multimedia applications simultaneously over HSDPA, WCDMA and EGPRS links, without the need for a dedicated multimedia application processor (see inside the white box in figure 1).
Figure 1: Infineon used a virtual platform to design this multi-processor SoC (Source: Infineon)
Principal engineer Dr. Wolfgang Ecker said “we use virtual platforms to analyze the trade-offs that determine processor selection, communications infrastructure, cache architecture, choice of peripheral cores and, ultimately, silicon area. Silicon is not free. The objective is to devise an architecture optimized to deliver the customers’ desired features at a competitive cost.”