Once a scenario has been created and executed, it will be possible to see any performance issues that may have been uncovered by the test.
This is the second of our blog series looking at the concepts contained within the Accellera Portable Stimulus Standard (PSS) (see also “Inside Portable Stimulus: Filling in the Blanks”). As a reminder, some of the material used in these blogs comes from the DVCon training session that goes over the basics of the language and how tools work. I use many of the same examples for continuity purposes, but I will present the material in a different manner.
In my previous blog, we covered the notions of partial specifications and how a tool uses them to construct scenarios. Examples that we used were primarily sequential in nature, but we also introduced the stream construct. An action must produce a stream of data at the same time that it is consumed by another action. This implies concurrency between the two actions. PSS also has ways in which concurrency can be explicitly defined and ways in which concurrency can be prevented. This is the focus of this blog.
Most system-on-chip (SoC) devices are capable of performing multiple actions at the same time but are often restricted by the availability of resources. You are probably familiar with the basic concepts that limit how a resource can be used. For example, a block may be capable of performing many actions but can only execute one action at a time. Examples may be a modem that can either send or receive or an audio codec that can either encode or decode, but not both at the same time.
Another type of resource is a direct memory access (DMA). This may be able to perform several concurrent actions, possibly with restrictions related to them. A similar type of resource is a CPU. While the number of these is fixed within a design, each may be capable of running multiple threads.
A further type of resource is a memory, a pool resource from which actions may need to reserve a certain quantity for the duration of the action.
Within PSS, these resources are controlled in much the same way that you would in any concurrent programing environment — using locks. When a lock is defined within a block, it can be grabbed or released by anything that has access to that lock. This also implies a scheduler that decides when things can or should be run. This is one of the more powerful tasks assigned to a PSS tool.
Note: Not all PSS tools have schedulers, and if they do, they may only be capable of setting up simple test schedules. By comparison, the Breker scheduler is a synthesis tool that interleaves tests to maximize system stress, allowing for memory allocation and other resource requirements.
PSS defines two principle constructs to fork concurrency in a required control flow: schedule and parallel. Schedule defines a number of actions that can be performed concurrently, but it is up to the scheduler when each action starts. They could finish up executing sequentially or in any order. Parallel is a much tighter construct in that all actions must start execution at the same time.
Subsequent sequential actions are delayed until all defined actions have completed execution, meaning that the concept of a join is supported. It, thus, becomes possible to define complex control flow templates that the tool will use to generate scenarios. When we add in the ability to create partial specifications, the tool can explore around a particular area, perhaps focusing on stressful situations for the SoC.
Based on this, we see that there are several pieces of information that feed into the scheduler:
1) Control flow — The desired aspects of a test case that generated scenarios should adhere to. As we previously discussed, these may be partially specified.
2) Data flow — Actions consume and generate data. Attributes of the way that data flows between actions may define notions of concurrency.
3) Locks — These constrain what can be executed concurrently based on the resources available in the system.
4) Software execution resources — The number of CPUs available and the number of threads that can be run on them defines the maximum software concurrency that is possible. Additional threads can also execute if they do not require coordination from the processors.
The role of the scheduler is to find scenarios that meet all constraints. It is possible that no schedule is possible. For example, the dataflow may define that two things have to run concurrently, but they each rely on a resource that is shared between them. In other cases, both tasks may have to wait until the resources they both require become available.
The establishment of a schedule is part of the scenario generation process. This is unlike the running of an OS, in which tasks are scheduled in a dynamic fashion. There is a downside to this in that the scheduler does not know ahead of time how long any action will take. This means that the tool may not be able to construct the densest schedules.
Once a scenario has been created and executed, the schedule can be annotated with information about the run, and from this, it will be possible to see any performance issues that may have been uncovered by the test.
For example, Fig. 1 shows a graph created by engineers at Analog Devices using Breker TrekSoC. This was the subject of a paper presented by them at the 2018 Design Automation Conference (DAC). This graph generated tests for an SoC that contained two DSPs, with each DSP running four execution threads. In addition, the SoC had an I/O port that supplied transactions from TrekSoC.
The graph performed various read and writes and processor operations. When this graph was constrained to create one specific scenario and executed, it generated a schedule shown in Fig. 2.
This schedule shows dependencies between tasks. Although this is a simple schedule, it highlights how dependencies on specific resources from multiple code segments across threads are handled and how the scheduler allows for them in the execution flow. In my next column, I will discuss how a portable stimulus tool generates tests that can be executed on various target platforms. In the meantime, I welcome your comments, and please feel free to ask questions if anything I’ve that said is not clear.