Agnisys

  Recently, I wrote the blog post “ Design, Verification, and Software Development Decisions Require a Single Source of Truth ” and published it on our site. I pointed out how this 60-year-old term is highly relevant for our specification automation solutions for IP and system-on-chip (SoC) development. In today’s post, I’m exploring some of the issues that arise when you use a single source of truth (SSOT) on your project and show how you can make it easier with Agnisys Collaboration Framework. An SSOT Refresher In case it’s been a while since you read my previous post, let me remind you that SSOT is based on an information architecture in which all data is edited in a single master location. There may be local copies for better performance, but all writes propagate to the master. In our world, SSOT refers to the master source for your IP or chip specifications. All the design, verification, software, validation, and documentation files that we automatically generate use this sing...

  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 t...