Traceability Is Not My Problem (Is It?)

What is all the fuss about traceability? If it is that important, should it be handled by a compliance group? Delegating to a separate team would be the preference for most design and verification team members, but it is not possible in this case. Traceability stops short of a big brother organization constantly looking over the shoulders of the development team. The more reasonable approach is to fold traceability needs into regular design and verification methodologies, supported by using automation to its utmost.

Another argument against traceability might be that the organization’s customers are not mandating support. Or that those customers only demand simple evidence of requirements compliance. Regardless, markets centered on safety, such as automotive, aerospace and medical, expect the traceability requirements to be a must-have. A final reason against traceability might be that the problem has been blown out of proportion. This article shares some examples to counter that wishful pushback. Traceability is everyone’s problem.

The path traceability must track, from system requirements to validation.

Design families, parameterization and requirements

Following a successful system-on-chip (SoC) product release, a next logical step is to extend the product family. This could be an ASIL B version for automotive headlights, an ASIL D version for critical safety systems such as anti-lock brakes, and maybe a low-power version with less safety emphasis for satellite applications. Reuse is essential to keeping development costs down and launching quickly in all three markets. An obvious tactic is to parameterize design RTL to spin local optimizations for each objective while still sharing design and verification improvements across the bulk of the design common to all three options.

The automotive specifications above need safety mitigations through parity, error-correcting code (ECC), and other tricks. The ASIL D application must support lock-step computing in critical logic with redundant CPUs and associated comparators. Meanwhile, the low-power version needs power islands and retention logic. These specialized needs can be cleverly crafted into the RTL to respond to top-level conditional compile switches.

However, each implementation must also comply with a set of customer requirements that are indifferent to clever reuse tactics. One customer specified a 32-bit interface on an IP. Another expects higher traffic through that IP and wants a 64-bit interface. Since these customers are in different markets, the design team also figures out how to fold in these conditional configuration options. As more choices emerge, compile options become messier as things evolve from the simple original set. More possibilities create more opportunities for inconsistencies that may not be caught in verification. The real impact of a mistake in an option setting for a key customer may not appear until software testing on silicon samples.

Critical subsystems with multiple owners

A safety island, monitoring and controlling application IPs.

An SoC supplier and the system builder may share some level of architecture ownership in certain subsystems. A safety island, for example, is designed to support ASIL D certification for an automotive subsystem. This must control in-flight diagnostic testing for critical IPs within the SoC. The safety island isolates an IP, launches diagnostic testing, then brings the IP back online if the test passes or takes remedial measures to deal with failure. Tier 1s or OEMs, not the SoC builder, determine what any corrective measures should be. To manage these objectives, system builders need input to architecture decisions – adding control and status registers (CSRs), for example.

While some system needs will be clear initially, others may emerge only during system prototype testing when the SoC design is already well underway. Those conditions drive late-stage specification changes that can slip through the cracks, among other issues the SoC team must manage. Verification will not necessarily catch this class of problem where the specification changes.

Bridging the disconnects between requirements and implementation

There are many other possible oversights in memory maps and IP register maps, power management options, tie-off configuration options, etc. Even the best-managed design team may not catch every disconnect between requirement and implementation among product and customer variants and design and specification evolution.

These problems are significantly mitigated with SoC design-aware traceability. It connects from system-level to architecture-derived requirements to what the team implemented in RTL and testing to validate the specification. It is much easier for a designer or verifier to see inconsistencies when examining a piece of RTL or a test together with the related requirement. This value holds even if the issue may not be easily testable. The development team’s insight into system-level needs may be enough to raise a red flag.

Conversely, sometimes constraints in design choices may force a change to a requirement. This is not necessarily fatal. The system design team may be able to adapt if the architects know about the change early enough. Bidirectional traceability is essential to enabling this level of communication between the SoC supplier and the system builder.

Traceability affects everyone in SoC design and verification. But it does not need to be painful overhead. It can be a real aid in avoiding late-stage crises and rework and an excellent tool to build confidence with customers. Want to learn more? Check out the Harmony Trace product.