This action might not be possible to undo. Are you sure you want to continue?
design practices are used. Each rule that follows is given a coding practice (CP) has following number for ease of reference.
Clock Domain Crossing (CDC):
This set of standards addresses potential hazards with designs containing multiple clock zones and asynchronous clock zone transitions. 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.
Static Timing Analysis (STA):
Static Timing Analysis is a method for determining if a circuit meets timing constraints without having to simulate. STA approach typically takes a fraction of the time it takes to run logic simulation on a large design and guarantees 100% coverage of all true timing paths in the design without having to generate test vectors.
The following standards are checked to ensure a proper netlist is created by the synthesis tool.
Synthesis optimization algorithms are geared towards synchronous designs. Unexpected synthesis gate level output can occur if the design is extremely asynchronous.
Design Reviews (DR):
The following standards are checked to make design reviews and code comprehension easier i.e. should be source level Transparent, Verifiable, maintainable and readable and include those attributes of the software that facilitates the understanding of the software by project personnel.
entity ff is port ( clk : in std_logic.5) Should have a formal syntax and be amenable to static analysis 1.q" => violation.ff_1. end architecture.ff_0. end entity. Do not use flip-flop output as a clock(Rationale 1& 2) Problem Description Do not use a flip-flop output as a clock . Example · Flip-flop "div_4.q" output is used as data for the flip-flop "div_4.avoid internally generated clocks as much as possible unless they are isolated properly. . begin process (clk) begin if (clk'event and clk = '1') then q <= not q. ff_output <= q. end process.all. end if.std_logic_1164. Use IEEE. ff_output : out std_logic ). library IEEE. architecture arch_ff of ff is signal q: std_logic.
allowed.allowed. enable. and async. enable . enable logic of multiplexers and tristates.alllowed. Do not connect clocks to anything other than flip-flop clock pins.allowed. sync. (Rationale 1& 2) A clock signal should not be connected to latches. Global clock(s) connections are verified throughout the design: flip-flop clock pin: ♦ flip-flop: data. clock . and flip-flop pins other than clock pin. Such descriptions infer internally generated clocks that are not recommended. data inputs .2.not allowed.not allowed.not allowed. . and async. ♦ tri-state: enable . controls . Example 1 • The global clock signal "clk" is connected to the select input of the multiplexer => violation. ♦ multiplexer: select . Controls . ♦ latch: data sync. data .not allowed.
Do not use combinatorial logic in reset lines(Rationale 1& 2) Problem Description Combinatorial logic in a reset line may generate hazardous reset signal. 4.3. Do not use the same signal as clock and reset (Rationale 1& 2) Problem Description Do not use the same signal both as a clock and reset. . Clock-reset mixing is very hazardous practice that should be avoided as much as possible. If combinatorial logic is really needed in the reset line it is recommended to explicitly group it explicitly in the hierarchically separated design unit (create the reset generator instance). • both as clock and reset (details point to the appropriate flip-flops pins). Example • combinatorial logic is present on the reset line of "output" flip-flop => violation. Example . Avoid internally generated resets and use the global resets only to feed the flip-flop asynchronous control pins.
The "FF_VECTOR. Declarations Correct usage of VHDL data types 5.output" flip-flop and clock pin of "FF_VECTOR.clk" signal is connected both to reset pin of "FF_VECTOR. 6. Use the 'std_logic_1164' standard package whenever it is possible.output" flipflop => violation.std_logic_1164" whenever it is possible. It is recommended to use "ieee. Do not use unsafe data types inside architecture(Rationale 4 & 5) Problem Description .high_ff. Example 1 • The entity "FDCPE" doesn't use the standard package "std_logic_1164" => violation.low_ff. (Rationale 4 & 5) Problem Description The 'std_logic' and 'std_logic_vector' are standard types that are required for RTL design.
Example • Range specification is missing in the signal "shift" declaration => violation. Range specification is required in 'integer' object declarations. Specify range for objects of 'integer' data type(Rationale 2 & 4) Problem Description If range is not specified explicitly. • Note: there is another checker with stricter requirements for entity data types 7. . 'unsigned’. This may block simulation-time 'x'-es propagation. 'Boolean'. an object of 'integer' data type is treated as 32-bit value and this may lead to redundant circuit generation in certain cases. 8. Example • The forbidden "bit_vector" datatype is used for the internal "data" signal => violation. Example • The forbidden type "bit" is used in the "and_4" entity port map => violation.Data types used inside architecture are not subject for such strict rules as an interface port data types.’ signed' and user-defined data types based on these types. The 'std_logic' and 'std_logic_vector' data types should be used instead to ensure that related bugs are not missed. The only exception to this rule is generic clause. Only the following types above the 'std_logic' are safe though: 'integer'. Do not use the 'bit' data type (Rationale 4 & 5) Problem Description Objects of the 'bit' and 'bit_vector' data types can be assigned only with '1' and '0'.
Example • The 'enum_encoding' attribute is specified for the "FSM_states" type => violation. Use named connections to explicitly show bindings between ports and signals. The probability to make a mistake is much higher when relying on ordered connections. Specify range for interface objects of 'std_logic_vector' data type. Range specification is always required in port and generic declarations of 'std_logic_vector' data type. Do not use the 'enum_encoding' attribute for enumerations(Rationale 4) Problem Description The 'enum_encoding' attribute is used to define the encoding scheme of a state machine in the design. Racing conditions Hazardous clock connections 12. Example 1 • Ordered port connection is used in the component "u_and_2" port map => violation. Match bit widths of relational operator arguments(Rationale 4) Problem Description . Do not use this attribute to prevent the particular logic synthesis. an object of 'std_logic_vector' data type is treated as unconstrained value and this may lead to mismatches between the RTL and postsynthesis simulation.9. 11. 13. . Do not use ordered port connections(Rationale 4 & 5) Problem Description Ordered port connections should not be used in component instantiations. Example • Unconstrained 'std_logic_vector' data type is used for entity "mux" ports => violation. Example • The clock signal "clk" is connected to the flip-flop "count(0)" data input => violation. This approach helps to prevent racing issues. (Rationale 4 & 5) Problem Description If range is not specified explicitly. 10. Do not use a clock signal as a data(Rationale 2 & 4) Problem Description A clock signal should not be used as a data.
Do not read global signals in a function body(Rationale 4). 16. So do not use a signal within the same process statement it was assigned. 14. This approach prevents differences between the results of RTL and postsynthesis simulation.resulting circuit may not operate as . Example • Ports "operand1" and "operand2" with mismatching bit width are used as operands of relational operator =>violation. Do not use a signal within the same process statement it was assigned(Rationale 2 & 4) Problem Description A code that contains a signal assigned and referenced within the same process statement is inefficient in simulation. .Bit widths of relational operator arguments should match clearly. Example • The signal "data" is read but not included in the sensitivity list => violation. A function that reads a global signal does not operate when this signal changes .it is not needed in the sensitivity list => violation. Also the readability of such code is reduced. 17. Define all the necessary signals in the sensitivity list of a combinatorial in process (Rationale 4) Problem Description A sensitivity list should include all the signals that are referenced within a combinatorial process. Redundant objects may result in unexpected process executions during the simulation. Do not define unnecessary objects in the sensitivity list of a combinatorial process (Rationale 4) Problem Description A sensitivity list should not include any unnecessary objects. 15. NOTE: Variables are not considered. Example 1 • The "sel" is both assigned and referenced within the same process => violation. Problem Description Global signals should not be used within a function body. Example • The signal "q" is an intermediate signal -. This approach prevents important mistakes (incorrect conditional branch may be executed).
. and/or constraints. Example • The function "comparision" contains return statement in the conditional branch => violation. Function should not return in conditional branches(Rationale 4) Problem Description Do not define function return value under control of conditional branches . While these types of issues are usually caught during compilation. Unconnected input ports can cause the associated circuit blocks to exhibit nondeterministic functional behavior in hardware. Problem Description Do not define a function return value anywhere else than at the end of the function body .it is recommended to use intermediate variable to calculate the results and return this variable.such descriptions are hazardous . it is beneficial to correct the problem as early as possible. Example • The function "func_shift" refers to the global signal "shl_or_shr " => violation.expected. Also do not place any statements after the return . 19.use intermediate variable to calculate the results and define function return value at the end on the function body. All signals that are used within a function body should be input arguments of this function. 2. Example: 21. Design reviews . Avoid Unconnected Input Ports(Rationale 2 & 4) Problem Description Input ports and bidirectional ports should be connected and not left floating. varying with changes in voltage-rails and operating conditions. Example 1 • The function "comparision" does contain a 'return' statement => violation. Unsafe return value description 18.they won't be executed. A function should return at the end of its body(Rationale 4). incompatible bounds. 20. Avoid incorrect VHDL type usage(Rationale 4) Problem Description Check for the incorrect use of types.
labels etc. signals use “_s” b. Problem Description The same signal names should not be described using both upper case and lower case English letters. are distinguished signals which may cause a problem (e. These standards will vary from company to company. Namespaces 1. with a prefix or postfix appended to the object name.the same approach is recommended for other statements. Consideration should be give to naming conventions for clocks. and therefore cannot be explicitly included in a generic set of DO-254 coding standards. FSM State Variables. For example: a. However. such signals are recognized as different. or even project to project. 3. constants use “_c” d. Abc and abc).g. Choose only one of these two methods (prefix vs. signals. Multiple statements in one line make description hard to read and understand. generics. Do not describe same objects using both upper and lower letter case Rationale 4). variables. Example • The input signal "Read_Addr" is referred to as "read_addr" (first letters are not capitalized) => violation. ports or parameters • Enforcing specific filename matching with associated entity • Enforcing specific object type naming convention. 2. resets.The following standards are checked to make design reviews and code comprehension easier. The sorts of things to consider include: • Having the component have the same name as the associated entity • Ensuring name association between formal and actual generics. they should be considered and included in each company’s HDL coding standards. Ensure company specific Naming standards (Rationale 4) Each company or project should establish and enforce its own naming standards. processes use “_p” . postfix labels) and consistently apply it through out the entire design. English letters in upper and lower case are not distinguished in VHDL but in many systems at subsequent stages. It is even advised to avoid having similar names for the signals in different visibility regions. registers use “_r” c. Do not describe multiple statements in one line (Rationale 4) Problem Description Each assignment should be located in a separate line . constants. registers.
Example • The multiple waveform is assigned to the "data_out" signal => violation. Multiple waveforms (VHDL only) 1. simple assignments only should be used in RTL description. Safe synthesis The following standards are checked to ensure a proper net list is created by the synthesis tool. 3. off-chip inputs use “_I” f. on-chip outputs use “_o” i. off-chip outputs use “_O” h.e. Do not use multiple waveform and optional delay expression in assignments (Rationale 2 & 4) Problem Description Multiple waveforms are not synthesizable and should not be used. . on-chip inputs use “_i” g. etc.
Problem Description The 'others' choice should always be added. Unreachable conditions are prone to mistakes and usually are the source of further confusion. Example • Branches with "x < y" and "x > y" conditions are not reachable => violation. This approach prevents the situation when nothing is executed and ensures optimal synthesis results. Do not describe unreachable conditions(Rationale 4) Problem Description Code that will never be executed should be removed from description. Example • The 'others' choice is missing in the case statement => violation.Conditional statement Case overlapping and completeness 2. . Case statement should always have 'others' choice. General issues 1.
Race conditions Combinatorial feedback 4. Example • Combinational feedback is detected (feedback propagation chain is as following: "q_back" -> "nq_back" ->"q_back") => violation.Implied logic Allowed implied logic 3. They cause number of problems .including racing conditions and problems with timing analysis. . Tri-state buffers should be inserted to correctly communicate with the 'inout' ports. Do not connect in out directly to input or output (Rationale 4) Problem Description Direct connections of inout to input or output ports imply generation of paths that have not been described in the RTL. Example • The "data_left" inout port is directly connected to the "output_data_right" output port => violation. Do not use combinatorial feedbacks(Rationale 2 & 4) Problem Description Combinatorial feedbacks should be avoided as much as possible in the design.
This approach prevents generation of unintentional circuit and improves readability of the description. .Registers inference Hazardous blocks 5. Example 1 • Process contains two sequential case statements => violation.there is a number of problems related to such descriptions. Do not describe multiple independent conditions in the process (Rationale 4) Problem Description Do not describe multiple independent conditions in the process .
Otherwise unwanted latches are inferred to retain signal value under certain condition(s). Problem Description Each signal must be defined under all the possible conditions in combinatorial process description. Example • The "data_out" signal is assigned only when "enable" signal is equal to '1' whereas its value should be retained when it is equal to '0' => violation. .Latches 6. Avoid latches as much as possible(Rationale 2 and 4).
This design guidance needs to be mentioned. Clock Domains. when found. . a thorough clock domain crossing (CDC) analysis should be done. which can have serious adverse affects on a device’s operation. or if internally-generated clocks are allowed. Figure. and Mean Time between Failure Calculations As part of the design review process.Clock Domain Crossing (CDC) This set of standards addresses potential hazards with designs containing multiple clocks Zones and asynchronous clock zone transitions. even though clock domain crossing issues and analysis is beyond the scope of typical HDL linting tools. analyzed to verify that they are properly addressed by a synchronizer circuit. Metastability. Improper clock domain crossings result in metastability or indeterminate circuit operation. This challenging design . Analyze Multiple Asynchronous Clocks Any time a design has multiple asynchronous clocks. and. all digital designs should be reviewed for potential clock domain crossing boundaries.
but it will occur during infield (i. reliability problems (if tri-state line remains undriven) and requirement for an analog simulator (for timing simulation of distributed tristate busses). It is often impossible to consistently duplicate these CDC-error induced behaviors in hardware for design debug. transistor junction temperature. voltage rails and ground bounce.. The ‘after’ must only be used in test bench for modeling purpose. in-flight) operating conditions given the right set of environmental factors for the targeted system application. requirements are: _ clearly structured layout _ One hot encoded enable signal _ Bus keeper circuits SEU(Single Event Upset) State Machines can be developed to tolerate SEU's or detect SEU's depending upon the overhead required. If needed use older versions (for instance from CVS. circuit elements are affected by the operating conditions. If still using it. While use of a one hot state machine and calculating the odd parity of the state register will enable the detection of SEU occurrence allowing appropriate action to be taken.methodology should be identified due to the extreme difficulties associated with isolating and debugging the intermittent CDC-error-induced functional behavior at the hardware level.e. a CDC error might not exhibit itself during normal testing conditions. Inactive Code Do not leave code lines commented. . Increasing the hamming distance between states and defining adjacent states can result in a SEU immune state machine. Some Other Coding Practices: Internal Tri-State Generally. avoid internal tri-state signals. such as loading. In a worst case scenario. Making this situation worse. Any inactive or wrong code has to be deleted. They introduce increased power consumption. SVN) for comparison Keyword After For synthesizable code do not use ‘after’ to symbolize delay: sum<=a+b after 5 ns.
REFERENCES a.opencores. Document RTCA/DO-254 c. FAA AC 20-152.105 d.fpga-design-solutions. EASA Certification Memos and CRIs on recent programs (non public material) e. www. www. RTCA/DO-254 (EUROCAE ED-80). www. b.com . Design Assurance Guidance For Airborne Electronic Hardware. FAA Order 8110.org i.mentor. RTCA. Inc.aldec.com f.com g. www..
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue reading from where you left off, or restart the preview.