Design, Verification, and Software Development Decisions Require a Single Source of Truth

You may have heard the phrase “single source of truth” sometimes abbreviated as “SSOT”—in the computing world. Although it was coined more than 60 years ago, it’s still used today. For today’s post, I’d like to briefly talk about the SSOT concept and then consider why it’s relevant for IP and system-on-chip (SoC) development. 

The SSOT Concept

The main concept of SSOT is that information is structured in an architecture where all data is edited in a single master location. In one variation, master data can be copied locally in read-only form, but local copies cannot be written. All writes (edits) are made to the master location, with any local copies of the edited data either invalidated or updated to match the master. In this sense, the SSOT approach works much like a write-through cache. 

There are also variations in which local copies can be written, and the master data is updated at some later point. This is much like a write-back cache, and it faces the same issues of how to prevent other accessors from reading stale master data and how to reconcile concurrent updates in multiple local copies. There are numerous other issues to be addressed in the SSOT implementation. Fortunately, most of them aren’t relevant to the way I’m using the term in this post.

The SSOT Specification

When I use SSOT in the context of our specification automation solution, I mean that there’s a single master source for the IP or chip specifications. I’m borrowing the main concept of SSOT, but not worrying about the messy details of local copies, how updates are made, and so forth. Since electronic specifications are online documents they can be managed by a version/revision control system, just like any other types of files.

The key attribute of SSOT specifications is that there is only one specification—or one set of non-overlapping specifications—for any IP or SoC project. Different project teams cannot maintain their own, independent specifications. With this rule, there is no issue with different teams having specifications that are inconsistent due to differing interpretations of what the project should be or because of simple human error.

Specifications are updated many times over the course of a project for many reasons. If updates are made independently to disconnected specifications, there is a very high risk of misinterpretation, more errors, and wider divergence across teams. With an SSOT specification, all updates are made in one place so there’s no chance of divergence. As with the cache analogies I made earlier, if there is a way to make local updates they must be reflected in the master copy, the SSOT.

SSOT and Specification Automation

At Agnisys, we rely on the methodology of specification automation. This entails having as many specifications as possible be executable so that as many files required by the project teams as possible are generated automatically by our tools. All the generated files are consistent and correct by design, and there’s no risk of misinterpretation or differing interpretations. Of course, automation saves the project teams a lot of work since they don’t have to write those files by hand.

Whenever a specification is updated, the team simply reruns the generation process to update all files for all project teams. This ensures that the teams always remain in sync and saves more project resources for every iteration. Our customers report that they save many weeks, or even many months, on their projects by using our solution and the specification automation process. The savings grow every time that any specification is updated.

We frequently refer to our executable specifications as “golden” specifications, which is another way to say SSOT. There’s only one master copy, everyone works from it, everyone updates this copy, and our tools generate a multitude of consistent design, verification, software, validation, and documentation files from it automatically. As I said earlier, SSOT specifications can be managed by version control systems just like any other important design file.

SSOT and You

The bottom line is that you don’t need to do anything special to adopt SSOT for your next IP or SoC project. You just need to have proper control over your golden specifications, and you must maintain good discipline, such as never hand-editing files that we generate automatically since those updates would be lost when the specification changes. By following these simple rules and using our IDesignSpec™ Suite of specification automation tools, you have achieved SSOT.