Traceability, Unfamiliar But Critical

Many understand that traceability is a popular concept. Still, understanding traceability in detail is more challenging, especially in how it connects to familiar objectives in the semiconductor design space. A simple way to understand is this: When a customer (call them C) asks a semiconductor supplier (call them S) to build a device to meet a system objective, they provide S with specifications, requirements and use-cases. S then goes off to design and build the device. C then faces a critical question: “Did S build exactly what I told them to build?” System validation cannot be exhaustive and can only provide a partial answer. C has no interest or expertise in examining register-transfer level (RTL) or universal verification methodology (UVM) files, which might provide complementary evidence, since these are disconnected from their original requirements. C wants evidence that their requirements have been met in the terms they defined because C’s system design depends critically on S having followed those requirements precisely.

The V-diagram and the gaps

System development, verification, and validation.

The V-diagram is an excellent way to understand the design lifecycle from C to S and back again. Coming down the left arm of the V, in building their system, C will define their requirements in tools like IBM DOORS or Jama Connect. An architect at S reads those requirements and elaborates into a more detailed set, leveraging their in-house technology expertise and architecture level modeling tools to optimize for power, performance, area (PPA) and other factors. That information, in turn, is handed off in readable rather than executable format to the design team, which does its magic to generate corresponding RTL.

Coming up the right arm of the V-diagram, design and verification teams generate unit tests and subsystem tests, probably in UVM, to verify correctness of implementation components. Those are followed by integration tests, quite likely in Accellera’s Portable Test and Stimulus Standard (PSS) or C/C++. These tests are intentionally developed independently of design to check against the architect’s requirements as faithfully as possible. Finally, full system validation runs emulation models, FPGA prototypes, or even early silicon through in-circuit emulations or hardware-in-the-loop testing, together with real system software.

It should be apparent that there are many gaps in automation in this flow. These gaps are steps where information is communicated from one type of designer to another. These are places where problems can creep in. A requirement might be ambiguous, misinterpreted or possibly overlooked in the heat of solving some late-stage implementation problem.

Through a year-long design lifecycle, it is not difficult for oversights to crop up. Some may not be apparent until full system validation or even later. Safety-critical domains demand proof of traceability for exactly this reason. They require that C be able to trace from a requirement down through S’s implementation and verification for evidence that these both fully meet the requirement. While it is unlikely C will want to do this for every requirement, they should be able to pick any at random and demand that walkthrough. Therefore, S must support traceability for every requirement.

Traceability to the rescue

The solution is to automate capture and maintain traceability linkages between requirements and implementation/verification. That way, a designer or verifier can quickly check in real-time that their work corresponds to the original requirement. It is possible to track traceability through spreadsheets, but that method quickly runs out of steam when there may be thousands of requirements. Tracing through a tool like Jama Connect will also work, but such tools can only make “dumb” connections to implementation and verification data since there is no understanding of the semantics of design data. The burden of developing and maintaining these links still falls on designers, with continued opportunity for human error.

Bridging the gaps with Arteris Harmony Trace.

A much more effective solution is creating and maintaining linkages through a separate tool with semantic understanding of the domains relevant to the design lifecycle: requirements, documentation, hardware assembly and hardware/software interface definition. This is what Arteris IP provides through the Harmony Trace product, a platform to maximize automation of traceability by bridging the gaps between those domains.

To learn more about how Harmony Trace makes automated traceability possible, click here.