The Elements of Traceability

By Vincent Thibaut, Arteris IP

Europe is an interesting place to observe complex systems’ development activity. It may not have hyperscalers or smartphone leaders, but on the world stage, it has one of the two dominant commercial aircraft manufacturers, an active space agency, several premium car brands and leading Tier 1s with supporting automotive semiconductor companies. Also, it has two of the biggest players in wireless infrastructure. As Israel is generally counted as a part of Europe in business terms, it adds much of the leading technology in automotive autonomy and active military engineering. This experience level gives Europe a uniquely rich perspective on the end goal for semiconductors and how interdependencies are growing closer between components and the systems served.

In addition, Europe is also known for its fondness for standards and regulations. This requires a significant amount of paperwork and cross-checks so engineers can build successful complex systems and subsystems from a diverse range of suppliers. Similar requirements are now standard around the world – DO-254, ISO 26262 and others. As component builders, teams tend to think of these standards as a list of additional things needed to be done in their specialized domain. But there is one very important aspect that ties across domains from the top-level system down to the lowest level components: requirements traceability. Systems engineers want to know that the requirements defined are being honored, even as hardware and software evolve through development across all the many parts in the system. Anywhere this is not true, they want immediate notification of a problem.

The Default Approach to Traceability

At the beginning of a project, the customer provides a pile of documents detailing their requirements. One way or another, engineers will have a spreadsheet of conditions, which perhaps is built by extracting key paragraphs from that pile of PDFs. Columns are added documenting who is responsible for a check and supplemented with details on how the check should be made (design review, verification assertion), current status and anything that might block approval for this item.

This is not something designers can just check once. As the design evolves, teams will make tradeoffs, fix bugs and address late-stage changes. Some of those changes may break existing requirements that can only be detected by tedious checking. Teams continue reviewing the traceability matrix and rechecking the design multiple times to ensure all components are correct. There may be some automation to support this activity, but it is still largely manual. If the team finds a problem, the reason for it must be determined. Was that a design mistake, or did a requirement change break the connection?

From Default to Automation

This tracing can get tedious pretty quickly and much more complicated if the system-on-chip (SoC) is sufficiently complex that the top-level requirements must be broken down into sub-spreadsheets. One major integrator shares that their engineering teams were screaming for a better solution. The teams were spending more time checking and updating spreadsheets than actually building and checking the design! The engineers wanted something that would automate most of the bookkeeping and let them get back to their real jobs.

A good starting point is getting requirements in platforms designed for that purpose – DOORS or Jama, for example. The next is to automate building links from those platforms to the SoC design flow, but that presents an apparent challenge. Requirements are generally written in natural language, even in these modern tools. How do architects connect from that to implementation or verification definitions in highly structured SoC design languages?

There is a two-part answer. First, the requirements care about relatively high-level characteristics: memory maps, bus widths, and intellectual property (IP) configurations. From an implementation point of view, there is no need to dive down into register-transfer level (RTL) behavior. Or perhaps more precisely, there should not be such a need. The IP-XACT standard captures most/all these characteristics, so it is the perfect representation to connect specifications to implementation. Requirements tools have a procedural interface; IP-XACT tools also have a procedural interface. Teams just need to connect them and figure out connections between the specifications and the implementation – the second part of the solution.

Automating the Tracing Step

How do engineers create links between natural language requirements and objects in the IP-XACT representation? In the software world, there are scores of papers on this topic. In the SoC world, the scope of objects to be considered is substantially more finite: things like bus widths, configuration parameters and register characteristics. Labeling is generally consistent for these objects from requirements to implementation, though not entirely, so teams must allow for some inconsistencies. Similar names are used in different contexts, where some natural language processing can help discriminate. There may still be a handful of cases demanding a designer to intervene, but it is very possible to reduce the bookkeeping load significantly.

Arteris IP already has active production-ready IP-XACT tooling and has built a great deal of experience learning the characteristics of viable traceability solutions over the years. Give us a call. We would be happy to discuss your goals.

About the Author:

Vincent Thibaut, Director, Product Strategy

Vincent, one of Magillem founders, has spent the last 13 years working with Magillem most advanced customers to build the most complete and comprehensive solution for IP Reuse around IP-XACT IEEE1685. As Chief Strategy Officer at Magillem Vincent is working on bringing the future of SoC integration tools and is an active member of IP-XACT standardization group at Accellera. His last focus has been around documentation, traceability and certification, as well as integration into system engineering.

Vincent has a master diploma in Software Engineering with a specialization in embedded systems and AI from EISTI , France