Inside Portable Stimulus — Hardware Software Interface

This blog series has stuck to what is in the Accellera Portable Stimulus 1.0 standard (PSS), but in this particular blog, we will deviate a bit. We will discuss a capability that did not make it into the first release of the standard, the Hardware Software Interface (HSI). It is a critical capability that now has the full attention of the Accellera Portable Stimulus Working Group (PSWG). Its absence results in extra work for companies that want to adopt Portable Stimulus tools without some form of this functionality.

The problem is easiest to understand by thinking about test portability. By that, we mean the ability to go from a single description of test intent and to execute that test, without modification, on a variety of execution engines. Those execution engines include simulators, running at either the transaction level or register transfer level (RTL), emulators, prototyping solutions, virtual platforms, and real silicon. Now, consider a test that needs to get data into a certain register or memory location or retrieve the contents of that register or memory to ensure that a test operated correctly.

When executing on a simulator, it is easy to use backdoor-access mechanisms, done without disturbing any aspect of the design under test (DUT). People who have been using universal verification methodology (UVM) will be familiar with the notions of a register abstraction layer (RAL) and backdoor memory access. Fast-forward to wanting to rerun those tests when you get the first silicon back from the fab or attempting to migrate the test to drive a full SoC on an emulator. With UVM, that often involves a complete rewrite of the test harness.

This is often not as easy as it sounds. Consider the case of the target being an emulator. You may have to run the necessary bus cycles to access the memory, and you have to do that without disturbing any of the circuitry not associated with that access. Some of this may not be obvious to the user. The very purpose of Portable Stimulus was to solve this issue. And yet, the 1.0 release failed to address it, leaving it as an exercise for the reader.

While PSS can basically do everything that UVM is capable of doing, PSS has an additional mode of operation. It can generate tests that run on the processors contained in the design, thus verifying it from the inside out. If you want to run a test on those processors, you either need to have some form of OS running on the processor, which creates a very large overheard for RTL testing, or you have to consider it to be a bare-metal processor. The last thing a verification team wants to do is spend a lot of time writing the necessary software to do this. HSI is the clean solution to this problem.

HSI provides a basic level of OS-like features that allow tests to be written to a standardized API while hiding the mechanics of executing those tests. It enables what looks like a UVM register access to be the same whether you are accessing a block register via a UVM sequence or if the register is contained within an embedded processor or in the final silicon. For an embedded processor, it may transfer register contents to a location in memory that is accessible from the outside or feed that data through a UART. For real silicon, the register may be accessed or modified through the scan chain. The mechanism to perform this function for each target is the same to the test writer. Most of the time, this would be supplied as part of the delivered tool.

Of course, the tool can go further, much like a full-blown OS, to schedule multiple tests together with key resources across processor threads to really wring out an SoC.

While it wouldn’t be right for me to discuss any of the details about the solution being proposed with the PSWG, this capability has been in our legacy tools for many years, and our customers are fully aware of the power that this interface provides. Some other tool vendors also have their own versions of this interface running within their tools, but the hope is that the Accellera effort will bring about a unification of these interfaces.

As already stated, users of UVM will be quite familiar with the notions of an RAL — necessary to have the DUT and testbench able to agree upon a common layout of the bits within registers. Users of hardware/software co-verification solutions will also be familiar with the need to define the memory map — again, so that the testbench and design can be kept in sync. Test Suite Synthesis knows where memory is located, any restrictions placed on that memory, and how the memory is accessed by the processor and peripherals. For example, is it little or big endian, or are there any security limitations associated with certain address ranges?

This is about the limit of what the PSWG is looking into for the PSS 1.1 release and does not contain all that is necessary for a full HSI. But it is a good start. Tool providers that truly understand the problem space and provide solutions that enable full system-level verification methodologies to be implemented already go beyond these basics in providing an HSI that encompasses the complete bare-metal layer.

Companies such as Breker, Vayavya, Agnisys, and others have been developing these solutions and know what it takes to make tests portable. These solutions increase the power of Test Synthesis based on PSS and reduce the amount of effort that users have to put in to get test portability. While PSS has reduced the risk associated with each vendor having their own language, it has not removed the ability for each vendor to compete in both the quality of tests generated and in the amount of effort that users have to expend to generate those tests.

As always, please feel free to reach out to me with questions or comments.

Author’s note: Breker Verification Systems will be at https://www.dvcon.org/ in Booth #701 March 2–5 in San Jose, California, demonstrating its Test Suite Synthesis tools based on the Portable Stimulus Standard.