It’s all in the details of FPGA requirements management

Word association: if I said “requirements management”, you’d probably say IBM Rational “DOORS,” or maybe Serena or Polarion if you come from the IT world. But what if the requirements you need to manage are for an FPGA or ASIC, with HDL and testbench code and waveform files and more details backing verification, and compliance to safety-critical standards is needed?

System requirements are fine in DOORS, but much more detail is needed for traceability into the internals of an FPGA or ASIC. In the context of DO-254, requirements have to be driven down through design and implementation into verification results.

It’s not that DOORS can’t do this job. DOORS has extensive customization capability and could, at least in theory, be extended to provide the level of detail. That effort is not for the faint of heart however, and it would be a significant time drain spent customizing a tool instead of doing actual work. (As I always say, 10 engineers can do anything – once.) A better scenario would be to use a tool built for the job of managing FPGA requirements – and able to import and export information to DOORS.

Aldec has entered this picture with Spec-TRACER, a new tool integrating a requirements management client with the existing capabilities of Active-HDL. An administration center and a report manager form a complete solution. The administration center is a set of fairly common functions for collaborative development: set up and manage repositories and projects, create and manage user identities, groups, and rights, and create and manage baselines. The report manager is template driven, allowing customization for corporate reporting standards.

The core capability of Spec-TRACER is the ability to correlate requirements to HDL source code. The first step of the process is capturing requirements, and developers can either enter them directly or import them from DOORS, Excel, or Word, and modify them as necessary within the Spec-TRACER client. Multiple versions of requirements can be tracked and examined, along with the change history.

A given FPGA requirement can be traced to the HDL code and test scenarios, and then to test results. Tags can be dragged and dropped, and are not project specific which allows the HDL design to be reused. This leads into impact analysis capability, which shows exactly which project elements are impacted if a requirement is changed. There is also a review workflow, so requirements and test results can be viewed and approved.

Multi-directional traceability is important, especially when design changes start to take effect as a project unfolds. Downstream traceability is important, showing requirements that are not covered, making it easier for designers to see what remains to be implemented or tested. Upstream traceability spots requirements that don’t trace back to a parent requirement, which is a key element in safety-critical analysis to ensure nothing superfluous exists which can cause unanticipated behaviors.

If you happen to be at @50thDAC in Austin, you may want to register for a live, in-person technical session by Aldec to get more insight. To reserve your seat, pre-register for Session 3: Requirements Traceability for Safety-Critical FPGA/ASIC Designs.

lang: en_US