DO-254 is the state-of-the-art standard guiding the development of airborne hardware. The document defines a hardware design lifecycle with guidance on the activities and work products expected within each phase of the lifecycle.
One such activity is the definition of hardware design standards. DO-254 lists out types of designs standards but stops short of specifying specific rules. The intent of this post is to shed some light on the expectations as it pertains to hardware design standards. This post is scoped to programs designing complex custom micro-coded components in HDL (Verilog, System Verilog, and VHDL).
What DO-254 Requires
Section 10.2.2 introduces the concept of hardware design standards and defines it as the “rules, procedures, methods, guidance, and criteria” in the development of a hardware design. The FAA recognized this and released Order 8110.105A which indicates the requirement for HDL coding standards. The order calls this out as a requirement for DAL A/B, and it is considered best practice for all designs Specifically, section 6-2a of the order stated:
“To prevent potentially unsafe attributes of HDLs from leading to unsafe features of theFAA Order 8110.105A
components, we must expect that, if they use an HDL, applicants define the coding
standards for this language consistent with the system safety objectives, and establish
conformance to those standards by HDL code reviews.”
HDL coding standards must be documented and code reviewed to ensure the standards are followed. The plan of record regarding the establishment and adherence to hardware design standards should be discussed and approved by the appropriate certification authority.
While the order provides clarity around the need for HDL coding standards, it does leave a lot of room for interpretation. The languages themselves offer a lot of flexibility resulting in multiple coding styles that can result in the same HW circuit. As you may guess, this guidance often results in the fundamental question: “What is a good set of design standards for HDL?”
What Siemens EDA offers
Siemens, in collaboration with both United States and European DO-254 user group representatives, defined a set of coding guidelines as a foundation to assess HDL design quality within a DO-254 program. While Siemens (formerly Mentor Graphics) was the first to implement these standards into an earlier linting tool, Siemens has recently implemented the DO-254 ruleset into our next generation Questa Lint solution. This built-in ruleset provides customers a launch point in the assessment of HDL design quality, leveraging the experience of industry practitioners,
Fundamentally, the checks within the ruleset serve several essential purposes:
- Catching design problems in HDL code that may not surface later in the lifecycle and which may not be detected using other verification activities.
- Support error detection, containment, and recovery mechanisms.
- Enforcing style and readability to improve code comprehension, portability, and reviews.
The rules are categorized into three types:
- Coding Practices (CP)
- Safe Synthesis (SS)
- Design Review (DR)
Figure-1 below provides a small sampling of the types of checks implemented within Questa Lint and the associated tie back to the rule type (category).
The HDL coding rules within the table above have severities ranging from Note -> Warning -> Error.
If you are interested in learning more about this capability, please refer to the Questa Lint product page or reach out to your account manager.