One interesting question that arises from time to time is whether the Cadence® Perspec ™ System Verifier can verify software as well as hardware. The question is simple enough, but the answer is more complex. There are at least two versions of “yes”, although the most common usage of the tool is focused almost entirely on verifying an RTL design. This post attempts to explain all this, and in doing so covers a fair amount of ground. I welcome your thoughts and comments, because there are likely even more dimensions than we will cover here. Let’s start by defining hardware-software co-verification, in which you are running production software or a close facsimile (perhaps with special debug features) on some model of your hardware design. For many system-on-chip (SoC) devices, it is challenging to bring up a complete RTL model in traditional simulation, and trying to execute a complete software stack is out of the question. It may take days or even weeks just to boot the operating system (OS) or real-time OS (RTOS), let alone run driver stacks and applications on top of the OS. The most common solution, of course, is to use an emulation system, such as the Cadence Palladium® series, or an FPGA prototyping system, such as the Cadence Protium™ Rapid Prototyping Platform. These platforms run much faster than simulation, so booting and running production code is feasible. Many SoC teams argue that it is essential to perform at least some hardware-software co-verification prior to tapeout. After the chip has been fabricated and is available in the bring-up lab, even more production software will be run on it. When running on FPGA prototypes or silicon, the term “validation” may be used rather than “verification.” The Perspec System Verifier is most commonly used to automatically generate “bare metal” tests that require no operating system or other software to be available. This is an enormous asset during the verification process, since the Perspec System Verifier tests find many bugs that would prevent an OS from booting, but would be very difficult to trigger with production code. The Perspec System Verifier’s focused test approach and powerful debug features make it much easier to find, diagnose, and fix hardware bugs early in the process. Further, the Perspec System Verifier tests are tuned to run on each platform, from simulation to acceleration, FPGA prototypes, and silicon in the bring-up lab. The Perspec System Verifier entirely meets the current requirements for a portable stimulus solution as defined by the standardization effort in the Accellera Portable Stimulus Working Group ( PSWG ).These requirements are also focused primarily on hardware verification. Although co-verification with software is encompassed within the complete PSWG vision, much of this work lies well into the future. One can imagine that a portable stimulus model might someday go beyond creating verification and validation tests to generating production software, at least for lower-level components such as drivers. But, for the present, there are two less revolutionary ways in which a portable stimulus tool (such as The Perspec System Verifier) might perform some level of software verification, even as it focuses primarily on finding bugs in your RTL hardware design. The first case occurs when there is some common code between the portable stimulus model and the production software. It is not uncommon for SoC teams to have software building-block libraries that are used both by verification teams to build “DV drivers” and by the software team to build production drivers. The Perspec System Verifier model may call some of these library routines (for example, to set up the DMA operation in the crypto example). In such a case, the Perspec System Verifier enables hardware-software co-verification by generating tests that exercise your library code on your RTL design. Further, one can imagine a portable stimulus tool generating tests that run on top of the OS rather than on bare metal. Such tests would be performing more software co-verification, because more of your production code is involved in the mix. However, this approach compromises the ability of portable stimulus to stress the RTL design. Part of the operating system’s job is to insulate programs from the hardware, so it is impossible for an OS-based test to have the kind of full control possible with bare metal. Debug would also be much more difficult with an OS in the way. The broad vision of the PSWG, the rich capabilities of the Perspec System Verifier, and the growing needs of the SoC industry ensure that this space will continue to evolve. For now, rest assure that the Perspec System Verifier can do a great job of stressing every aspect of your hardware design while verifying certain aspects of your software as well. Again, we welcome your comments. Tom A. The truth is out there...sometimes it's in a blog.![]()
![]()
↧