Setting the Stage for the Next Abstraction

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 your 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 specify stimulus 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 the downstream code reusable from block, subsystem and system-level, which can be re-targeted for various verification platforms such as simulation, emulation, prototyping or post-silicon validation.

The PSS 1.0 standard was recently released on 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. These implementation-level details of the tests also known as test realization are coded by the user by 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 programed by reading and writing to the embedded registers.

Figure 1: SoC HW/SW Interface Layer

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

Figure 2: Example UVM Sequence with HSI Description

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 ISequenceSpec™ which augments PSS tools. ISequenceSpec is already used in production by various SoC design houses for generating sequences from a golden specification into multiple formats such as UVM, SystemVerilog, C, HTML, Matlab etc. We recently made some improvements to ISequenceSpec to support PSS tools.

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

1. In ISequencesSpec, the user defines sequences in pseudo-code in the golden spec (spreadsheet or text format).
2. In ISequenceSpec, 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 ISequenceSpec.
4. In the PSS tool, the user synthesizes the tests scenarios and generates the required files for the target platform.

Figure 3: ISequenceSpec + PSS Tool Flow

The solution must have a variety of input formats that the users are already comfortable with, such as spreadsheet or text. It must have some mechanism to abstract out the actual code generation using some form of templates. This is a requirement because it helps in abstraction and keeps implementation detail 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 IP level

In addition to these core features, certain meta information 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/writes 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 ISequenceSpec, 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 ISequenceSpec is to capture the implementation details in a portable format. The full abstraction is not complete without a tool like ISequenceSpec to take care of the low-level details. Together, ISequenceSpec 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 thousand-year history of ancient civilizations are both on 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 many 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. PSS 1.0 is already released and the stage is already set. PSS is poised to provide the next level of abstraction needed to manage the forthcoming challenges, and as a company we 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 learn more, please feel free to contact us. 

Tags: Agnisys, Assertions, Automation, functional verification, hsi, IDesignSpec, ISequenceSpec, ISS, PSS, UVM registers, Verification

Category: Abstraction

This entry was posted on Sunday, March 31st, 2019 at 10:18 am. 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.