If your engineering organization is still pushing requirements, design specifications, and test plans around on paper, you’re not alone. It’s remarkable in this day and age, given the sophistication of our hardware design flows which enable us to create extraordinarily complex and large designs, that requirements are largely decoupled from actual design implementation and verification. Perhaps we shouldn’t be surprised given the frantic pace of design completion at the backend of each design. Who has time to automate the front-end? Unfortunately, the cause of much of the frantic activities in the back-end can be traced to mistakes made when synchronizing requirements with what was actually built and verified.

The idea behind requirements traceability is simple: associate each design requirement with the implementation (examples: VHDL or Verilog Code segment, module, entity, synthesis tool output, etc). Next, associate each requirement with a verification result, such as coverage, assertion, or monitor output. Now, when any one of the three items change (requirement, implementation, or verification result), analyze and report the dependencies.

Of course, it’s not quite as easy as it sounds, when you consider the fact that even the most disciplined organizations maintain requirements in a multitude of sources, including requirements databases, documents containing derived spec and spread sheets with test plans. In addition, implementation data is spread across a litany of tools and verification results come in many flavors. Trying to manage that over thousands of requirements is excruciating.

Imagine the joy in being able to automatically assess the actual impact of a proposed change in requirements, or perhaps the relief in knowing all the requirements that depend on a piece of hardware you are planning to change? Best of all, simply knowing the status of completion relative to the design requirements and specs should provide greater confidence in the overall design.

Well, fortunately, the industry that has zero tolerance for design mistakes have instigated a solution; specifically, the people who implement airborne and aerospace electronics have defined standards and driven tool development that automates requirements management. And, as it is often the case, design processes in every market segment can benefit from the results of these major investments in requirements management technology for safety-critical design.

The software community blazed the trail with DO-158, the FAA standard that inspires requirements traceability in the software design flow. Soon thereafter, DO-254 was invented to define high reliability processes for safety critical design.

Now today, commercial tools are emerging that assimilate and unify requirements from dissimilar sources, and then automatically trace them into implementation and verification.

Figure 1. Examples of a “non-verified implementation” (top) vs. a “verified implementation” (bottom).

Requirements capture and tracing are critical to the DO-245 initiative since documents and processes used for requirements are audited closely for certification. Since many companies use tools to identify, record and manage this process, the DO-254 standard addresses hierarchical, high-level and derived document (developed from the hardware development process). Thus, all system requirements implemented in hardware are documented, and safety requirements related to the hardware are documented. In addition, design constraints are identified, such as standards and technology processes. Other documentation data may include the deriving requirements, design tolerances and feedback on requirement changes and additions during the product development process.

Content for Conceptual Design, such as high-level flowcharts, diagrams, finite state machine bubble diagrams, or spreadsheets, are documented. This includes high-level descriptions of the hardware, third-party intellectual property (IP), component or test features that are identified upfront, whether they will actually be used, or not.

Next, Detailed Design processes and requirements are captured. Examples include the actual writing of the HDL code for the design; the design of important test features and, architectures; assessment of safety issues and design constraints.

Then, at Implementation – where the detailed design data is used to produce the hardware device, assembly and installation – the DO-254 standard requires documentation of parts procurement, instruction on building and programming the device, assembly, inspection and test.

The Product Transition process takes the completed hardware implementation, and the verification process into production and manufacturing. At this stage, preparing and checking manufacturing data and associated requirements, such as manufacturing for safety and testing, are captured.

Support processes for DO-254 refer to guidance on the validation of hardware requirements; the verification of hardware implementation as it relates to design requirements; configuration management; process assurance, such as product lifecycle; and product certification for both the company and certification representatives.

The end result is a new methodology that can help any design team reduce errors, improve efficiency and get to market sooner.