D0-254 Coding Checks For RTL Code - NMI · PDF fileVHDL) design best practice coding ... In...

Graeme Jessiman

D0-254 Coding Checks For RTL Code

European Applications Engineer

May 2016

Email: [email protected] Tel: 01635 811446

www.mentor.com © 2015 Mentor Graphics Corp. Company Confidential

Agenda

2

Background to the D0-254 RuleSet

Rule Categories

Automated Linting

Considerations For Tool Assessment


D0-254 : Requirements for Coding Standards

3

RTCA/DO-254 provides design assurance guidance for airborne electronic hardware.

— The goal of DO-254 is to ensure that airborne electronic hardware (AEH) works reliably as specified, avoiding faulty operation and potential functional hazards.

— DO-254 discusses the need for “Design Standards” and FAA Order 8110.105 takes this a step further, discussing the specific need for HDL coding standards.

FAA Order 8110.105 section 6-2a clarified that HDL coding standards should be defined and checked when it stated:

— “To prevent potentially unsafe attributes of HDLs from leading to unsafe features of the 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.”

D0-254 Coding Checks For RTL Code, NMI : May 2016


History Of DO-254 Coding Standard Proposal

4

2009: — NA D0-254 User Group asked Mentor’s D0-254 Program Manager

to propose a design checking ruleset for VHDL coding

— Ruleset was presented and a survey was generated to solicit feedback for additions and modification from NA & European participants

— Significant Reviewers

– Individuals who did a thorough review, provided feedback, and in most cases did a second or even third review.

— Group Reviewers

– Individuals who were presented with a copy of the paper and participated in at least one group review that was held within the DO-254 user group meetings:



History Of DO-254 Coding Standard Proposal

5

Significant Reviewers

Additional Participants

− Airbus − Thales Airborne Computer Systems − Honeywell Aerospace Electronic Systems − Patmos Engineering Services − SystiQ − Saab − Aeroconseil

− Rockwell Collins − Mentor Graphics − Barco Avionics − MTU Engines − Hamilton Sundstrand

− Actel − Astronautics − BAe Systems − Boeing − ENEA − Rolls Royce − Altera

− ChipX − Sagem Avionics − Xilinx − Purple Seal Inc



Positioning Paper

6

D0-254 User Group Positioning Paper published in 2010

− The aim of the paper was to provide a list of generally accepted HDL (specifically VHDL) design best practice coding guidelines that should be considered for a fail-safe design, including DO-254 programs.

− These coding guidelines should NOT be

viewed as what must be done in a DO-254 program.

o What must be done is always the decision of the applicant in conjunction with the certification authority.

o However, if a project team is looking for a good foundational set of checks to assess the HDL design quality for their DO-254 program, this document provides that foundation.



Rule Categories

7

Following 4 Rule Categories Were Proposed

— Coding Practices [14 Rules CP1 – CP14]

– This set of rules ensures that a coding style supporting safety-critical and good digital design practices are used.

— Safe Synthesis [21 Rules SS1-SS21]

– This set of rules ensure that a proper netlist is created by the synthesis tool.

— Code Reviews [13 rules DR1 – DR13]

– This set of rules are checked to make design reviews and code comprehension easier.

— Clock Domain Crossings [1 Rule CDC1]

– This rule addresses potential hazards with designs containing multiple clock zones and asynchronous clock zone transitions.



Rule Severities & Controls

8

Severity Level — Each coding rule has a default severity level of Error, Warning, or

Note, which provides a measure of the worst case impact a standard violation can have on safety.

— In general

– Errors should always be corrected – Warnings should usually be corrected but may have documented and

justified exceptions – Notes should simply be examined to ensure there is no impact on safe design

operation.

User Controls — The rules and severity levels should be potentially editable by the project

team, depending on the design assurance level assigned to the design as well as the project team’s own coding style and preferences.



Automated Rule Checking

9

In DO-254 programs, HDL coding standards must be documented, and any project code must be reviewed to ensure it follows these standards.

While reviews can be done manually, an automated approach (when possible) guarantees a more consistent HDL code quality assessment.

Automating the HDL code assessment process, often called linting, has the added benefit of promoting regular HDL design checking steps throughout the design development process, as opposed to waiting for gating design reviews where issues can be overwhelming and more costly to address.

The positioning paper also discussed automation when appropriate, and stated that a combination of automation and manual reviews can lead to best results.



Expectation For End Users

10

Using The RuleSet

— These standards (or rules) can be used as-is by companies who don’t have their own standards and are seeking guidance.

— Likewise this rule set can also be modified and augmented by companies wanting to do more or different types of checks.

Mentor D0-254 Rulset

— Mentor created a D0-254 ruleset for Design Checker (part of HDL Designer)

— We added additional rules for Verilog code – 4 additional Coding practise rules (CP15-CP18) – 3 additional Safe Synthesis rules (SS22-SS24)



Agenda

11


Rule Categories

Automated Linting



Coding Practice (CP) Rules

12

Avoid Incorrect VHDL Type Usage (CP1) — Check for the incorrect use of types, incompatible bounds, and/or

constraints.

Avoid Duplicate Signal Assignments (CP2) — The same signal should not be assigned a value more than once within

the same statement region.

Avoid Hard-Coded Numeric Values (CP3) — For design IP reuse and portability ease, hard-coded numeric values

should not be used.

Avoid Hard-Coded Vector Assignment (CP4) — For vector reset assignments; do not use hard-coded values.

Ensure Consistent FSM State Encoding Style (CP5) — A design should employ a consistent state encoding style for Finite State

Machines (FSM). — FSM state types should not be hard-coded, unless unavoidable.

Red : Error Orange : Warning Green : Note



Coding Practice (CP) Rule Examples

13

Avoid Hard-Coded Numeric Values (CP3)

— Constants or generics should be used and documented within the design. This will greatly reduce the probability of a design error from creeping into the design code as it is being ported to a new application.

— Default severity: Warning

Ensure Consistent FSM State Encoding Style (CP5)

— Inconsistent FSM encoding style may interfere with the design’s FSM error detection and recovery scheme. Enumerated state types make HDL code more readable generally. Enumerated types facilitate more flexibility in the synthesis implementation as users can select the encoding style used (one-hot, gray, binary etc.) without modifying the HDL code. These aspects support greater design portability and support FSM error detection and recovery.

— Default severity: Error




14

Ensure Safe FSM Transitions (CP6) — An FSM should have a defined reset state. — All unused (illegal or undefined) states should transition to a defined

recovery state, where this error condition can be processed accordingly. — There should be no unreachable states (i.e., those without any incoming

transitions) and dead-end states (i.e., those without any outgoing transitions) in a FSM.

Avoid Mismatching Ranges (CP7) — Bit widths on both sides of an assignment, comparison, or association

should match.

Ensure Complete Sensitivity List (CP8) — The sensitivity list should only contain the signals needed by the process.





15

Ensure Proper Sub-Program Body (CP9) — Each sub-program must:

a) have only one exit point b) have no recursion c) access only local variables/signals

Assign Value Before Using (CP10) — Every object (e.g. signal, variable, port) should be assigned a value

before using it.

Avoid Unconnected Input Ports (CP11) — All Input ports should be driven.

Avoid Unconnected Output Ports (CP12) — Design output ports should be connected.

Declare Objects Before Use (CP13) — Objects should be declared before use.

Avoid Unused Declarations (CP14) — All declared objects should be used.




Coding Practice (CP) Rule Examples

16

Ensure Proper Sub-Program Body (CP9)

— Each sub-program must : a) Have only 1 exit point b) Have no recursion c) Access only local variables

— In some cases, if the code is intentionally designed this way (such as a recursive sub-program), its justification should be documented.


Avoid Unused Declarations (CP14) — Check for objects that have been

declared, but are never used (i.e., read from or assigned to). Unused declared objects are considered dead code. Dead code can be detrimental when a design is reused. The dead code could be inadvertently activated during the code base port.




Coding Practice (CP) Rules [Additional Rules Added By Mentor]

17

Assignment Style – Combinatorial Blocks Inferring Latches (CP15, Verilog Only) — Verilog non-blocking assignment operator should be used for

combinational block coding style with inferred latches.

Assignment Style – Pure Combinatorial Blocks (CP16, Verilog Only) — Verilog blocking assignment operator should be used for pure

combinational block.

Assignment Style – Sequential Blocks (CP17, Verilog Only) — Verilog non-blocking assignment operator should be used for sequential

block.

Mixed Variable Assignments (CP18, Verilog Only) — Do not use both blocking and non-blocking Verilog assignments for the

same variable.




Safe Synthesis (SS) Rules

18

Avoid Implied Logic (SS1) — Do not allow coding that implies feed-throughs, delay chains, and

internal tri-state drivers.

Ensure Proper Case Statement Specification (SS2) — Case statements should:

a) Be complete b) Never have duplicate/overlapping statements c) Never have unreachable case items d) Always include the “when others” clause .

Avoid Combinational Feedback (SS3) — Do not allow combinational feedback paths.

Avoid Latch Inference (SS4) — The HDL coding style should avoid inference of latches.

Avoid Multiple Waveforms (SS5) — Only one waveform should exist on the right-hand side of a signal assignment.




Safe Synthesis (SS) Rule Examples

19

Avoid Implied Logic (SS1) — Certain coding styles that are

dependent on implied synthesis constructs can be dangerous. This implied logic might prevent the design code base from being synthesized in a consistent manner across

different device technologies. — Default severity: Warning

Avoid Multiple Waveforms (SS5) — A waveform consists of an assignment

value expression and an optional assignment delay expression. Multiple waveforms are non-synthesizable. With multiple waveforms, synthesized hardware behavior will not match simulation.

— Default severity: Error




20

Avoid Multiple Drivers (SS6) — The same signal/variable should be assigned in only one sequential

block.

Avoid Uninitialized VHDL Deferred Constants (SS7) — Ensure all VHDL deferred constants are initialized.

Avoid Clock Used As Data (SS8) — Clock signals should not be used in a logic path that drives the data input

of a register.

Avoid Shared Clock & Reset Signal (SS9) — The same signal should not be used as both a clock and reset signal.

Avoid Gated Clocks (SS10) — Data signals should not be used in a logic path that drives the clock input of a

register.

Avoid Internally Generated Clocks (SS11) — Internally generated clocks should be avoided.





21

Avoid Internally Generated Resets (SS12) — Unless they are properly isolated, internally-generated resets should be

avoided.

Avoid Mixed Polarity Reset (SS13) — The same reset signal should not be used with mixed styles or polarities..

Avoid Unresettable Registers (SS14) — All registers should have a reset control

Avoid Asynchronous Reset Release (SS15) — Reset signals should have a synchronous release

Avoid Initialization Assignments (SS16) — Do not use register initialization assignments..

Avoid Undriven and Unused Logic (SS17) — a. Every register and latch must be used and driven in the design. — b. Registers and latches affecting only unused logic must be examined.





22

Ensure Register Controllability (SS18) — Each register should be controllable from its inputs.

Avoid Snake Paths (SS19) — Combinational paths should not exceed a maximum allowable logic depth

Ensure Nesting Limits (SS20) — Conditional branching constructs should have a maximum nesting depth

Ensure Consistent Vector Order (SS21) — Use the same multi-bit vector order consistently throughout the design


SS18 Example SS20 Example



Safe Synthesis (SS) Rules [Additional Rules Added By Mentor]

23

Asynchronous Block (SS22, Verilog Only) — Verilog asynchronous always blocks should not contain more than one

sequential statement or constructs other than IF-ELSE

Continuous Assignments (SS24, Verilog Only) — Avoid using Verilog procedural continuous assignments

Unsynthesizable Event Controls (SS24, Verilog Only) — Do not use unsynthesizable Verilog event control constructs.




Design Review (DR) Rules

24

Use Statement Labels (DR1) — Case statements, Processes, Always Blocks & End constructs should have

labels.

Avoid Mixed Case Naming for Differentiation (DR2) — Names should not be differentiated by case alone..

Ensure Unique Name Spaces (DR3) — The same name should not be used for different types of identifiers.

Use Separate Declaration Style (DR4) — Each declaration should be placed on a separate line

Use Separate Statement Style (DR5) — Each statement should be placed on a separate line.

Ensure Consistent Indentation (DR6) — Code should be consistently indented

Avoid Using Tabs (DR7) — Tabs should not be used (for portability across editing environments)





25

Avoid Large Design Files (DR8) — Designs should be partitioned and files should be of limited size.

Ensure Consistent Signal Names Across Hierarchy (DR9) — Signals and busses should have consistent names when they span the

design hierarchy

Ensure Consistent File Header (DR10) — Ensure a consistent file header.

Use Sufficient Comment Density (DR11) — Code should be sufficiently documented via inline comments — The amount of design code in-line commenting should allow a different

designer to be able to understand the design well enough to be able to modify it for a different project in a reasonable amount of time

Ensure Proper Placement Of Comments (DR12) — Comments should be placed in appropriate places to aid understanding





26

Ensure Company Specific Naming Standards (DR13) — Each company or project should establish and enforce its own naming

standards.

These standards will vary from company to company, or even project to project, and therefore cannot be explicitly included in a generic set of DO-254 coding standards. — The sorts of things to consider in each companies HDL coding standards include: — Enforcing specific filename matching with associated entity — Enforcing specific object type naming convention, with a prefix or postfix appended to the

object name. For example: a) signals use “_s” b) registers use “_r” c) constants use “_c” d) processes use “_p” e) off-chip inputs use “_I” f) on-chip inputs use “_i” g) off-chip outputs use “_O” h) on-chip outputs use “_o” i) etc.




Clock Domain Crossing (CDC) Rules

27

Analyze Multiple Asynchronous Clocsk (CDC1) — Any time a design has multiple asynchronous clocks, or if internally-

generated clocks are allowed, a thorough clock domain crossing (CDC) analysis should be done..

“This design guidance needs to be mentioned, even though clock domain crossing issues and analysis is beyond the scope of typical HDL linting tools and beyond the scope of this document”

As part of the design review process, all digital designs should be reviewed for potential clock domain crossing boundaries, and, when found, analyzed to verify that they are properly addressed by a synchronizer circuit.

For those interested in learning more about clock domain crossing issues and analysis techniques, refer to:

2008 FAA SW and AEH presentation “Mitigating the Dangers of Multi-Clock Designs” (available here: http://www.mentor.com/products/fpga/do-254/upload/multi-clock-designs.pdf )

“Automating Clock-Domain Crossing Verification for DO-254 (and other Safety-Critical) Designs” a whitepaper developed by Mentor Graphics (available here: http://www.mentor.com/products/fpga/do-254/techpubs )



Agenda

28


Rule Categories

Automated Linting



Benefits Of Automated Linting

29

No testbench required. − Find issues ahead of simulation/integration

Automation brings to the design checking process a standard metric for finding coding violations and weighing violation severities, based on an organization’s digital design coding guidelines.

By leveraging tool automation capability, this can dramatically reduce the

large man-hour labour cost from manual design code reviews For large, complex designs, it is nearly impossible to guarantee a consistent

and error free design checking process based on manual code reviews. Machine based checking guided by an organization’s design standards ensures a consistent result, even as designs grow in size



DesignChecker Rule Configuration

D0-254 Coding Checks For RTL Code, NMI : May 2016 30

130 Parameterizable Base Rules

Base Rule Categories

1. Drag Drop Rules Into RuleSets

3. Configure rule parameters

2. Drag Drop Rulesets Into Policies

4. Toggle Rule On/Off

Each rule assigned a score & weight


DesignChecker Interactive Results


1. Result Categories

2. Code Snippet for violation

3. Quality Score

4. Schematic violation debug coming in 2016


DesignChecker Reporting


Comprehensive data available from DesignChecker

— GUI and API

Formal statement of Checker run/results for audit

Enhancements to Report — Which rules are enabled in Policy/Ruleset — Which files have Rule/Pragma exclusions — Which files are flagged as Black-Box,

Don’tTouch — Which instances/components are unbound — Justification stored for

exclusions/exceptions


Use Model For Automated Linting

33

Build & customize the rule set − Add, remove and modify rules to suit company/project “style” standards

Check during design − Clean up code blocks prior to integration into the larger design

Check at integration − Run checks again each time design code integration into a higher level

Check reused code − check the quality of the previously-written code against the organization’s design coding

standards − The key is simply ensuring reused code does not violate any of the most critical/serious

checks, and/or that any violations are examined to ensure they will not have any safety impact. For these cases, a subset of the full coding standards can be used to verify the quality of the reused code

Check during regressions − Run in batch and extract metrics for trending − lines of code, quality score, number of violations, etc

In order to get maximum use out of automated standards checking, it should be used as early and often as possible.



Agenda

34


Rule Categories

Automated Linting




35

Checking of HDL code against a set of standards via a review would be considered a verification activity in DO-254. Therefore, if credit was taken for this activity via an automated tool, the tool used would have to go through tool assessment.

The preferred method would be to conduct a basic tool qualification, as defined by DO254 (section 11.4).

o This could consist of a document identifying the standards to be checked, along with a set

of test cases, including both good and bad code for each standard.

o This could be run by the applicant to demonstrate that the tool is indeed performing the standards checking correctly.

o If the set of standards the tool is checking is modified in any way, the set of tests run to demonstrate correct results would have to change accordingly.

o Using this approach, credit taken for the automated code review activity should be assured.

o Note that because this is not a “functional” verification activity (in other words, the tool checking HDL coding standards is not verifying that the design implementation meets its intended function as per requirements), this approach should be sufficient.



Summary

36

Defining and checking HDL coding standards is a best practice that is generally accepted and employed by many companies today. It is also a requirement imposed by DO-254.

In order to assist with this compliance objective, a “best practice” set of foundational standards was presented in the positioning paper.

− These standards (or rules) can be used as-is by companies who don’t have their own standards and are seeking guidance.

− Likewise this rule set can also be modified and augmented by companies wanting to do more or different types of checks.

Using a tool to automate the checking of these coding standards is common practice. While automated checking cannot fully replace manual code reviews, it can improve the efficiency of the design review process – helping meet compliance objectives more effectively.


D0-254 Coding Checks For RTL Code - NMI · PDF fileVHDL) design best practice coding ... In...

Documents

Transcript of D0-254 Coding Checks For RTL Code - NMI · PDF fileVHDL) design best practice coding ... In...