How to Manage Change in Your Semiconductor Specification with Helpful Online Tools

Every semiconductor design starts with a specification, traditionally written in a natural language such as English. Every team—hardware, software, verification, validation, and documentation—develops their part of the project based on this specification. They refer to the document so often that physical copies become dog-eared and online versions are permanently bookmarked. This post discusses what happens when the specification inevitably changes and describes how to minimize the impact on the team.

SoC Specifications are Challenging

Any design specification requires effort to write and maintain, but system-on-chip (SoC) projects present special challenges. For a start, there are usually multiple specifications. SoCs comprise hundreds or even thousands of IP blocks, and many of these have their own specifications. Some of these blocks are licensed from partners or IP suppliers, who supply specifications along with their designs. The SoC integrators generally do not have source files, just PDF documents.

In addition, there are often special forms of specifications for specific teams. The architecturally defined programmable registers are a good example. The software team generally has a programmer’s reference guide that helps them configure the registers and use them to accomplish the intended functionality of the SoC. The register sets, registers, and fields are also likely to be included in the overall hardware specification, and perhaps in standard formats such as SystemRDL and IP-XACT.

The bottom line is that it is impractical or even impossible to merge all this information into a single SoC specification. The development team therefore shoulders the burden of managing a hierarchy of specifications from multiple sources and, even worse, ensuring that they are consistent. Many chip bugs arise from the hardware team developing their register transfer level (RTL) design from a register specification that does not completely align with the software programmer’s guide. 

The Only Thing Constant Is Change

For a large and complex SoC, developing a complete and self-consistent set of specifications is challenging enough. On top of that, specifications change many times over the course of the project. There are several reasons for this. IP suppliers may update their own specifications, which affect the overall hierarchy and may have ripple effects. The SoC team has little control over this since they usually want to integrate the latest version of each block.

The SoC feature set often changes as well, perhaps due to evolving market requirements or a new offering from a competitor that requires a response. The sales and marketing teams continue to talk with potential customers for the entire duration of the project, and they may find out new information that changes the product requirements. Changes in the high-level specification means changes in lower-level specifications, especially in the programmable registers.

Modifications may also be made due to issues encountered while implementing the design at the RTL stage or lower. Detailed analysis of the placed-and-routed chip may reveal that it does not meet the power, performance, and area (PPA) requirements for the intended product. If these issues cannot be fixed at the layout, synthesis, or RTL stages, the impact can ripple all the way up to the top-level specifications. Changes may be significant, with a serious impact on all the project teams.

Automation Is the Only Answer

There is only one way to deal with change effectively: generate as many of the project files as possible from executable specifications. This saves team resources and schedule time by automating many of the traditional manual development steps. It also ensures consistency across all generated files, completely eliminating SoC bugs due to hardware-software misalignment or differing human interpretations of specification details. 

The term for this approach is specification automation, which requires both executable specifications and generation tools. There are many formats amenable to automated generation, including IP-XACT, SystemRDL, spreadsheets, and sequence descriptions. Recent advances in artificial intelligence (AI) have even made it possible to generate some types of files, such as assertions, register RTL designs, and register C/C++ headers, from natural language specifications.

While the savings at the start of the SoC project are significant, the biggest benefit from specification automation comes whenever any specification changes for any reason. The developers can simply push a button to re-generate all relevant files. This saves additional resources and prevents schedule creep on every single iteration. With the Agnisys IDesignSpec™ family of products, updated and consistent design, verification, software, validation, and documentation files are available in minutes upon every specification change.

Conclusion

Specification automation with the Agnisys solution saves the SoC project time and money while ensuring consistency across all development teams. The many changes that inevitably happen during the project are handled quickly and automatically, minimizing the impact for everyone. Developing a complex hierarchical set of SoC specifications remains challenging, but the use of executable formats makes it faster and more precise. There is simply no reason that every SoC development team should not adopt this approach.