Setting the Stage for the Next Abstraction

By Louie De Luna, Agnisys Chief Product Evangelist

As generations of designs evolved from a few hundred transistors to hundreds of billions, our industry abstracted the problem space from transistors to schematics to gates, and from RTL bit-level to transaction-level. Using abstraction, designers were able to focus on the high-level design and tests while the tools took care of the automation and calculations at the low level – this certainly made the design flow more efficient and engineers more productive. Over the years abstraction has allowed the EDA industry to manage the ever-increasing complexity and scale of ASIC/SoC designs.

On a related note, check out Mark Glasser’s blog regarding his perspective on abstraction (while you are there check out his great photography too).

The strategy behind the Portable Test and Stimulus Standard (PSS) is again to raise this level of abstraction to the next level. PSS will enable SoC teams to specify stimuli and tests at a high level. PSS has constructs for modeling high-level test scenarios such as data flow (buffer, streams, states), behavior (actions, activities, components, resource, pooling), constraints, randomization, and coverage. The PSS tool generates downstream code that is reusable from block, subsystem, and system levels, allowing for retargeting on various verification platforms such as simulation, emulation, prototyping, or post-silicon validation.

The PSS 1.0 standard was recently released in June 2018. Inherently, the standard focuses on the high-level test scenario specification devoid of any implementation detail that will invariably tie it to a particular target platform. The user codes the implementation-level details of the tests, also known as test realization, using the PSS ‘exec’ blocks. Users manually create the sequences and map them to the output generated by the PSS processing tool. Users create the test intent using PSS and generate C/UVM/SystemVerilog sequences from it. These implementation-level sequences exercise the Hardware/Software Interface (HSI). 

SoC Hardware/Software Interface Layer

The Hardware/Software Interface (HSI) layer describes both the configuration and the functionality of SoC peripherals and how they interact with CPUs. The Interconnect Fabric is at the center connecting CPUs to various programmable IP slaves. On the software side, the HSI is the CPU Instruction Set. On the hardware side, the HSI is the IP registers and interrupts. These IP slaves can have their own memory or can even be a bridge to a slower bus depending on the requirements. The slaves are programmed by reading and writing to the embedded registers.

As an example, the code below is a common UVM sequence that is manually coded by users, showing that the HSI is a critical part of the sequence.  This code snippet contains several writes/reads via the register model ‘rm’:

• write to register TXDATA
• write to register field CONTROL.TXEN
• read from register field STATUS.TXDONE

The HSI is a critical part of the PSS high-level tests or sequences. Sequences are built on registers because they contain register reads/writes and they need to handle IP-level registers comprehensively which means sequences need to have access to the full SoC register and memory map. Register and memory map specifications are usually defined in IP-XACT, SystemRDL, Word, or Excel. What’s needed is another interface layer between the sequences and IP registers/memories/pins.

Proposed Solution – Augmenting PSS Tools

The proposed solution is to provide a golden specification for the implementation-level sequences with a built-in generator that can re-target the sequences for various verification platforms.

The solution is based on our tool called IDS-Validate™ which augments PSS tools. Various SoC design houses already use IDS-Validate in production to generate sequences from a golden specification into multiple formats such as UVM, SystemVerilog, C, HTML, Matlab, etc. We recently made some improvements to IDS-Validate to support PSS tools.

The four basic steps of the tool flow are as follows:

1. In IDS-Validate, the user defines sequences in pseudo-code in the golden spec (spreadsheet or text format).
2. In IDS-Validate, the user generates sequences in multiple formats (UVM, C, or SystemVerilog) and their PSS exec headers.
3. In the PSS tool, the user creates the test scenarios and calls the action blocks generated by IDS-Validate.
4. In the PSS tool, the user synthesizes the test scenarios and generates the required files for the target platform.

The solution must have a variety of input formats that the users are already comfortable with, such as spreadsheets or text. It must have some mechanism to abstract out the actual code generation using some form of template. This is a requirement because it helps in abstraction and keeps implementation details away from the sequence specification.

The implementation detail is captured in the golden spec just as the high-level test intent is captured in PSS, then all target outputs can be created from the specification. The solution for capturing the golden specification for sequences includes the following capabilities:

• High level of abstraction devoid of implementation detail
• Control flow
• Access to hierarchical register data for SoC, Subsystem, and IPs
• Access to pins, signals, and interfaces
• High-level execution of arbitrary transactions
• Deal with timing differently based on the target
• Hierarchy of sequence and base address of the DUT
• Parallelism between:
  • Device and target environment
  • Subsystem and IP level
  • Several interfaces at the IP level

In addition to these core features, certain metainformation is also required so that these sequences can be written in a concise way without any duplication. These features are:

• Arguments
• Parameters
• Enum/Define/Macros
• Structures
• Look Up Tables

Depending on the output configuration, the generated outputs can include:

• .pss file that contains the required component with multiple action/exec blocks
• .c and .h files contain the sequences for firmware
• .sv files contain the sequences (SV task) for verification

The UVM sequences can be used for simulation, C code for firmware and device driver development, and SystemVerilog sequences for post-silicon validation. The target platforms also impose certain requirements on this scheme. Certain concepts make sense in one platform and not in the other. For example, the concept of front door and back door register read/writes are important to verification engineers for simulation. The speed of register read/write is important for firmware developers during post-silicon validation. Firmware developers also worry about consolidated read/write and read-modify-writes. Similarly, a post-silicon validation engineer may be interested in optimizing the throughput of the chip-tester by simultaneously testing four to eight chips.

With the help of IDS-Validate, SoC teams can centralize the creation of the implementation-level sequences from a golden spec. The tool includes the interface layer to the hierarchical register data, pins, signals, and interfaces. These sequences are also hierarchical which can then be compiled into a library for both vertical and horizontal reuse.

The mantra of PSS is to abstract the tests without any implementation details, and the main value add of IDS-Validate is to capture the implementation details in a portable format. The full abstraction is not complete without a tool like IDS-Validate to take care of the low-level details. Together, IDS-Validate and Portable Stimulus tools offer a complete solution from specification to fully portable tests.

Conclusion

Our electronics together with the internet have now become part of our daily lives. They have become an extension of our intellect and capabilities. The weekly weather forecast and the thousand-year history of ancient civilizations are both at our fingertips. We ask Google just about everything, and we buy most of our stuff on Amazon. I certainly rely on GPS when I travel and visit customers. My kids do much of their homework on the iPad apps and upload their presentations to the cloud so they can easily access them at school.

Undeniably, the required functionality, bandwidth, and scale of today’s electronic products will only continue to increase. Abstraction has been the key tool that helped us manage and reduce the problem space over the years, and once again we need it to get us to the next level. The release of PSS 1.0 has set the stage, and PSS is positioned to provide the next level of abstraction needed to manage the forthcoming challenges. As a company, we actively support this important endeavor.

We were invited to present this solution at CDNLive Silicon Valley on April 2-3, 2019.  If you’re in the area stop by and ask us about it to get more information.

If you’d like to learn more, please feel free to contact us.