How to Reduce Semiconductor Design Errors Caused by Inconsistent Specifications
Content
Introduction
Every chip or intellectual property (IP) project starts with a design specification, often requiring multiple specifications for different aspects of the design. Traditionally, these specifications have been written in a natural language such as English. Such specifications are inherently imprecise and ambiguous, subject to different interpretations by different teams. This inevitably leads to inconsistency across the project, consuming valuable time and resources to resolve.
This eBook presents a better way: executable golden specifications that can be used by specification automation tools to automatically generate many key files used in the development process. This approach benefits every team on the project: architecture, hardware design, verification, embedded software, pre-silicon validation, post-silicon validation, and documentation.
Limitations of Traditional Specifications
Natural language is flexible and rich in context, but these characteristics make it inherently imprecise and ambiguous. When writing creatively or concocting puns, the attributes of natural language are advantages. When creating an engineering specification, these same attributes are detrimental. Two designers may read the same specification and create blocks that do not interact properly because they interpreted the shared interface differently.
This sort of problem permeates design projects. For example, if a designer and a verification engineer responsible for checking the design interpret the specification inconsistently, a great deal of time and effort may be spent looking for the source of bugs that do not exist. As another example, an embedded programmer may be responsible for writing the code that configures and controls the operation of a design.
Inconsistent interpretation results in embedded code that does not manipulate the system-on-chip (SoC) design correctly, which again requires a lot of work to debug. Ideally this happens in hardware-software co-verification, also known as pre-silicon verification, so that the silicon is correct. Sometimes issues are not discovered until post-silicon validation in the bring-up lab, resulting in a software workaround at best and a chip turn at worst.
The notion of inconsistency applies not just to the interpretation of specifications, but also to the specifications themselves. As noted previously, the initial high-level project specification often leads to multiple detailed design specifications. These specifications can diverge, and the many files hand-written by engineers based on the detailed specifications can also diverge, all based on the inherent issues with natural language. This is an unavoidable result of using non-executable specifications that cannot be processed by electronic design automation (EDA) tools.
It is also important to note that all design specifications change many times over the course of an IP or SoC project. Market conditions may change, competitors may introduce new products that must be countered with new features, and issues found during design implementation may all result in specification changes. Every time that any specification changes, the updates must be propagated to all project teams.
This process opens new avenues for inconsistency. The schedules of different teams may not be aligned on versions of the specification or on updates to the files written from this specification. Once again, time and effort will be wasted trying to debug issues and get design, software, verification, and validation files in sync. Every specification tweak consumes more project resources and prolongs time to market (TTM). Some engineers use macros in traditional editors such as Emacs when writing specifications, but these provide only limited help.
Some may wonder whether advances in artificial intelligence (AI) and machine learning (ML) will help the situation. AI is improving the ability to interpret natural language but ML algorithms are trained on data sets created by humans. If multiple engineers are prone to inconsistent reading of a specification, it is unreasonable to expect an AI solution to somehow avoid or resolve any differences. Further, AI is trained on last-generation data and thus cannot support new innovation. Thus, even with AI/ML, natural language is unlikely to ever be fully suitable for a machine-executable specification.
Introduction to Specification Automation
Fortunately, there are many specification formats that are unambiguous, precise, and much more suitable for processing by EDA tools. As shown in Figure 1, the process of specification automation involves selecting appropriate executable specification formats and using EDA tools to automatically generate as many design, software, verification, validation, and documentation files as possible.
Cleary, automatic generation of files saves significant effort over manual creation, reducing project cost, shrinking the schedule, and speeding TTM. Perhaps even more importantly, specification automation completely eliminates the inconsistency associated with the use of imprecise and ambiguous natural language for specifications. Since every group generates their files from the same golden specification, all files are consistent and aligned.
This resolves the issues raised by the earlier examples:
- Designs interact properly since their common interfaces are auto-generated from the same golden specification
- The verification environment and tests are consistent with the register-transfer-level (RTL) design, so no time is wasted chasing false bugs
- RTL designs and the embedded code that controls them are also consistent, so there are no unpleasant surprises in the bring-up lab
As noted earlier, the problems of inconsistency mushroom every time that a specification changes. With an automated flow, all files for all teams are re-generated at the push of a button from the same golden specification and automatically propagated across the project. Thus, all teams remain in sync and all files are always consistent. This saves even more resources and further reduces the schedule beyond the initial file generation.
Complete the form to download
your copy of this eBook.
Sequence Specification Automation
Generated register functionality tests are extensive, including programming sequences for register fields, register-level sequences, positive/negative sequences, and special register types. Complex designs may also require specialized tests that explore corner cases and check interaction among registers. These rely on custom sequences that can themselves be quite complex, with many conditional branches.
Writing these sequences by hand in UVM code for verification and again in C/C++ for validation is time-consuming, error-prone, and guaranteed to yield inconsistencies. Every time that a sequence specification is updated, both the UVM and C/C++ must be updated manually, causing greater divergence between the two types of tests. Fortunately, sequence generation is also part of a complete specification automation solution.
The Portable Stimulus Standard (PSS) includes syntax for the definition of sequences, but there are no widely adopted legacy standards for sequence specification. Thus, in addition to support for PSS, a specification automation solution must support the definition of custom sequences in a specialized editor. For maximum flexibility, the specification language must include complex control features such as loops, branches, waits, calls, switches, and macros.
The IDesignSpec Suite meets all these requirements. As shown in Figure 3, both IDS-Verify and IDS-Validate support the specification of complex custom sequences using a sophisticated editor or PSS. From this specification, the solution automatically generates UVM tests, C/C++ tests, and formats for manufacturing automatic test equipment (ATE). All generated C/C++ code (headers, functional tests, and custom sequences) can be incorporated into production drivers and embedded programs.
Agnisys supports hybrid sequence specification. When lower-level sequences are specified using the dedicated editor, the IDesignSpec Suite can generate PSS models for portability to other tools that use this standard. The verification team can write PSS directly to create higher-level sequences in more complex configuration and tests for chip bring-up, debug, etc. To make this easier, Agnisys provides an intuitive and powerful PSS editor.
Integration Specification Automation
Today’s SoCs contain many thousands of both standard and custom IP blocks. Chip assembly, also known as chip integration, is the process of connecting all these blocks together. This step is becoming a much more significant portion of the overall design process. Designers tend to regard this as a tedious task, rather anticlimactic after the challenges of architecture and block-level design. Performing this effort by hand is extraordinarily error-prone.
The sheer number of interconnections can run into the millions. An example SoC containing 500 IP blocks with 200 interface signals each requires at least 100,000 signals to connect them and assemble the chip. Since not all blocks sit at the top level, many of these signals run through multiple levels of hierarchy and require even more connections. A single signal may run through dozens of levels and name changes many times.
Since some IP blocks are multiply instantiated, many of the interconnecting signals have very similar names. Managing signals that differ only in prefixes and suffixes leads to many typographical errors. Typically, designers use spreadsheets to specify the interconnections, and additional errors creep in as they hand-write the RTL code to match the specification. Every time that the specification changes, the manual RTL updates offer new opportunities for errors.
Specification automation can prevent inconsistencies between the interconnect specification and the design by generating the RTL code. Again, the Agnisys IDesignSpec Suite provides a solution. IDS-Integrate™ includes a specialized editor for interconnect specification, a spreadsheet with additional powerful features. These include wildcards for ports and signals to enable integration of complete buses in a single line of specification.
As shown in Figure 5, IDS-Integrate generates the RTL code for the top level of the SoC, and lower levels of hierarchy as well if requested by the designer. As noted earlier, many IP blocks have interfaces using standard buses. In some cases, multiple blocks cannot be connected by simple wires. When necessary, IDS-Integrate also generates RTL multiplexores, aggregators to combine multiple buses of the same type, and bridges to connect buses of different types.
IDS-Integrate handles custom IP blocks as well as those generated by IDS-IPGen. Designers can also generate templates for new blocks with mirrored ports from existing blocks, and then automatically connect the blocks. Other capabilities of IDS-Integrate include:
- Generating subsystems with the flexibility to customize or configure
- Automatically adding instances, making connections, and restructuring
- Viewing the resulting schematics for design analysis
- Running design rule checks to endure IP and SoC quality
Traditional semiconductor development is based on specifications written in a natural language, followed by multiple teams interpreting the standard and hand-writing design, software, verification, validation, and documentation files. This consumes vast amounts of human resources and prolongs TTM. There are many opportunities for inconsistencies among the specifications and the manually created files.
Specification automation is the modern way to develop SoCs and IP blocks, auto-generating a wide range of files from executable golden specifications. This process can be repeated whenever specifications change. This ensures consistency across all project teams at all times, saves resources, shrinks project schedules, and produces correct-by-construction designs.
Agnisys is the undisputed industry leader in specification automation, providing a complete solution that spans registers, sequences, IP blocks, and block integration. To learn more, visit www.agnisys.com.
Complete the form to download
your copy of this eBook.
