How Specification Automation and Version Control Keeps an SoC Register Design and Spec in Sync
Ever wondered how SoC design teams keep all their files in sync and avoid costly errors?
Synchronization of files is critical in system-on-chip (SoC) design because the output files of one development stage are often the input files of another stage. Version control systems such as Git are used to track changes and maintain consistency among files by tagging a collection of input files with a release label. Specification automation further improves this process by automatically generating output files for multiple development stages whenever a change is made in the specifications. This ensures that all generated files are in sync, saving time and effort while reducing errors.
Synchronization is Critical
SoC development involves thousands of input files, and often as many output files, for hardware design, verification, software, validation, and documentation. Some input files are developed by hand, while others are generated automatically by electronic design automation (EDA) tools during previous stages in the process. The output files from every stage are generated by such tools. Thus, there is a great deal of linkage and interdependency among the development stages and the teams performing them.
Proper results and useful output files rely on accurate input files. We all know the old “garbage in, garbage out” saying, but this is only part of the challenge. Even if every input file is technically correct, all the input files must be in sync. Any lack of alignment means that the development stage is compromised and the results are either suspect or not generated at all due to tool errors. Sadly, it’s really easy to get into this situation on real-world projects.
Imagine that the design specification changes to add a new programmable register to the architecture, and that the hardware designers have added this register to the register transfer level (RTL) design. Suppose that the hardware verification team has not yet added any simulation tests for the new register. When the regression test suite is run, the new register will not be exercised and code coverage will drop. If the verification team instead adds the tests first, before the RTL design is updated, the tests will fail completely because they try to access parts of the design that don’t exist yet.
A similar effect might occur during pre-silicon validation, in which the hardware and software simulate (or emulate) together. If the RTL design and the embedded software that controls the hardware are not in sync, validating testing will fail. It can be very challenging to track down the source of verification or validation failures, especially on a large SoC where no one person really understands everything that is happening in the hardware and software.
Version Control to the Rescue
Project teams learned years ago that file synchronization is critical, and they invented version control systems (also known as revision control systems) to help. Such systems track all changes to all files, which helps in code development by clearly tracking changes. Changing history is very helpful in debugging and determining the root cause of failures in any development stage. A collection of consistent input files is tagged with a release label so that these files are always used together.
In the previous example, the verification team would know right away that the RTL design and the tests were inconsistent because they would have different release labels. A makefile or other flow control mechanism would refuse to combine inconsistent files in a way that would generate bad output files or generate errors due to mismatches. Successful execution of a development stage generally results in the output files being tagged with the same release label or a related one.
Version control systems have been around for more than fifty years, ranging from legacy solutions such as SCCS and RCS to more advanced systems such as CVS and Subversion (SVN). A few commercial offerings have also garnered market share from time to time. Today, Git has become the version control system of choice for most hardware and software code development projects.
Even when using Git, the problem is that the bundling of files into releases is traditionally a manual process. It falls to the development team to track what changes and when. Going back to our register example, if the verification tests for the new register are incomplete but tagged to match the hardware release, verification may be incomplete and code coverage may still take a dip. What’s really needed is automation of as many development stages as possible.
Specification Automation to the Rescue
The process of generating development files automatically from executable golden specifications is known as specification automation. We at Agnisys pioneered this domain with our register automation solution, and we’ve expanded it greatly in recent years. We can generate a broad array of design, verification, validation, software, and documentation files from a wide range of executable input formats, including the SystemRDL and IP-XACT standards. We’ve even leveraged AI technology to generate some types of files from design specifications written in natural English.
This means that the number of files that must be manually managed and tagged for releases is reduced dramatically. If a new register is added to the design specifications, this can be tagged with a new release label and our tools can automatically generate the output files for multiple development stages. Using a makefile or a similar system triggers this process automatically whenever a new release is indicated, and all output files can also be tagged as desired.
Every file generated in this automatic flow is, by definition, in sync. In our example, the RTL design, the verification tests, the C/C++ headers and validation tests, and the end user documentation are all generated based on the same input specifications. This process is repeated every time that any change is made in the specifications. When any development team pulls all the files for a particular release from the version control system, they know that they are all consistent.
A Final Word
SoC developers know that they have a big challenge on their hands when it comes to the sheer number of files to be managed throughout a project. The powerful combination of state-of-the-art specification automation and a well proven version control system is unbeatable. Our team at Agnisys has a great deal of experience in helping our users set up and succeed with such a flow. Please contact us and let us help you with your next big project!