Inside Portable Stimulus – Introducing a Processor

So far in this blog series, we have talked about some of the fundamentals of the Accellera Portable Test and Stimulus Standard (PSS) and how it can enhance a universal verification methodology (UVM) flow. This is a highly effective strategy for block-level verification and allows for reuse of existing Verification IP (VIP) models. However, as soon as a few design IP blocks are integrated together, it is almost certain that one or more processors will become a part of the subsystem. As soon as that happens, a new verification strategy is called for.

Software often represents an important aspect of the functionality of the system and parts of it may need to be included in the verification process. Being able to directly manipulate the bus, as required by a UVM flow, means that more thorough testing can be conducted, not always the verification focus after multiple blocks have been integrated together. You are not trying to repeat the verification that was done on each block in isolation. You are instead trying to make sure the blocks communicate with each other correctly and can perform the higher-level functions of the product. In fact, once the processor and bus protocol have been fixed in the design, it may not be possible for all functionality of each IP block connected to the bus to be accessed.

Within a simulation environment, each processor will probably be represented by an instruction set simulator (ISS) or some other form of behavioral model. These are readily available from all processor vendors and third parties. The models provide functional accuracy and, while they are not perfect in the timing sense, they are usually good enough for most purposes. Most important, they run orders of magnitude faster than a register transfer level (RTL) model and will have been integrated into your favorite RTL simulation environment.

What software should you run on those processors? In the past, special-purpose test code would have been written to exercise the subsystem in the form of a small suite of directed tests. Seasoned verification engineers know how long it takes to develop these tests and maintain them as the hardware changes. With PSS and test synthesis, this problem almost becomes trivial.

Let’s not get too carried away too quickly. Just because we have a path to automatically generate software to run on those processors, the problem isn’t fully solved, nor does it answer all questions about the level of software to be used.

Embedded processors can access everything in the design in the exact manner that would be accessible by the actual running software. Why don’t we just run that? There are a couple of reasons for this. First, the production software may not be ready. While the shift-left movement is trying to bring software development forward, it is not always possible to have them developed concurrently. Second, you don’t want your testing to be constrained to only what the current version of the software does to the hardware. What if additional features are expected to be released later through a software update? If the hardware hasn’t been verified when the product was initially released, then it may affect your ability to add those updated in the future.

That does not mean you should never use any production software. As you get close to finalizing the design and verification is close to the coverage goals, you may want to use production drivers, some other layers of protocol stacks or even elements of the operating system. Breker, for example, provides a library of functions that can be used during test synthesis. These functions, such a memory management, form the basis of a multi-layered hardware/software interface abstraction layer that we will discuss in future blogs.

Getting a testbench to operate when software is running is another problem. How do you coordinate activity on the external inputs of the subsystem or chip? There has to be a method to communicate between the processor and the VIP so that activity can be coordinated. We accomplish this at Breker using TrekBox (see Figure 1).

TrekBox monitors memory in the simulator using the back-door memory API of the simulator. When a certain address is written to by the processor, it indicates a command to be sent to a particular VIP. Within that message could be more information about the exact operation required. Thus, it becomes possible for the processor to coordinate external activity. This is useful if you want to test, for example, flooding data into all external ports when the software enters an interrupt service routine.

In the previous blog, we developed a testbench for a sample design shown in Figure 2. VIP feed the two UARTs. The processors had been removed, replaced by bus interface models driven by the testbench. Everything was controlled by the testbench.

In figure 3, three configurations of the testbench are shown tb_cfg_uart, tb_cfg_ss and tb_cfg_fc. The first configuration was previously used with one processor, running four threads and communicating through transaction level modeling (TLM). The designation TLM indicates that they are not true CPUs in the design –– instead, they are generating traffic for the TLM interfaces. The code associated with this is shown below.

8 component tb_cfg_uart {
  
9
10   // Start of user code Component_tb_cfg_uart
11   Processor cpu0 {"cpu0", 4, Processor::TLM};
12   // End of user code

We could modify the configuration to instead generate test for two processors, each running four threads. This requires changing the configuration code as shown below.

  
8 component tb_cfg_ss {
9
10   // Start of user code Component_tb_cfg_ss
11   Processor cpu0 {"cpu0", 4, Processor::TLM};
12   Processor cpu1 {"cpu1", 4, Processor::TLM};
13
14   memory_resource ddr0 {"ddr0", 0x1000};

While no processors are instantiated into the design, a memory region is still defined for data reads and writes and for behavior checking. To switch to making the generated tests software driven instead of utilizing UVM, we again change the configuration code as shown below.

8 component tb_cfg_fc {
9
10   // Start of user code Component_tb_cfg_fc
11   Processor cpu0 {"cpu0", 4, Processor::SDV};
12   Processor cpu1 {"cpu1", 4, Processor::SDV};
13
14   memory_resource ddr0 {"ddr0", 0x1000}; 

That is the only change that needs to be made. Now test synthesis will output the code for the processors, the code that gets loaded into TrekBox and everything to perform the coordination of the external VIP and shown in Figure 1.

In the next blog, we will transfer this example onto an emulator, creating a few new problems. It is this portability of tests between simulation and emulation that was the primary motivation for the creation of the standard.

As always, please reach out to me with any questions or if clarification is required.