Traceability Complements Agile Design

By Paul Graykowski, Senior Technical Marketing Manager, Arteris IP

Agile design methods have become mainstream in software development as traditional waterfall approaches cannot scale in large, fast-moving product schedules. System-on-chip (SoC) development teams have noticed and are enthusiastically adopting similar methods to accelerate schedules and become more nimble to in-process requirement changes. However, agile methods must be supported by agile verification/validation (V&V) to ensure that fast-moving development is constantly heading in the right direction. The V&V must be backed by adaptable testing and requirements validation.

^{Click to enlarge}

Figure 1. System development, verification and validation diagram

Agile in SoC Design

Product definitions and schedules today are shaped by rapidly evolving markets – automotive, communications, industrial automation, high-performance computing (HPC) and the internet of things (IoT). New product ideas are constantly chasing new possibilities, many in consumer-driven domains and often in winner-take-all markets. Multi-year product development cycles are a distant memory. Market pressures demand the transition from concept to product within a year or less, including the SoC and supporting software.

For an SoC, the software team is likely already working in an agile flow. Designers are closest to customers’ system requirements and most exposed to changes. Some of those changes will also ripple down to the SoC, such as the need for added or changed control and status registers. Although, if a requirement at the SoC level cannot meet specifications and an alternative implementation is possible, it will be sent back to the software team. Responsibility to stay in sync with requirements is distributed between software and SoC teams and even further down into IP teams.

This is a dynamic back-and-forth in requirements, exactly the kind of product evolution for which agile methods are defined. Agile provides the methodology to support dynamic requirements, but then how can software and SoC development be kept in lockstep with evolving specifications?

Keeping Development Connected to Requirements

Regression tests are an important part of validating the ongoing compliance with requirements. In Figure 1 above, the V-diagram shows that as the design evolves along the left side, testing evolves along the right side. However, regression tests cannot be the sole resource for keeping agile design on track. Tests themselves take time to develop and debug. Delivering tests may not be possible until some critical mass of functionality is available. Some requirements depend on a use-case understanding of performance which may be difficult to verify fully.

As a concrete example, consider a requirement for a flag in a status register bitfield. When the design is originally specified, the system design intent is that this flag, set by a hardware operation, will be used to inform one or more software processes that a particular step has been completed. When all requestors have been satisfied, another software function will clear the flag. Hardware design proceeds with this requirement. Later in software development, it becomes apparent that this test is in a performance-critical loop for one software requestor and that others can afford extra latency in getting this data through another path. The critical requestor needs to squeeze out all possible delays to change the hardware requirement for the bitfield. Now it must be clear-on-read, avoiding the need for a software-triggered reset and saving many cycles.

From a hardware design perspective, this is a late-stage requirement change at a very low level that could easily be missed. Implementing the change may not be difficult if recognized soon enough. This process may require extra wiring, additional logic, clock and reset changes, tweaks to power management, and rework for verification and the floorplan. The need for the change may be unavoidable, yet it cannot be lost in the noise, and the hardware consequences must be understood as soon as possible.

Testing must be complemented by the designer’s and verifier’s understanding of changes in the specification in real-time. This comprehension can be assured through automated requirements tracing. That capability is already well supported in the software domain through tools like Jama Connect and IBM DOORS. However, these tools have no native understanding of tracing in the hardware domain. These resources provide mechanisms to trace beyond software but without hardware design semantics. Using that approach requires significant effort and checking by SoC designers, undermining much of the value of tracing.

Ideally, the design and verification team would create an agile system that incorporates the best tool for the job in each component of the V-V diagram. The team then utilizes the full extent of automation to connect and trace requirements to the design, verification and validation artifacts. Requirements need to maintain traceability in near real-time so that the team can immediately detect changes and react appropriately. Best-in-class software trace tools are utilized to the maximum extent while managers check for requirement compliance across the whole product. This goes beyond software checks by entering the SoC domain without having to have the full breadth of knowledge of the SoC implementation. Arteris IP® Harmony Trace™ provides such a system of systems enabling agile methods to be extended across the entire product development process.

Is Traceability in Agile Worth the Effort?

In some domains, traceability is a requirement for compliance. However, the value in agile development flows, in general, is now a significant topic. One source has conducted research to show a clear connection between the completeness of traceability and software defect rate. In design and test, adherence to specifications is more likely if designers are regularly reminded of requirements. Additionally, studies indicate that developers complete tasks faster when guided by requirements tracing.

In summary, traceability can be an invaluable complement to agile practices in SoC development. Regression testing is important but waiting for complete and debugged tests undermines the value of agile methods. Requirements traceability bridges the gap in missing and incomplete tests and restores agility. To learn more about extending agile and traceability into SoC design using Harmony Trace, click HERE.

About the author

Paul is a senior technical marketing manager for Arteris IP with over 20 years of experience in the design and verification of systems-on-chip. Prior to Arteris, Paul specialized in Verification methodology with a focus on technologies that eventually became SystemVerilog and UVM.  Over his career, he has worked at Compaq, Intel, and Synopsys in several roles, including design consulting, product and methodology specialist, technical and product marketing, and application engineering leadership. Paul holds a BSEE from Texas A&M.

If you wish to download a copy of this white paper, click here