Mission-critical design may be the future for the SoC world

Toyota’s recent travails have stimulated discussion lately about the risks of having unsupervised software in control of a system that can do harm. The Toyota issue was whether engine-control software could cause unintended acceleration. But similar questions have been asked about other automotive systems such as ABS, and about medical systems ranging from radiation-therapy equipment to implanted pacemaker/defibrillators to robotic surgeons. There has even been angst about a computer-driven securities trading system running amok, as has apparently already happened a few times.

These are not new problems. the aerospace industry faced them decades ago, when airframe designers for missiles and combat aircraft began producing dynamically unstable designs in the pursuit of performance. They had to rely on flight-control software to keep the vehicles in the air and in one piece. There were some unfortunate incidents.

That industry’s eventual response was a formal approach to requiring best practices, quantifying the progress of verification, and demanding an exhaustive regimen of reporting to ensure compliance. Mandatory programs such as DO-178B for software or DO-254—intended for full systems but in fact only enforced today for FPGAs and ASICs—became an expensive fact of life for folks who make stuff fly.

Now, design teams outside the aerospace industry are beginning to look at these disciplines, if not for adoption—they can be ruinously expensive by non-military standards—at least for emulation. "The medical equipment industry has been looking at certification ever since the problems with the Therac 25, 25 years ago," says Nat Hillary, field applications engineer for LDRA Software Technology. "But the result from the FDA was only a set of ad-hoc guidelines, with no specific metrics or mandatory steps." LDRA vice president of business development John Greenland adds that in the auto industry, already deeply into drive-by-wire, there is interest in the aerospace experience, but no move toward industry-wide standards. "Automotive is where the aerospace industry was ten or fifteen years ago," Greenland opines.

Nor is interest in such methodologies likely to stop at the boundary of mission-critical systems. Today, the failure of a product due to design errors can be as lethal to a company as a speeding car might be to its driver. The level of pain a design team is willing to endure to make sure that an SoC and its associated software function in the customer’s system may be nearly as great as the pain aerospace contractors endure to avoid airliner crashes.

DO-178B is both rigorous and independently monitored. "It’s not just a set of metrics, but a process," Hillary says. When a team is working on a mission-critical design, an FAA representative must approve the design process. Then throughout the program the designers generate documentation that proves compliance with the approved process. Among other things, DO-178B enforces a list of allowable code constructs, and requires rigor in moving from high-level code to implementation. For example, the mandate requires verifiers to prove that there are no branches in the object code that don’t explicitly exist in the source code. And it requires 100 percent code coverage in verification, as well as coverage of every possible path out of decision blocks. Vendors like LDRA provide analysis tools to assess the source code and direct the verification efforts, helping to automate what otherwise can be an enormous manual process resting on the discipline of lots of individuals.

Another key facet of DO-178B is traceability. Every byte of object code must be traceable back to the source code line that generated it, and to the statement in the requirements definition for which the line of source code was written. This allows quality-assurance teams to answer vital questions such as "why is this code here?" and "have we tested the code that implements this requirement yet?" LDRA tools also support the creation of traceability.

Not everything in DO-178B makes sense for a hardware design. Intuitively, Verilog or VHDL could play the role of source code, but the analogy breaks down quickly. "At the execution level hardware and software are very different," Greenland laments. "Chips are inherently parallel." And so there is a quite different procedure, DO-254, for mission-critical FPGAs and ASICs.

DO-254 also demands strict traceability. And it was while working with a customer on a DO-254-goverend project that Mentor Graphics recognized the need for a generalized traceability tool, according to Mentor program manager Pete Decher. "We found that most teams were still tracking traceability manually, and it was costing on average 25 person-hours for every 1000 requirements," Decher says. Mentor’s answer is ReqTracer.

ReqTracer starts by assisting in identifying, isolating, and tagging individual requirements. These can be as detailed as the need for a controller to generate an acknowledge pulse of a certain length within a certain time after it recognizes its address, for example. So the number of individual requirements in a large system can be huge. The task requires ReqTracer to read text documents, Microsoft Office files, and data from other systems such as IBM’s DOORS. ReqTracer then allows users to include the appropriate tags when they generate design data: high-level designs in C/C++, SystemC or Matlab, or implementation code in Verilog or VHDL. As the design team creates and refines the design, the tags go in. Significantly, the verification team can also tag items in the test bench to identify which requirements each module is to verify.

With the tags in place, design teams can analyze such issues as the completeness of the code set and the presence of orphaned code. They can drive the verification process based on coverage of the requirements, rather then an arbitrary approximation like code coverage. And they have a powerful tool for estimating the impact of ECOs: not by formally evaluation dependencies, but by projecting the dependencies identified in the requirements document through the design data to the implementation.

All by themselves the abilities to do requirements-driven verification and to estimate the implications of ECOs might justify the cost and overhead of a tool like ReqTracer. But in the larger context of a necessary move towards mission-critical design methodology—just to get enormously complex SoCs out the door—tools such as Mentor’s ReqTracer and LDRA’s DO-178B-support take on a different level of appeal.