VSPs ease embedded multicore designs

Embedded-system design has been around since just after the first microprocessors hit the market. The difference today is that the extreme computational requirements of modern systems require using multiple CPU and DSP cores combined with tens or hundreds of peripheral and hardware accelerator blocks, and tiered memory structures—all connected by sophisticated multilevel buses and crossbars. At the same time, the software content of embedded systems is increasing at an exponential rate.

One method being used to improve the quality and productivity of embedded design is the virtual system prototype (VSP), a fast software simulation model of the system that is cycle-, register- and timing-accurate. The edit-compile-execute-debug cycle is as fast as it is on the real hardware. Once an optimal architecture has been identified, the winning VSP becomes the executable specification (golden reference) for the system. Hardware design teams can then start to perform detailed design, while software developers can use the VSP to port and develop the remaining system software.

Here are some do's and don'ts for those embarking on this productive design methodology.

Do

• Use a VSP to quantify architecture performance early. Multiprocessor architectures require a particular focus on the bus and memory system architectures. Thorough testing identifies bus architecture bottlenecks that, if left unaddressed, could cause resource contention, resulting in stalls and process starvation.

• Test candidate architecture performance against real or representative apps software. This approach is easier to construct, and avoids the uncertainties and errors associated with estimation-based approaches.

• Use the VSP to capture intent in the form of an executable spec to drive implementation and verification. A thoroughly developed VSP is much more effective than a written specification in describing system operation in an unambiguous way.

• Use cycle-accurate models. Such descriptions present fewer restrictions—they can be used for timing-critical, highly reactive systems and can be used with implementation verification.

• Maintain the VSP throughout the design phase, updating and reissuing it, as implementation-driven architectural refinement occurs. The VSP can be used to debug system problems long after the actual system is available.

• Use the VSP for software development. With adequate performance, the VSP can be used not only for early device driver creation, but also for middleware and end application development. Developing and testing the application software early can catch flaws before the implementation is complete, saving costs.

Don't

• Wait for hardware before beginning software development and system-level testing. VSPs have allowed customers to begin software development on the order of one year sooner than conventional, hardware prototype-based design methodologies.

• Wait for final application development to begin application-level performance testing. Representative applications are better than none.

• Try to use a function-only model for more than it is capable of. Function-only models can't accurately process bus-timing and processor-execution exceptions. Bus bandwidth affects program access to instruction and data resources that have a first-order effect on system performance.

• Carry over modeling practices more suited for implementation than for simulation. Focus on what's important. For example, consider the modeling styles for describing synthesizable RTL descriptions. Because these are purposed for synthesis, much of the complexity and verbosity of the description are not needed to represent cycle-accurate functionality faithfully. The extra baggage degrades simulation speed.

• Use a hybrid modeling approach consisting of fast-functional and slow-but-accurate models. As the design undergoes engineering changes, keeping the multiple models functionally in sync entails a lot of time and resources. Moreover, the slow-but-accurate model lacks sufficient speed to do thorough timing-critical testing. Dual-use solutions are simpler and more productive.

• Settle for inadequate performance. Faster is nearly always better. However, software development requires performance in the tens of MIPS. Often, billions of clocks must be exercised to develop the software thoroughly.

- Jeff Roane
Technical Marketing Director, VaST Systems Technology