System Functionality Includes Software

Listening to users is never a bad thing. Users are the people who set Breker along its current direction and during the process of standardizing Portable Stimulus (PS), the ability to talk to an expanded group of users allowed Breker to see a larger portion of the total available market. We learned a lot.

Another group of people are starting to get interested in Portable Stimulus. These are industry consultants who help with methodology insertion and getting the industry up to speed. While not huge in number, these people have something that few others have to offer – a broad view of the market. They have seen more design styles and types of design than would exist within a single company.

One of these industry consultants – Neil Johnson, who is the chief technologist at XtremeEDA, attended DVCon this year. He listened to what was happening with Portable Stimulus and what new techniques he would have to learn, and started to try and make sense of it. This was his first exposure to PS and he asked himself where it fits into the larger scheme of verification. He came up with a diagram which was published on LinkedIn and quickly started an industry discussion about how his diagram was right, wrong, or ways in which it could be improved. Below, is the current state of his diagram, reproduced from his blog with permission.

Fig 1: Where Portable Stimulus fits in the verification landscape. Source Neil Johnson – XtremeEDA.

Neil makes an interesting observation that PS only covers the feature set, which essentially maps to the hardware, while most of the use cases, that define the overall solution, involve software. He observes only a small overlap between them. This exposes a set of features that are meant to be in PS and yet are missing in the early adopter releases. This is the Hardware Software Interface (HSI).

A modern system contains many processors. Most of these are not application processors, but deeply embedded processors where the software is an integral part of the functionality. In addition, higher-level software is most likely driving the power states of complete system and functions such as reset and interrupt handling are core to system functionality. The verification of this type of software is not something that you leave until the hardware is finished. It needs to be integrated much earlier in the development cycle.

Part of the system integration task involves verification of processor integrations. This might include relatively straight forward testing such as ensuring the consistency of the register and memory map, I/O transactions, or the correct handling of interrupts through an interrupt service routine. It can also include far more complex verification needs such as system-level cache coherency, or power domain cycling. These verification tasks must be completed as early as possible to avoid late stage bugs being discovered, which can dramatically slow down the progress of a project.

In the past, much of this type of testing was left until prototypes or early silicon were available and just involved booting the OS. But that was when processor integrations were fairly standardized with repeated architectures, and bugs were less likely. Today, SoC verification consists of running C-tests on the processor model coincident with transactions on various ports of the device and backdoor memory accesses. It is this verification domain for which PS is ideal. Without an effective HSI, it will be hard to operate these tests on a realistic device, or a large amount of basic coding will be required by the users.

HSI provides the necessary connection between the hardware and software domains such that software tests might be written, at an appropriate level of abstraction, to drive the hardware components of an SoC-under-Test. One of the objectives of PS is portability, and yet without HSI, key software services will have to be recreated for each SoC-under-test. This will reduce the idea of portability as the services tend to be specific to each phase of testing. HSI is essential to allow common tests to be reused from phase to phase, without them having to be heavily adapted once a processor is introduced.

Unless HSI is included in PS, the standard will be relegated to addressing the systems of a decade ago. The only way that true system-level verification will be possible involves a large increase in the effort that has to be expended by the user and that will slow adoption and relegate PS to be a hardware focused solution and to simpler forms of verification. It is time that the EDA industry realized that systems include software. Together we can do this.

Tags: Breker, Breker Verification Systems, Hardware Software Interface, HSI, portable stimulus, SoC under test, System integration

Category: Knowledge Depot

This entry was posted on Monday, April 23rd, 2018 at 1:48 pm. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.