Why Traceability Now? Blame Custom SoC Demand

In the SoC world, we can’t believe our good luck. Every product maker now wants bespoke silicon solutions with the most advanced AI, communications, SLAM, etc. Which is fantastic for business, but this level of demand also drags us into a new level of accountability, especially in requirements traceability. Time was that only software teams had to worry about the headaches of traceability. Hardware platforms used branded devices such as microprocessors with proven track records; variability at most was in board design. However, in a scramble for functional differentiation at acceptable power and cost, product builders now demand both custom software and hardware stacks. Inevitably, traceability then crosses into hardware. Which is why SoC developers are now hearing about this topic.

A review

Traceability is a concept which mandates tracking between initial requirements and implementation as represented in logic design, verification and documentation. This method is used widely in logistics, food processing and many other domains. In electronic systems development, system builders first pushed traceability to control compliance in software development and verification, and more recently into SoC design as well. This level of tracking is active already in safety-critical automotive, aerospace and medical markets. Expect to see similar moves around security-sensitive products also.

An enforceable system must be based on structured requirements rather than unstructured natural language specifications. In support of this objective, systems designers have adopted tools like IBM DOORS and Jama Connect. Using such tools, they can describe hierarchically and concisely what they expect to satisfy their objective for the complete system. A supplier architect will typically further elaborate a subset of these requirements applicable to the supplier’s deliverable. Leveraging prior understanding of their own organization’s products and strengths. Further elaboration is possible inside subsystems.

Top-level requirements are decomposed hierarchically, concise at each level, simplifying locating and checking correspondence between a requirement and its implementation. This structure also makes it easy to isolate–if something went wrong–where and why it went wrong. Was it a problem in software, a sensor or one of multiple SoCs? Maybe there was a bug in the memory map? Requirements systems provide a system designer the means to pin down a possible cause without having to read through countless manuals written by multiple suppliers, with the imprecision of natural language. And without having to depend on appeals to trust from suppliers.

Entry-level traceability support

The simplest solution for traceability is a traceability matrix. This is typically a spreadsheet, listing one requirement per row with collateral information (e.g., related files and line numbers) in columns. Spreadsheets can be organized hierarchically and can become quite large and sophisticated.

Manual solutions like this are an obvious starting point but quickly run out of gas. Tracking 100 requirements isn’t a problem. Tracking 10,000 across multiple design, verification and documentation teams would be a huge problem without some level of semantic connection between the spreadsheet, design, test and documentation data. From system developers to SoC architects, translating higher-level requirements to lower-level requirements is a manual step; spreadsheets won’t catch mistakes at these transitions. What happens if a designer makes what seems a harmless change, without being aware of some dependency in another spreadsheet? Can the product maker see the disconnect or will they only trip over it when they run their application software and find it doesn’t work?

There isn’t an infallible answer to these questions, but there is a better answer than spreadsheets. That’s where Harmony Trace™ from Arteris IP comes in.

Professional traceability support

Clearly, a professional solution must support semantically aware connections between requirements and all aspects of the design implementation. Some of these will be derivable connections, given sufficient understanding of the design. In modern SoC design, that generally means down to the IP level. Others will require expert design understanding of system objectives. Generally, the majority will be derivable from a sufficiently structured starting point; think of memory map and register map detail as examples.

Semantically Aware SoC Traceability

These data and traceability connections should remain current as the design evolves, which requires that they should be semantically aware. Traceability can’t simply be to design files and line numbers. If an IP or an address offset changes, that detail should track automatically in traceability without need for designer updates to keep links current.

The link should be bidirectional. Requirements evolve through improved understanding or though necessary updates at the OEM level. Such changes should trickle down, automatically flagging affected design teams. Conversely, if a designer, verifier or documentation writer makes a change on an artifact within the scope of a requirement but on which the requirement is silent, perhaps the system designer should be notified anyway. Maybe that change is safe, maybe not?

There is great opportunity for SoC design organizations but that opportunity comes with more accountability. In being able to prove they built what they were told to build, down to a quite fine level of detail. Arteris IP has a solution for those design teams.