FreescaleVerilog

Verilog HDL Coding Semiconductor Reuse Standard IPMXDSRSHDL0001 SRS V3.2 SRS V3.2 01 FEB 20052 © Freescale Semiconductor, Inc. 2005 Freescale reserves the right to make changes without further notice to any products herein to improve reliability, function or design. Freescale does not assume any liability arising out of the application or use of any product or circuit described herein; neither does it convey any license under its patent rights nor the rights of others. Freescale products are not designed, intended, or authorized for use as components in systems intended for surgical implant into the body, or other applications intended to support or sustain life, or for any other application in which the failure of the Freescale product could create a situation where personal injury or death may occur. Should Buyer purchase or use Freescale products for any such unintended or unauthorized application, Buyer shall indemnify and hold Freescale and its officers, employees, subsidiaries, affiliates, and distributors harmless against all claims, costs, damages, and expenses, and reasonable attorney fees arising out of, directly or indirectly, any claim of personal injury or death associated with such unintended or unauthorized use, even if such claim alleges that Freescale was negligent regarding the design or manufacture of the part. Freescale and and the stylized Freescale logo are registered trademarks of Freescale Semiconductor, Inc. Freescale Semiconductor, Inc. is an Equal Opportunity/Affirmative Action Employer. Freescale Semiconductor Revision History Version Number Date Author Summary of Changes 1.0 29 JAN 1999 SoCDT Original 1.1 08 MAR 1999 SoCDT Revision based on SRS development process. Detailed history contained in DWG records. 2.0 06 DEC 1999 SoCDT Revision based on SRS development process. Detailed history contained in DWG records. 3.0 30 APR 2001 SoC-IP Design Systems Change summary location: http://socdt.sps.mot.com/ddts/ddts_main 3.0.1 01 DEC 2001 SoC&IP Edit 3.0.2 15 MAR 2002 SoC&IP Changed from MCP to MIUO; Changed Motorola font batwing to batwing gif. 3.1 1 NOV 2002 SoC&IP Changed to reflect changes to SRS V3.1. 3.1.1 1 APR 2003 SoC&IP Changed to reflect changes to SRS V3.1.1; added eight new paragraph tags 3.2 01 FEB 2005 DEO Added updates for SRS V3.2. Semiconductor Reuse Standard Table of Contents Section 7 Verilog HDL Coding 7.1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13 7.1.1 Deliverables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13 7.2 Reference Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14 7.2.1 Referenced Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14 7.2.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14 7.3 Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15 7.3.1 File Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15 7.3.2 Naming of HDL Code Items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15 7.4 Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19 7.4.1 File Headers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19 7.4.2 Additional Construct Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21 7.4.3 Other Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22 7.5 Code Style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23 7.6 Module Partitioning and Reusability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 7.7 Modeling Practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28 7.8 General Coding Techniques. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31 7.9 Standards for Structured Test Techniques. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37 7.10 General Standards for Synthesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .38 SRS V3.2 01 FEB 2005 3Freescale Semiconductor Semiconductor Reuse Standard SRS V3.2 01 FEB 20054 Freescale Semiconductor Semiconductor Reuse Standard List of Figures Figure 7-1 Verilog File Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20 Figure 7-2 Verilog Functions, User-Defined Primitives and Tasks Header. . . . . . . . . . . . . .21 Figure 7-3 Verilog Coding Format (Page 1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25 Figure 7-4 Verilog Coding Format (Page 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 Figure 7-5 Metastability Hazard Due to a Violation of this rule . . . . . . . . . . . . . . . . . . . . . . .29 Figure 7-6 Proper Use of Synchronization Register According to this rule . . . . . . . . . . . . . .29 Figure 7-7 Scan Support for Mixed Latch/Flip-Flop Designs . . . . . . . . . . . . . . . . . . . . . . . .38 SRS V3.2 01 FEB 2005 5Freescale Semiconductor Semiconductor Reuse Standard SRS V3.2 01 FEB 20056 Freescale Semiconductor Semiconductor Reuse Standard List of Tables SRS V3.2 01 FEB 2005 7Freescale Semiconductor Semiconductor Reuse Standard SRS V3.2 01 FEB 20058 Freescale Semiconductor Semiconductor Reuse Standard Rule and Guideline Reference Introduction Reference Information Naming Conventions R 7.3.1 At most one module per file R 7.3.2 File naming conventions R 7.3.3 Separate analog, digital, and mixed-signal Verilog files R 7.3.4 HDL Code items naming convention R 7.3.5 Document abbreviations and additional naming conventions R 7.3.6 Global text macros include module name R 7.3.7 Instance naming conventions R 7.3.8 Signal naming convention - suffixes R 7.3.9 Signal naming convention - prefixes G 7.3.10 Consistent signal names throughout hierarchy R 7.3.11 Signal name length does not exceed 32 characters Comments R 7.4.1 Each file must contain a file header with required fields R 7.4.2 Additional constructs in file use a header with required fields R 7.4.3 Comment conventions Code Style R 7.5.1 Write code in a tabular format G 7.5.2 Use consistent code indentation with spaces R 7.5.3 One Verilog statement per line R 7.5.4 One port declaration per line G 7.5.5 Preserve port order R 7.5.6 Declare internal nets G 7.5.7 Line length not to exceed 80 characters Module Partitioning and Reusability R 7.6.1 No accesses to nets and variables outside the scope of a module G 7.6.2 The use of ‘include compiler directives should be avoided R 7.6.3 Mask plugs outside of top most module R 7.6.4 Avoid potentially non-portable constructs G 7.6.5 Partitioning conventions - general G 7.6.6 Partitioning conventions - clocks Modeling Practices R 7.7.1 No hard-coded global distribution nets R 7.7.2 Synchronize asynchronous interface signals R 7.7.3 Use technology independent code for noninferred blocks SRS V3.2 01 FEB 2005 9Freescale Semiconductor Semiconductor Reuse Standard R 7.7.4 Glitch-free gated clock enables and direct action signals R 7.7.5 Known state of powered down signals R 7.7.6 Initialize control storage elements G 7.7.7 Initialize datapath storage elements G 7.7.8 Use synchronous design practices R 7.7.9 No combinational feedback loops General Coding Techniques R 7.8.1 Expression in condition must be a 1-bit value R 7.8.2 Use consistent ordering of bus bits R 7.8.3 Do not assign x value to signals R 7.8.4 No reg assign in two always constructs G 7.8.5 Use parameters instead of text macros for symbolic constants R 7.8.6 Text macros must not be redefined G 7.8.7 Preserve relationships between constants R 7.8.8 Use parameters for state encodings G 7.8.9 ‘define usage includes ‘undef R 7.8.10 Use programmable base addresses R 7.8.11 Use text macros for base addresses R 7.8.12 Use base + offset for address generation G 7.8.13 Use symbolic constants for register field values G 7.8.14 Limit ‘ifdef nesting to three levels G 7.8.15 Use text macros for signal hierarchy paths R 7.8.16 Macromodules are not allowed R 7.8.17 Operand sizes must match R 7.8.18 Connect ports by name in module instantiations R 7.8.19 Ranges match for vector port and net/variable declarations R 7.8.20 Port connection widths must match G 7.8.21 Avoid ports of type inout G 7.8.22 Use parentheses in complex equations G 7.8.23 No disables on named blocks or tasks containing nonblocking assignments with delays G 7.8.24 Use task guards G 7.8.25 Next-state encoding of state machines should be made through the use of case statements R 7.8.26 No internal three-state logic G 7.8.27 Avoid three-state outputs R 7.8.28 Replication multiplier must be greater than zero Standards for Structured Test Techniques R 7.9.1 Use additional logic for scanning high-impedance devices R 7.9.2 Allow PLL bypass G 7.9.3 Allow clock divider bypass R 7.9.4 Scan support logic for gated clocks R 7.9.5 Externally control asynchronous reset of storage elements R 7.9.6 Latches transparent during scan R 7.9.7 No simultaneous master/slave latch clocking G 7.9.8 Segregate opposing phase clocks SRS V3.2 01 FEB 200510 Freescale Semiconductor Semiconductor Reuse Standard General Standards for Synthesis R 7.10.1 Complete always sensitivity list R 7.10.2 One clock per always sensitivity list R 7.10.3 Only use synthesizable constructs R 7.10.4 Specify combinational logic completely G 7.10.5 Assign default values to outputs before case statements G 7.10.6 Avoid full_case synthesis directive R 7.10.7 No disable in looping constructs R 7.10.8 Avoid unbounded loops R 7.10.9 Expressions are not allowed in port connections G 7.10.10 Avoid top-level glue logic R 7.10.11 Verilog primitives are prohibited R 7.10.12 Use nonblocking assignments when inferring flip-flops and latches R 7.10.13 Drive all unused module inputs G 7.10.14 Connect unused module outputs R 7.10.15 Do not infer latches in functions R 7.10.16 Use of casex is not allowed R 7.10.17 Embedded synthesis scripts are not allowed G 7.10.18 Use a cycle-wide enable signal for signals with multicycle paths G 7.10.19 Model high-impedance devices explicitly G 7.10.20 Avoid direct instantiation of standard library cells SRS V3.2 01 FEB 2005 11Freescale Semiconductor Semiconductor Reuse Standard SRS V3.2 01 FEB 200512 Freescale Semiconductor Semiconductor Reuse Standard Section 7 Verilog HDL Coding 7.1 Introduction The Verilog HDL coding standards pertain to virtual component (VC) generation and deal with naming conventions, documentation of the code and the format, or style, of the code. Conformity to these standards simplifies reuse by describing insight that is absent from the code, making the code more readable and as- suring compatibility with most tools. Any exceptions to the rules specified in this standard, except as not- ed, must be justified and documented. The standards promote reuse by ensuring a high adaptability among applications. The intent of this docu- ment is to ensure that the gate level implementation is identical to the HDL code as it is understood by a standard Verilog simulator. Partitioning can affect the ease that a model can be adapted to an application. The modeling practices section deals with structures that are typically difficult to address well in a synthe- sis environment and are needed to ensure pre- and post-synthesis consistency. These standards apply to behavioral as well as synthesizable code. Additionally, these standards apply to all other code written in Verilog, such as testbenches and monitors. Some of the standards explicitly state the type of code to which they apply, and exceptions to the standards are noted. The rules were determined to be items that enable rapid SoC design, integration, and production, as well as enable maintainability by someone other than the original author. Note that in many cases, a guideline may fit this definition, however, at this point it may have a large number of exceptions, tool limitations, or a deeply entrenched opposing usage which prohibited the rule designation. Note: rules and guidelines as described in V3.2 of the SRS are required for compliance only in new IP (i.e. IP coded after the release date of V3.2). But it is possible to certify older IP with V3.2 if there is no issue with the changes introduced by the new version of the standard. 7.1.1 Deliverables The deliverables to the IP repository are defined in Section 2 VC Deliverables. These deliverables include: • Synthesizable RTL Source Code (L1) • Testbench (V1) • Drivers (V2) • Monitors (V3) • Detailed Behavioral Model (V4) • HDL Interface Model (V5) • Stub Model (V6) • Emulation (V13) SRS V3.2 01 FEB 2005 13Freescale Semiconductor Semiconductor Reuse Standard 7.2 Reference Information 7.2.1 Referenced Documents [1] IEEE Verilog Hardware Description Language, IEEE Standard 1364-1995. [2] IEEE Verilog Hardware Description Language, IEEE Standard 1364-2001, Version C. [3] Verilog-AMS Language Reference Manual, Version 2.2. November 2004, Accellera http://www.eda.org/verilog-ams/htmlpages/public-docs/lrm/2.2/AMS-LRM-2-2.pdf [4] SystemVerilog 3.1a Language Reference Manual, Accellera’s Extensions to Verilog, Accellera, May 2004. http://www.eda.org/sv/SystemVerilog_3.1a.pdf 7.2.2 Terminology Base address - An address in the allocated address space of the SoC to which offsets are added to enable access registers. Deliverables - VC deliverables are a set of files that make up a design. They are provided by the virtual component creator. Deliverables are assigned a unique identifier that consists of a letter followed by a number. A complete description of the SRS deliverables can be found in document IPMXDSRSDEL00001, Semiconductor Reuse Standard: VC Block Deliverables. Guideline - A guideline is a “recommended” practice that enhances rapid SoC design, integration, and production, reduces the need to modify IP deliverables, and increases maintainability. HDL - Hardware Description Language Mask plug - Physically a mask plug is just a wire either connected to VDD or VSS, or a choice of two inputs (hardwired switch) used to configure a module without changing anything internal to that module. This avoids resynthesis when changing the configuration. PLL - Phase-Locked Loop Properties - Properties are variables that are assigned a value. Values are unique to each VC but the prop- erty names are common to all VC blocks. Properties are also referred to as “Metadata .” Properties are also used in equations to determine if a rule is applicable to a deliverable. If the equation holds true, the rule applies to the deliverables. RTL - Register Transfer Level Rule - A rule is a “required” practice that enables rapid SoC design, integration, and production, eliminates the need to modify IP deliverables, and supports maintainability. Text macro - ‘define Top-level module - Module at the highest level of the VC design hierarchy. UDP - User-Defined Primitive VC - Virtual Component. A block in the virtual socket design environment. A pre-implemented, reusable module of intellectual property that can be quickly inserted and verified to create a single-chip system. The usage of the term VC is not an indication of compliance to the VSIA standards. SRS V3.2 01 FEB 200514 Freescale Semiconductor Semiconductor Reuse Standard 7.3 Naming Conventions 7.3.1 File Naming R 7.3.1 At most one module per file A file must contain at most one module. Reason: Simplifies design modifications. Deliverables: L1,V1,V2,V3,V4,V5,V6,V7,V13 R 7.3.2 File naming conventions The file name must be composed in the following way: [__{][_]. where: is the name of the top level module (e.g., duart.v) is the module name extension for a module under the top level module (e.g., fifo for module duart_fifo.v) indicates the file type: task file consists of tasks func file consists of functions defines file consists of text macros (see G 7.8.9) For regular synthesizable RTL source code, _ is omitted. signifies that it is a Verilog file: .v Verilog file .va Verilog-A file .vams Verilog-AMS file Reason: Simplifies understanding the design structure, and file contents. Example: spooler.v: File containing Verilog code for module spooler spooler_task.v: File containing Verilog code for tasks used by module spooler Deliverables: L1,V1,V2,V3,V4,V5,V6,V7,V13 R 7.3.3 Separate analog, digital, and mixed-signal Verilog files A file must contain either: (1) digital-only Verilog code (files with .v extension); (2) analog-only Verilog code (files with .va or .vams extension); or (3) mixed-signal Verilog code (files with .vams extension). Reason: Digital compilers may not handle analog constructs or mixed-signal constructs; analog compilers may not handle digital or mixed-signal constructs. Deliverables: L1,V1,V2,V3,V4,V5,V6,V7,V13 7.3.2 Naming of HDL Code Items A meaningful name very often helps more than several lines of comment. Therefore, names should be meaningful (i.e., the nature and purpose of the object it refers to should be obvious and unambiguous). The following naming conventions do not apply to third-party PLI tasks. R 7.3.4 HDL Code items naming convention These items include: nets, variables, parameters, module/primitive instances, and constructs such as functions, modules, and tasks. SRS V3.2 01 FEB 2005 15Freescale Semiconductor Semiconductor Reuse Standard a. Names must describe the purpose of the item. Items must be named according to what they do rather than how they do it. Use meaningful names. b. English must be used for all names. c. Names must start with a letter, be composed of alphanumeric characters or underscores [A-Z, a-z, 0-9,_]. d. Consecutive underscores and escaped names are not allowed. e. For names composed of several words, underscore separated words must be used. f. Consistent usage in the spelling and naming style of nets and variables must be used throughout the design. g. All signals and modules in the RTL that are referenced in the documentation must maintain the same name. h. Names representing constants must be upper case (parameters and text macros), all other names NOT representing constants must be lower case. Case must not be used to differentiate construct, net, or variable names. i. SystemVerilog, Verilog-AMS, VHDL and VHDL-AMS keywords must not be used for signals or any other user code item. Deliverables: L1,V1,V2,V3,V4,V5,V6,V7,V13 R 7.3.5 Document abbreviations and additional naming conventions Abbreviations used in a module must be documented and uncommon abbreviations should be avoided. Any naming conventions used in the module which are in addition to the conventions required or recommended in the SRS should be documented. The keyword section of the header should be used to document the abbreviations and additional naming conventions used. Alternately, the keyword section may contain the name of the file that contains these items. Document abbreviations and naming conventions in the Creation Guide as well. Reason: What may be an obvious abbreviation to the original designer could be obscure when the module is reused. Exception: Generally known abbreviations or acronyms, like}