Professional Documents
Culture Documents
VHDL Standards
VHDL Standards
VHDL Standards
design practices are used. Each rule that follows is given a coding practice (CP) has following number for ease of reference.
1)
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.
2)
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.
3) Safe
Synthesis (SS):
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.
4)
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.
Flip-flop "div_4.ff_0.q" output is used as data for the flip-flop "div_4.ff_1.q" => violation. library IEEE; Use IEEE.std_logic_1164.all; entity ff is port ( clk : in std_logic; ff_output : out std_logic ); end entity; architecture arch_ff of ff is signal q: std_logic; begin process (clk) begin if (clk'event and clk = '1') then q <= not q; end if; end process; ff_output <= q; end architecture;
2. Do not connect clocks to anything other than flip-flop clock pins. (Rationale 1& 2)
A clock signal should not be connected to latches, enable logic of multiplexers and tristates, and flip-flop pins other than clock pin. Such descriptions infer internally generated clocks that are not recommended. Global clock(s) connections are verified throughout the design: flip-flop clock pin: flip-flop: data, enable, sync. and async. controls - not allowed, clock - allowed; latch: data sync. and async. Controls - not allowed, enable - alllowed; multiplexer: select - not allowed, data inputs - allowed; tri-state: enable - not allowed, data - allowed.
Example 1
The global clock signal "clk" is connected to the select input of the multiplexer => violation.
Problem Description Combinatorial logic in a reset line may generate hazardous reset signal. Avoid internally generated resets and use the global resets only to feed the flip-flop asynchronous control pins. 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). . Example combinatorial logic is present on the reset line of "output" flip-flop => violation.
4. 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. both as clock and reset (details point to the appropriate flip-flops pins). Example
The "FF_VECTOR.clk" signal is connected both to reset pin of "FF_VECTOR.low_ff.output" flip-flop and clock pin of "FF_VECTOR.high_ff.output" flipflop => violation.
Declarations
Correct usage of VHDL data types
Problem Description The 'std_logic' and 'std_logic_vector' are standard types that are required for RTL design. It is recommended to use "ieee.std_logic_1164" whenever it is possible. Example 1 The entity "FDCPE" doesn't use the standard package "std_logic_1164" => violation.
Problem Description
Data types used inside architecture are not subject for such strict rules as an interface port data types. Only the following types above the 'std_logic' are safe though: 'integer', 'Boolean', 'unsigned, signed' and user-defined data types based on these types. Example The forbidden "bit_vector" datatype is used for the internal "data" signal => violation. Note: there is another checker with stricter requirements for entity data types
Problem Description Objects of the 'bit' and 'bit_vector' data types can be assigned only with '1' and '0', This may block simulation-time 'x'-es propagation. The 'std_logic' and 'std_logic_vector' data types should be used instead to ensure that related bugs are not missed. Example The forbidden type "bit" is used in the "and_4" entity port map => violation.
10. Specify range for interface objects of 'std_logic_vector' data type. (Rationale 4 & 5)
Problem Description If range is not specified explicitly, 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. Range specification is always required in port and generic declarations of 'std_logic_vector' data type. Example Unconstrained 'std_logic_vector' data type is used for entity "mux" ports => violation.
Racing conditions
Hazardous clock connections 12. Do not use a clock signal as a data(Rationale 2 & 4)
Problem Description A clock signal should not be used as a data. This approach helps to prevent racing issues. . Example The clock signal "clk" is connected to the flip-flop "count(0)" data input => violation.
Bit widths of relational operator arguments should match clearly. This approach prevents important mistakes (incorrect conditional branch may be executed). . Example Ports "operand1" and "operand2" with mismatching bit width are used as operands of relational operator =>violation.
14. 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. This approach prevents differences between the results of RTL and postsynthesis simulation. Example The signal "data" is read but not included in the sensitivity list => violation.
15. 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. Redundant objects may result in unexpected process executions during the simulation. Example The signal "q" is an intermediate signal -- it is not needed in the sensitivity list => violation.
16. 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. Also the readability of such code is reduced. So do not use a signal within the same process statement it was assigned. 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. A function that reads a global signal does not operate when this signal changes - resulting circuit may not operate as
expected. All signals that are used within a function body should be input arguments of this function. Example The function "func_shift" refers to the global signal "shl_or_shr " => violation.
Unsafe return value description 18. A function should return at the end of its body(Rationale 4).
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. Also do not place any statements after the return - they won't be executed. Example 1 The function "comparision" does contain a 'return' statement => violation.
2. Design reviews
The following standards are checked to make design reviews and code comprehension easier.
Namespaces 1. Do not describe same objects using both upper and lower letter case Rationale 4).
Problem Description The same signal names should not be described using both upper case and lower case English letters. It is even advised to avoid having similar names for the signals in different visibility regions. English letters in upper and lower case are not distinguished in VHDL but in many systems at subsequent stages, such signals are recognized as different, are distinguished signals which may cause a problem (e.g. Abc and abc). Example The input signal "Read_Addr" is referred to as "read_addr" (first letters are not capitalized) => violation.
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.
3. Safe synthesis
The following standards are checked to ensure a proper net list is created by the synthesis tool.
Multiple waveforms (VHDL only) 1. 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, simple assignments only should be used in RTL description. Example The multiple waveform is assigned to the "data_out" signal => violation.
Conditional statement
Case overlapping and completeness 2. Case statement should always have 'others' choice.
Problem Description The 'others' choice should always be added. This approach prevents the situation when nothing is executed and ensures optimal synthesis results. Example The 'others' choice is missing in the case statement => violation.
General issues
1. Do not describe unreachable conditions(Rationale 4) Problem Description
Code that will never be executed should be removed from description. 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.
Implied logic
Allowed implied logic
Race conditions
Combinatorial feedback
4. Do not use combinatorial feedbacks(Rationale 2 & 4)
Problem Description Combinatorial feedbacks should be avoided as much as possible in the design. They cause number of problems - including racing conditions and problems with timing analysis. Example Combinational feedback is detected (feedback propagation chain is as following: "q_back" -> "nq_back" ->"q_back") => violation.
Registers inference
Hazardous blocks 5. Do not describe multiple independent conditions in the process (Rationale 4)
Problem Description Do not describe multiple independent conditions in the process - there is a number of problems related to such descriptions. This approach prevents generation of unintentional circuit and improves readability of the description. Example 1 Process contains two sequential case statements => violation.
Latches
6. Avoid latches as much as possible(Rationale 2 and 4).
Problem Description Each signal must be defined under all the possible conditions in combinatorial process description. Otherwise unwanted latches are inferred to retain signal value under certain condition(s). 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.
Figure. Clock Domains, Metastability, and Mean Time between Failure Calculations 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. This challenging design
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. It is often impossible to consistently duplicate these CDC-error induced behaviors in hardware for design debug. Making this situation worse, circuit elements are affected by the operating conditions, such as loading, transistor junction temperature, voltage rails and ground bounce. In a worst case scenario, a CDC error might not exhibit itself during normal testing conditions, but it will occur during infield (i.e., in-flight) operating conditions given the right set of environmental factors for the targeted system application.
Inactive Code
Do not leave code lines commented. Any inactive or wrong code has to be deleted. If needed use older versions (for instance from CVS, SVN) for comparison
Keyword After
For synthesizable code do not use after to symbolize delay: sum<=a+b after 5 ns; The after must only be used in test bench for modeling purpose.
REFERENCES a. RTCA/DO-254 (EUROCAE ED-80), Design Assurance Guidance For Airborne Electronic Hardware; b. FAA AC 20-152, RTCA, Inc., Document RTCA/DO-254 c. FAA Order 8110.105 d. EASA Certification Memos and CRIs on recent programs (non public material) e. www.mentor.com f. www.fpga-design-solutions.com g. www.opencores.org i. www.aldec.com