This article is part of the TechXchange: Addressing Chip Verification Challenges
What you'll learn:
- The iterations a specification goes through in a given project.
- Are chip design and verification specs, and hardware and software specs, separate entities?
- Automation of the specification process.
Every successful engineering endeavor starts with a solid specification, and chip development is no exception. A semiconductor project generally begins with the marketing requirements for a new product, either the chip itself or a system incorporating the chip. System architects develop a high-level specification for the chip, typically including both aspects of the hardware design and the interfaces used by software to control and communicate with the hardware.
The specification is refined as the project continues, and many of these refinements result in additions or changes to the specification. Choosing the target silicon technology may have ripple effects back to the hardware specified—for example, if the original memory size can’t be supported. In addition, features may be added in response to competitive products introduced during the development timeline.
Further specification refinements happen while the hardware and programming teams are creating the design and its associated software. Sometimes the vision of the architects proves impractical or too expensive to implement. Adding clocks, resets, power-management features, and testability support to the design may also require unanticipated specification updates. Engineers often say that change is the only certainty when it comes to chip specifications.
Development teams always want to save resources to lower project costs and shrink the schedule to reduce time to market. This is possible only through higher levels of abstraction and increased automation of the design and verification process. Finding a better way to create and maintain chip specifications is part of such a solution. Taking this next step in chip development requires recognizing and dispelling some common myths.
1. Chip specifications must be written in natural language.
It’s true that most specifications are written in natural language, probably most commonly in English. It’s also true that no other existing language can specify 100% of a chip’s requirements from both the hardware and software viewpoints.
However, many aspects of a chip can be described using more formalized domain-specific languages (DSLs) and formats. These include registers and memories, programming sequences, verification sequences, silicon test sequences, power-management structures, and hierarchical chip assembly. These portions of the specification are inherently unambiguous and more precise than natural language.
2. Chip specifications aren’t executable.
Development teams have long wanted to be able to feed their specifications into some sort of magical electronic-design-automation (EDA) tool that would generate the register-transfer-level (RTL) design as well as the testbench and tests needed to verify it. While some might argue that the RTL descriptions themselves qualify as executable specifications, in practice this implementation is too detailed, and a higher level of abstraction is required.
Though no full-chip solution is available, the DSLs and formats used for specific parts of the specification can be executable given the right tools. It’s possible to generate the RTL design, testbench components, verification tests, programming headers and sequences, files for automated test equipment (ATE), and end-user documentation for these portions of the chip.
3. Natural language isn’t executable.
It’s true that a complete chip specification isn’t executable, but there’s excellent progress being made in understanding natural language descriptions for certain aspects of the chip. Artificial intelligence (AI) and machine learning (ML) can transform these descriptions into executable form. Two particularly active areas involve generating SystemVerilog Assertions (SVA) from statements of design intent and converting natural language sequence descriptions into SystemVerilog verification tests and C/C++ code for drivers and embedded software.
4. Chip design and verification specifications are separate.
In the past, this has been the case. The chip-verification team took the design specification and developed a verification plan that iterated all of the design features that had to be verified. With the advent of constrained-random verification, the focus shifted from manual tests to achieving coverage goals.
Verification planning tools can tightly link a list of coverage targets with the design specification, ensuring that all design features are covered in the verification plan. This approach is automated even further when testbench components, including coverage checkers, and verification tests are generated from the executable portions of the chip specification.
5. Chip hardware and software specifications are separate.
This has also been the case in the past, and it remains true to some extent. Some aspects of the software specification are independent of the underlying hardware. However, a significant portion of the software interacts directly with the hardware, usually through reading and writing registers.
As noted above, C/C++ driver and embedded code can be generated automatically from executable specifications. Thus, part of the software specification is shared with the hardware specification.
6. Register specifications require obscure languages.
Registers and memories were some of the first parts of chips to have executable specification formats supporting generation of design and verification code. It’s true that some of the early tools had arcane proprietary languages, but this is no longer the case.
SystemRDL is a widely adopted and supported standard DSL for register and memory definition. The standard IP-XACT format is used to communicate design information, including registers, among different EDA tools.
In addition, some tools support specification of registers, register files, and memories in an intuitive graphical format. For example, the IDesignSpec family of products from Agnisys provides a specialized editor as well as plug-ins to Microsoft Word and Microsoft Excel.
7. Sequence specifications can’t be executable.
Automatic generation of verification sequences from executable specifications is widely accepted and adopted. For example, the Agnisys ISequenceSpec tool supports specification using a specialized editor or Word/Excel plug-ins.
In addition to sequences for SystemVerilog testbenches, the tool generates Portable Stimulus Standard (PSS) headers to facilitate creation of complex scenarios built on the sequences. It also outputs C/C++ code for embedded software and ATE files. Further, as mentioned earlier, AI/ML generation of sequences from natural language is an emerging technology that’s usable today.
8. IP specifications can’t be easily integrated at the chip level.
With natural language specifications, details for IP and other lower-level blocks can simply be merged into the text for the full chip. It turns out that easy integration is also possible with executable portions of specifications.
Since the generation process works at multiple levels, engineers can move up and down the specification hierarchy with predicable and consistent results. Executable specifications are in text-based formats, so they can be merged into a chip-level specification in the same way as natural language.
9. IP block integration must be done manually.
Especially in a large system-on-chip (SoC) design, the task of integrating and interconnecting IP blocks can be huge. Tens of thousands of blocks are not uncommon. However, with executable interconnect specification, it’s no longer necessary to do this manually. IP libraries can include the information needed for a chip assembly tool such as Agnisys SoC Enterprise to create the higher levels of hierarchy, all the way up to the full chip, and automatically generate all interconnecting logic. Users can provide guidance using standard formats such as Tcl and Python.
10. Custom block integration can’t be automated.
Automatic integration and interconnection work for custom blocks as well as standards-based IP. Users can specify information for their blocks using the same Tcl/Python approach, including features such as pattern matching to recognize ports and signals that should be connected.
11. Chip specification is a one-time investment.
As described above, chip specifications evolve over the course of the project, changing dozens or even hundreds of times. Without automation, every single time that the specification changes, the designers must update the RTL implementation; the verification engineers must revise the testbench, tests, and PSS models; the embedded programmers must modify their code; and the technical writers must edit the documentation. Executable specifications enable regeneration of all these output files at the simple push of a button.
Thus, automation saves time and resources in the initial creation of the specification and adds even more value on every subsequent revision. Every member of the development team directly benefits. For SoCs and all chips of significant size or complexity, specification-based automation is a must-have technology.