As I often point out in my blog posts, modern chip development is one of the most complex tasks undertaken by humans. There are hundreds of billions of transistors, all of which must be designed, verified, validated with embedded software, and fabricated correctly. Making this all happen is a massive challenge for chip developers, electronic design automation (EDA) vendors, and foundries. I’d like to address some of the ways that EDA companies such as Agnisys can help with leading-edge tools, advanced methodologies, and best practices based on years of experience.
Creating the RTL Design
It’s impossible to imagine design engineers creating billions of transistors from scratch, and in fact they never do. The register-transfer-level (RTL) abstraction allows designers to write code that is automatically turned into gates and transistors by logic synthesis and layout tools. This is not enough, since it would still take far too long to create an entire RTL chip design. One way to help a great deal is by reusing existing designs from EDA vendors, IP suppliers, shareware sites, and previous projects.
Designers have another method in their toolbox: automatically generating RTL code from executable specifications. Although technology does not exist yet to describe and generate an entire chip, there are many parts of the design that are amenable to this approach. Examples include programmable registers, memories, state machines, bus interfaces, bus bridges/aggregators/multiplexers, clock domain crossing (CDC) logic, functional safety mechanisms, and IP block interconnections.
Verifying the RTL Design
The days when designers would just run some simple simulations on their own designs are long gone. Verification is very much its own specialty, almost always using the Universal Verification Methodology (UVM) standard. UVM supports constrained-random stimulus generation, self-checking tests, assertions of design intent, object-oriented programming (OOP), and functional coverage to assess verification completeness. UVM tests and testbenches are very complicated.
Chip verification engineers appreciate any help they can get. Fortunately, many types of verification files can also be generated from executable specifications. This is especially true for registers, with tests tuned for the various special types such as indirect, indexed, read-only/write-only, alias, lock, shadow, interrupt, counter, paged, virtual, and external. If the verification engineer also provides a sequence specification, the generated UVM tests do even more to configure and verify the registers.
Programming the Hardware
The set of programmable registers represents the hardware side of the hardware-software interface (HSI), the core of system-on-chip (SoC) designs. The software side consists of drivers, microcode, embedded programs, and other low-level software that has direct access to the hardware. The HSI is the mechanism by which this software accesses the registers to initialize, configure, and control the hardware, followed by the gathering of status and results.
Writing this low-level software is also a big task, and programmers also appreciate any help they can get. Many of the same activities performed by the UVM tests can also be performed by C/C++ code running the SoC’s embedded processors, and this can also be automatically generated from the register and sequence specifications. Much of this code can be incorporated directly into production software, saving programmers time and improving quality.
Validating the SoC Design
Validation, also called hardware-software co-verification, is the process of running the hardware and software together to ensure that the whole system works as intended. RTL verification simulation usually runs with stubs or simple processor models for the sake of efficiency. Simulation for pre-silicon validation uses cycle-accurate processor models that execute test code. Post-silicon validation runs tests on the actual chip in the bring-up lab, followed by production code.
The C/C++ tests generated from the specifications execute in pre-silicon validation using a combined UVM-C/C++ testbench that can also be automatically generated. Many of the same C/C++ tests can also run on the chip in the bring-up lab, although at that stage there is no longer any UVM testbench involved. As noted earlier, production embedded code can leverage the C/C++ tests, so automatic generation also supports the final stages of post-silicon validation before the chip goes to production
Tying It All Together
The entire methodology described in this post is known as specification automation. A shared, executable golden specification becomes the single source of truth (SSOT) for all the teams on the chip project. As many design, verification, software, validation, and documentation files as possible are generated automatically from the specification. This saves human and computing resources, shrinks the project schedule, and ensures correct-by-design quality.
Note that these are not one-time benefits. Specifications change many times over the course of a project for many reasons. Every time this happens, the chip developers simply re-generate all relevant files from the SSOT. This eliminates manual updates, preserving quality and saving even more time and resources. It also ensures that all the project teams are always using the latest specification, fully in sync, eliminating errors due to differing interpretations of the specification.
All this is exactly what we do at Agnisys. Our many customers use our IDesignSpec™ Suite of specification automation solutions every day to develop better chips. We provide the tools, methodologies, and AI technology they need to be successful, while advising them on best practices. Please contact us to learn more.
