Driving the Golden Specification

Many students of history will know the expression “driving the golden spike” and its reference to the completion of the first transcontinental railroad in the United States. Many countries have their own stories of key moments and critical links. In chip development, what ties everything together is not a golden spike, but a golden specification. Unfortunately, this specification is traditionally a natural language text document that is not truly golden. This article explains why, and offers an alternative approach: executable golden specifications from which tools can automatically generate many types of files used in chip hardware and software development.

All That Glitters is Not Golden

Chip teams are usually rather proud of their specifications. Architects labor mightily to create a specification document that is complete and unambiguous. Product managers survey potential customers and investigate competitors to ensure that the specified chip will meet the meets of the target markets and be financially successful. Every development team—design, verification, embedded programming, validation, lab bringup, and technical writing—works off this same specification in an attempt to create exactly the intended product. Everyone involved has the best intentions and they generally do about as well as they possibly can.

Unfortunately, no plain text specification can ever be truly golden. Natural language is inherently imprecise and ambiguous, leading to different interpretations by different teams. Studies have shown that many of the errors that make it into silicon and cause chip turns are due directly to this issue. In pre-silicon verification and validation, engineers frequently think that they have found coding bugs in the register-transfer-level (RTL) design during simulation, only to find that the designers and the test writers interpreted the specification inconsistently. Resolving this may involve changing the design, the test, the testbench, or even the specification itself.

This is just one of several reasons that every specification is updated many times over the course of the project. Changing market needs or competitive intelligence may mandate new functionality. Revisions to interface specifications or new versions of intellectual property (IP) blocks may have ripple effects. Resolving issues discovered during logic synthesis, layout, or power analysis may propagate all the way back to the specification. Every time that the specification changes, all the teams must manually update their code, making synchronization challenging and introducing even more opportunity for errors due to divergent interpretations.

Rising chip complexity, shrinking market windows, and fast-changing market requirements place enormous burdens on IP and system-on-chip (SoC) development teams. Their design specifications become ever more complex, and the consequences of differing interpretations become ever more serious. Studies have shown that verification consumes up to 70% of the development time and resources, and every error or inconsistency that must be debugged prolongs time to market (TTM) and increases project cost. What the chip community really needs is an approach that produces a design correct by construction, confirmed by a smooth verification process with minimal debug loops.

Executable Golden Specifications and Specification Automation

Despite all the recent advances in artificial intelligence (AI) and natural language processing, there is no way to overcome the inherent issues with traditional specifications. A genuine golden specification must be executable, written in a format that is precisely defined and unambiguous so that code and documentation for every team can be generated automatically and directly from the specification itself. This removes any possibility of misinterpretation or divergent interpretations by different project teams.

The resulting IP or SoC design is correct by construction, and consistent with verification and validation environments, firmware and software, and product documentation.

Executable specifications and automation save a great deal of engineering effort and schedule time, not just once, but every time the specification changes. When the specification is updated for any of the reasons previously cited, the engineers can simply push a button and re-generate all files. This can be completely automated as part of a “makefile” flow or within a revision control system. This makes it easy to keep all development teams in sync at all times since engineers are not grabbing different versions of the spec and manually updating their files on different schedules. The resulting savings in TTM is typically measured in months rather than days or weeks.

It is not possible with currently technology to generate 100% of a large SoC using this flow, but many portions of the RTL design are amenable to automation, including:

• Datapaths
• Registers and memories
• Finite state machines (FSMs)
• Clock-domain-crossing (CDC) logic
• On-chip buses, bridges, and aggregators
• Connections between both IP and custom design blocks
• Safety mechanisms required by standards such as ISO 26262

When combined with silicon-proven IP blocks from commercial suppliers or previous design projects, a large percentage of even a large SoC design can be correct by construction. The types of project files automatically generated from the specification go far beyond the RTL design. SystemVerilog verification models, testbenches, and tests compatible with the Universal Verification Methodology (UVM) can all be generated for simulation, as well as SystemVerilog Assertions (SVA) for both simulation and formal analysis. Executing these tests builds confidence in the design, but consistent interpretation from a single golden specification means that no time-consuming debug is required.

Every SoC and many complex IP blocks rely on a combination of hardware and software to perform their functions. The hardware-software interface (HSI) forms the boundary between these two domains. The RTL design contains status and control registers (CSRs) that are programmed and monitored by low-level software such as embedded programs, firmware, and system drivers. When this code is written manually based on a natural language specification, different interpretations or lack of synchronization with the design is certain to occur. Fortunately, specification automation can also automatically generate the HSI software, guaranteed to be consistent with the generated RTL registers.

Embedded programmers can directly call the generated code from operating systems and other higher-level applications. These applications run not just in the final product, but also as part of the process to validate that the hardware and software work together properly. During pre-silicon validation, this happens in simulation, emulation, and FPGA prototyping. The application programming interface (API) with sequences to access the HSI is generated in both C/C++ and UVM SystemVerilog, enabling co-simulation of hardware and software. Of course, there is no testbench in the bring-up lab, but the same software can run on the actual chip during post-silicon validation.

Last but not least, specification automation can generate high-quality documentation in a variety of formats suitable for inclusion in manuals for end users of the IP or chip. Format diversity is a key requirement for a flow that can be adopted by a wide range of projects. The specifications might be written in SystemRDL, IP-XACT, XML, YAML, RALF, comma-separated-value (CSV), JSON, or custom XML formats. Users might also want to use an interactive tool such as Microsoft Word, Microsoft Excel, or a dedicated specification editor. Many of these same formats are also required as generated outputs to enable format translations and interoperability with other tools.

A Proven Commercial Solution for Specification Automation

Some forms of specification automation, such as generated of register RTL designs and associated UVM code, have been around for years. But only recently has the scope of executable specifications and automated generation expanded to include everything outlined above. The Agnisys IDesignSpec™ Suite is a robust, proven commercial solution available today that provides all the requirements and capabilities discussed so far:

• IDesignSpec^TM GDI automates the design and documentation of registers and memories
• IDS-Batch™ CLI generates all the same files as IDesignSpec GDI, but in command-line mode
• IDS-Verify™ generates UVM-based simulation environments and SVA for registers and memories
• IDS-Validate™ automates pre-silicon and post-silicon validation by generating C/C++ sequences
• IDS-Integrate™ automates the assembly of IP and custom design blocks into a full SoC
• IDS-IPGen™ generates both standard and custom IP blocks, including commonly used blocks such as AES, DMA, GPIO, I2C, I2S, PIC, PWM, SPU,Timer, and UART

Conclusion

Traditional natural language specifications don’t suffice for today’s complex IP and SoC designs. Specification automation generates key files from executable specifications, including verification and validation environments with out-of-the box 100% coverage. This state-of-the-art approach improves engineering productivity, shrinks time-to-market, and ensures high-quality correct-by-construction designs.