Inadequate specification methods are a significant reason why today’s chips are so hard to develop. The solution is to write as many executable specifications as possible in unambiguous formats and to make them executable.
Natural languages are inherently ambiguous, so specifications written with them may be interpreted in different ways by different engineers. Further, design specifications evolve constantly over the course of a project. The effort to update them, propagate the changes to all teams, and reflect these changes in multiple places adds up quickly.
By writing as many executable specifications as possible in unambiguous formats, the design files, verification code, software, and documentation can all be generated automatically when the specification changes. All teams remain in sync, saving many months of effort and preventing bugs related to inconsistency.
The IDesignSpec family from Agnisys provides a specification automation solution that meets these goals. Engineers can develop executable specifications using intuitive editors or import them using industry-standard formats, and then simply push a button to generate all files needed by the project teams. This solution has been used in production by thousands of engineers at hundreds of chip and system companies.
Where executable specifications help
Development of huge, complex system-on-chip (SoC) devices has become a daunting prospect for many companies. The resources required—in people, tools, and compute power—are staggering. These costs are compounded by the enormous cost of fabrication for a deep submicron chip. Using a field-programmable gate array (FPGA) eliminates this specific line item, but almost always adds significant cost to the final product. Even developing a single block of silicon intellectual property (IP) is challenging because today’s blocks can be as large and complex as yesterday’s chips.
There are many reasons why chip development is so hard, and thousands of individual tasks that must be completed along the way. Entire books have been written to propose new ways to design, verify, and validate semiconductors in less time, with fewer resources, and with less chance of catastrophic bugs making their way into production parts. Some techniques, such as expressing the design in register-transfer-level (RTL) format and converting it to gates via logic synthesis, have already been widely adopted. In verification, constrained-random testbenches using SystemVerilog and the Universal Verification Methodology (UVM) are nearly universal. Formal methods using SystemVerilog Assertions (SVA) are common. System validation has been made easier to manage with virtual prototypes early in the project and emulation in the later stages. A few novel approaches, such as portable stimulus, are starting to gain traction.
Sadly, all this advanced technology is not enough. Chips still take too long and cost too much to develop, and most require at least one ’spin’ (re-fabrication) before they are ready for production. This article considers another relatively new technique that can help a lot: specification automation.
The goal is to automatically generate as much as possible of the RTL design, verification testbench and formal environment, associated C/C++ code, and end-user documentation as from executable specifications. Although no solution exists today for an entire SoC, many portions of the design are amenable to this automated process. The resulting flow benefits all members of the development team, saving project time and money.
The trouble with specifications
Every chip, just like every engineering project (and almost any project of any kind) starts with a specification. In the classic product development flow, the product marketing team surveys the target customers on an ongoing basis to see what features they will need in their next-generation products. This is often a give-and-take process, with experts from both sides brainstorming on what problems the target industry faces and how they might be addressed. Sometimes, the customer is looking to expand its market or enter an entirely new market, so the discussion is wide-ranging and more speculative. In other cases, the idea for the new market might arise from the chip company, in which case it might have to find new potential customers from scratch.
The result of this effort is generally a rough textual description of a new chip, listing features and some high-level goals such as price and power consumption. Turning this into a design specification from which an engineering team can develop the chip is a big effort. The ideas from the marketing staff are often too lofty in nature to be built, so it is important to put them in the context of current or forthcoming technologies. System architects typically play a key role in connecting the dots between vision and silicon, while working out many of the details about how the chip will do its job. They take the lead in writing a design specification that reflects the market requirements while serving as the baseline for the development project. For most project managers, a solid specification is an absolute requirement before anyone starts writing code or laying down transistors.
The biggest problem with specifications is that they are written as text in natural language. Despite decades of attempts at formalism, there is no widely accepted or adopted alternate format to describe the functionality of a complete chip. The advantage of natural language is that it uses the same syntax and semantics that team members rely on for informal verbal and written interactions among themselves. The downside is that natural language is inherently imprecise, sometimes downright ambiguous. It is subject to different interpretations by different team members, leading to major project inefficiency. After all, the specification is the main vehicle for communication about the chip. Every team relies on it.
As an example of a problem, a designer may interpret some part of the specification one way and write the RTL code accordingly. The verification team may read the same text differently and develop an inconsistent testbench and tests. When the verification engineers run these tests, they will fail because the design does not behave as they expected. Figuring out what is wrong, fixing the bug, and verifying the fix is tedious and time consuming. It is widely accepted that verification consumes the most resources of any stage in chip development and that debug is the dominant task within verification. Every bug that must be found and fixed contributes to this cost in resources and schedule delays.
On an SoC project, more teams are involved so the risks are even greater. By definition, an SoC contains one or more embedded processors executing code. The system consists of a combination of hardware and software, and these must be validated together. The programmers writing the embedded code might interpret the application programming interface (API) in the specification differently than the hardware designers. This problem might not be found until late in a project, perhaps when running production software in an emulation system. Fixing a bug at that late stage is likely to delay thetape-out. Finding such a disagreement in the fabricated chip is far worse since a silicon spin might be required.
Some SoC teams might argue that nearly all the design is composed of reused blocks or commercial IP, so new coding bugs are unlikely. However, for the chip to have any value in the market it must have new functionality. If the blocks are assembled in a unique way, there is still a risk that the verification or software teams will develop code that is inconsistent with the way that the hardware is integrated at the chip level. Further, it is hard to imagine any chip that does not have some novel features requiring new RTL design code. The specification is vital to keep all the project teams aligned, but with natural language there are always challenges.
It is also important to note that a specification changes multiple times over the course of a project. The product marketing team continues to work with potential customers and may learn additional information that results in changes to the specification. Competitors may introduce chips with new features that must be added to the design to keep it competitive, or an updated version of a standard used in the chip may be released. There is also a feedback loop from the development process to the specification. During design and implementation (synthesis and layout), the engineers may find issues in power consumption, testability, chip size, and other domains whose resolution ripples back to changes in the specification.
Figure 1: Each specification change causes a waterfall (Agnisys)
Every specification on every SoC or IP project is updated many times. Whenever this happens, there is a waterfall effect, as shown in Figure 1. Changes to the hardware design require re-verification. In many cases, embedded software updates are also required, mandating re-validation. The technical writers must align the end-user documentation with the changed specification. Manually updating the RTL design, verification environment, embedded code, validation environment, and documentation repeatedly over the course of the project is a major effort. Even if a perfect, unambiguous specification could be written in natural language, the frequent changes would still be an issue.
Automation with executable specifications
The only real solution for ambiguity is writing the specification in a precise format rather than natural language, and the best way to deal with constant change is to make this format executable. Project managers may dream about an executable specification that can generate a complete SoC design at the push of a button, with the entire RTL description ready for implementation and all the embedded code ready to compile and run. This level of automation is not possible today technology, nor is it likely to be in the immediate future. However, specification automation is well established for certain parts of the design, including registers and memories, and its use in more areas has become feasible over the last few years.
Figure 2: Specification automation applies to many parts of the SoC (Agnisys – click to enlarge)
Figure 2 summarizes the aspects of executable specification automation available that have been proven on many production chip projects. The familiar register and memory executable specifications start the process. Users can specify all the memories, register sets, registers, and register fields using a specialized editor or import descriptions from popular formats such as SystemRDL and comma-separated values (CSV) files. Statements of design intent (assertions) can be provided in natural language. A specification automation solution can automatically generate:
- SystemVerilog or VHDL RTL design code for the registers and memories;
- Properties to verify the RTL code formally (including SVA assertions, constraints, coverage, and helper code);
- UVM testbench models and test sequences to verify the RTL code in simulation (including bus agents, monitors, drivers, predictors, sequencers, and makefiles);
- Embedded C/C++ code needed to program and validate the registers and memories; and
- Documentation suitable for use across the project team.
This generation process works for plain registers as well as a wide range of special register types such as alias, lock, shadow, FIFO, buffer, interrupt, counter, paged, virtual, external, and read/write pairs. The process of verifying and validating these diverse types of registers can be quite different, but the generation of UVM and C/C++ sequences to perform these tests handles these differences automatically. In some cases, registers might require custom sequences that fall outside of these types. These can be specified by the user with a specialized sequence editor that supports basic programming constructs such as loops and conditional statements. From this executable description (Figure 3), the specification automation solution can generate both customized UVM and C/C++ sequences for verification and validation.
Figure 3. Custom sequences can be specified (Agnisys – click to enlarge)
In addition to the user-defined registers and the custom design blocks that they support, almost all SoCs make use of IP from internal or external sources. Some companies maintain in-house libraries for commonly used design structures and many projects acquire portions of the design from other projects or partner companies. Commercial IP vendors also play a role, especially for blocks that implement a standard processor instruction set architecture (ISA) or an interface protocol. In many cases, the SoC designers need to customize some of the IP blocks to meet their requirements, but modifying proven RTL code is always tricky. This process requires significant expertise in the ISA or protocol and runs the risk of breaking the standard functionality in the process.
For this reason, a library of IP generators is vastly preferable to a library of fixed IP blocks. Most standards have options for bus widths, selective functionality, power/performance/area (PPA) tradeoffs, user extensions, and more. With an IP generator, users can bring up an interactive interface and select from the available options (Figure 4). Traditionally, the generator then produces an RTL design to meet the user’s requirements. In the context of specification automation, an IP library generator can do much more. Any complex IP block contains programmable registers, so the generator can automatically output the UVM and C/C++ sequences for these registers. It can also generate a UVM testbench for simulation, and properties for formal verification. Finally, it can provide extensive documentation for the IP, including instructions for use and validation.
Figure 4: Generated IP blocks can be customized (Agnisys – click to enlarge)
Hooking up the IP blocks into a top-level chip design is no trivial exercise, especially when hundreds or thousands of such blocks are used. Doing so manually is a tedious and error-prone process that can also benefit from specification automation. The library of standard IP generators includes the information necessary to connect these blocks together, such as assembling multiple agents on internal or external buses. The RTL code to provide this hookup and documentation of the resulting SoC can be automatically generated. The best specification automation solutions can also apply this process for custom design blocks. Users can specify how their own blocks should be interconnected, including rules for intelligent name-mapping between block input and output ports with identical or similar names. With a small up-front user investment in specification, the top-level RTL design for even a huge SoC can be produced automatically.
The six generated types of outputs shown earlier in Figure 2 illustrate the power of today’s specification automation technology. These output files provide value to many different project teams in a unified, consistent manner. RTL design code for registers, memories, standard IP blocks, and chip hookup becomes part of the design that is implemented to build the actual chip. Many designers run some amount of formal verification, so they also benefit from the generated properties. Deeper formal analysis is usually performed by dedicated engineers on the verification team, while others focus on simulation with the UVM testbench and sequences. Of course, they also receive the RTL code because that is what they are testing. Some SoC verification teams also run the C/C++ embedded code on processor models in simulation, although the slow speed of such runs limits how much they can accomplish.
Many verification teams turn to emulation or FPGA prototyping for more thorough hardware-software co-verification and pre-silicon system validation. The programming team may use these same platforms to develop their apps and other software on top of the generated C/C++ code, or they may choose virtual prototypes for this purpose. These run quickly and make program development and debug easier but, because they use abstract design models rather than the RTL code, they are not directly verifying the full system. Regardless of how much pre-silicon verification/co-verification/validation occurs, the bring-up team is responsible for final system validation by running production software on the fabricated chips in the lab.
As noted earlier, chip and IP specifications change many times over the course of the project. While there is clear value in automatically generating so many files and greatly reducing manual effort, perhaps the biggest payback from specification automation comes during the looping process. Every time that the specification changes, a simple push of a button updates the RTL design, formal properties, UVM verification environment, embedded code, pre-silicon validation environment, and documentation. The time saved in avoiding manual updates is measured in months of engineering effort and frees up money and resources for more valuable tasks.
This process ensures that all teams receive consistent, updated files after each specification update. This prevents a whole class of bugs related to improperly synchronized design, testbench, and embedded code. Consistent documentation is also critical in keeping the teams aligned after each update. In addition, the automatically generated text and diagrams are frequently of such high quality that they are used by the technical writing team as part of the manual and guides for the end-users of the chip or the electronic product containing the chip.
State-of-the-art specification automation
While register automation has been mainstream use for years, other aspects of specification automation have only recently become available. The Agnisys IDesignSpec (IDS) family provides a very broad solution in this domain, incorporating all the requirements and capabilities discussed here. As shown in Figure 5, this solution automatically generates many types of file, including support for verification using embedded C/C++ code, UVM, and the Portable Stimulus Standard (PSS). Its components include:
- IDesignSpec (IDS) – a register RTL design and model generator;
- IDS NextGen (IDS-NG) – a common front-end and specification editor;
- Automatic Register Verification (ARV) – a register verification generator;
- Specta-AV – a comprehensive UVM testbench generator;
- ISequenceSpec (ISS) – a custom sequence generator;
- SLIP-G – a standard library of IP generators (GPIO, TIMER, I2C, PIC, etc.);
- SoC Enterprise – a SoC design assembler; and
- DVinsight – a smart editor for SystemVerilog/UVM design and verification code.
Figure 5: The available solution spans a wide range capabilities (Agnisys- click to enlarge)
Specifications are the starting point for every IP and SoC project, but they take a lot of time to write, and then they change many times. Specification automation has emerged as the best way to generate written documents as well as design, verification, and validation files from executable formats. Because of the frequent changes, this process saves time and resources many times during the project, not just once. For significant portions of the design and testbench, specification automation eliminates hand coding, tedious manual updates, introduced errors, and the effort to find and fix these errors. Agnisys has been providing tools in this space for more than 14 years, and the current production-proven solution provides the most comprehensive set of features available. Specification automation is a must-have for every development team. To learn more, visit www.agnisys.com.
Tom Anderson is a technical marketing consultant working with multiple EDA vendors, including Agnisys. His previous roles have included vice president of marketing at Breker Verification Systems, vice president of applications engineering at 0-In Design Automation, vice president of engineering at IP pioneer Virtual Chips, group director of product management at Cadence, and director of technical marketing at Synopsys.