IEC 62142:2005

INTERNATIONAL IEC
STANDARD 62142
First edition
2005-06
IEEE

1364.1 ®
Verilog register transfer level synthesis

Reference number
IEC 62142(E):2005
IEEE Std. 1364.1(E):2002
Publication numbering
As from 1 January 1997 all IEC publications are issued with a designation in the
60000 series. For example, IEC 34-1 is now referred to as IEC 60034-1.

Consolidated editions
The IEC is now publishing consolidated versions of its publications. For example,
edition numbers 1.0, 1.1 and 1.2 refer, respectively, to the base publication, the
base publication incorporating amendment 1 and the base publication incorporating
amendments 1 and 2.
Further information on IEC publications
The technical content of IEC publications is kept under constant review by the IEC,
thus ensuring that the content reflects current technology. Information relating to
this publication, including its validity, is available in the IEC Catalogue of
publications (see below) in addition to new editions, amendments and corrigenda.
Information on the subjects under consideration and work in progress undertaken
by the technical committee which has prepared this publication, as well as the list
of publications issued, is also available from the following:
• IEC Web Site (www.iec.ch)
• Catalogue of IEC publications
The on-line catalogue on the IEC web site (www.iec.ch/searchpub) enables you to
search by a variety of criteria including text searches, technical committees
and date of publication. On-line information is also available on recently issued
publications, withdrawn and replaced publications, as well as corrigenda.
• IEC Just Published
This summary of recently issued publications (www.iec.ch/online_news/ justpub)
is also available by email. Please contact the Customer Service Centre (see
below) for further information.
• Customer Service Centre
If you have any questions regarding this publication or need further assistance,
please contact the Customer Service Centre:

Email: custserv@iec.ch
Tel: +41 22 919 02 11
Fax: +41 22 919 03 00
INTERNATIONAL IEC
STANDARD 62142
First edition
2005-06
IEEE

1364.1 ®
Verilog register transfer level synthesis

© IEEE 2005  Copyright - all rights reserved
IEEE is a registered trademark in the U.S. Patent & Trademark Office, owned by the Institute of Electrical and Electronics Engineers, Inc.
No part of this publication may be reproduced or utilized in any form or by any means, electronic or
mechanical, including photocopying and microfilm, without permission in writing from the publisher.
International Electrotechnical Commission, 3, rue de Varembé, PO Box 131, CH-1211 Geneva 20, Switzerland
Telephone: +41 22 919 02 11 Telefax: +41 22 919 03 00 E-mail: inmail@iec.ch Web: www.iec.ch
The Institute of Electrical and Electronics Engineers, Inc, 3 Park Avenue, New York, NY 10016-5997, USA
Telephone: +1 732 562 3800 Telefax: +1 732 562 1571 E-mail: stds-info@ieee.org Web: www.standards.ieee.org
Commission Electrotechnique Internationale
International Electrotechnical Commission
Международная Электротехническая Комиссия

– 2 – IEC 62142:2005(E)
IEEE 1364.1-2002(E)
CONTENTS
FOREWORD . 4

IEEE Introduction . 7

1. Overview. 8

1.1 Scope . 8

1.2 Compliance to this standard . 8

1.3 Terminology . 9

1.4 Conventions. 9

1.5 Contents of this standard . 9

1.6 Examples .10

2. References.10
3. Definitions.10
4. Verification methodology .11
4.1 Combinational logic verification.12
4.2 Sequential logic verification.12
5. Modeling hardware elements.13
5.1 Modeling combinational logic .13
5.2 Modeling edge-sensitive sequential logic .14
5.3 Modeling level-sensitive storage devices.17
5.4 Modeling three-state drivers.18
5.5 Support for values x and z.20
5.6 Modeling read-only memories (ROM) .20
5.7 Modeling random access memories (RAM) .22
6. Pragmas.23
6.1 Synthesis attributes.23
6.2 Compiler directives and implicit-synthesis defined macros .34
6.3 Deprecated features .35
7. Syntax .36
7.1 Lexical conventions.36
7.2 Data types.41
7.3 Expressions.46

7.4 Assignments .48
7.5 Gate and switch level modeling .49
7.6 User-defined primitives (UDPs).52
7.7 Behavioral modeling .53
7.8 Tasks and functions.59
7.9 Disabling of named blocks and tasks .62
7.10 Hierarchical structures.62
7.11 Configuring the contents of a design.68
7.12 Specify blocks .70
7.13 Timing checks .70
7.14 Backannotation using the standard delay format .70
7.15 System tasks and functions .70
Published by IEC under licence from IEEE. © 2005 IEEE. All rights reserved.

IEEE 1364.1-2002(E)
7.16 Value change dump (VCD) files.70

7.17 Compiler directives .70

7.18 PLI.71

Annex A (informative) Syntax summary .72

A.1 Source text.72
A.2 Declarations.74
A.3 Primitive instances . 79

A.4 Module and generated instantiation . 81

A.5 UDP declaration and instantiation. 82

A.6 Behavioral statements . 83
A.7 Specify section . 87
A.8 Expressions. 92
A.9 General .96
Annex B (informative) Functional mismatches.100
B.1 Non-deterministic behavior.100
B.2 Pragmas .100
B.3 Using `ifdef .101
B.4 Incomplete sensitivity list.102
B.5 Assignment statements mis-ordered.103
B.6 Flip-flop with both asynchronous reset and asynchronous set.104
B.7 Functions .104
B.8 Casex .105
B.9 Casez .105
B.10 Making x assignments.106
B.11 Assignments in variable declarations. 107
B.12 Timing delays. 107
Annex C (informative) List of Participants .108

Published by IEC under licence from IEEE. © 2005 IEEE. All rights reserved.

– 4 – IEC 62142:2005(E)
IEEE 1364.1-2002(E)
INTERNATIONAL ELECTROTECHNICAL COMMISSION

___________ ®
VERILOG REGISTER TRANSFER LEVEL SYNTHESIS

FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization
comprising all national electrotechnical committees (IEC National Committees). The object of IEC is to
promote international co-operation on all questions concerning standardization in the electrical and
electronic fields. To this end and in addition to other activities, IEC publishes International Standards,
Technical Specifications, Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter
referred to as “IEC Publication(s)”). Their preparation is entrusted to technical committees; any IEC National
Committee interested in the subject dealt with may participate in this preparatory work. International,
governmental and non-governmental organizations liaising with the IEC also participate in this preparation.
IEC collaborates closely with the International Organization for Standardization (ISO) in accordance with
conditions determined by agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an
international consensus of opinion on the relevant subjects since each technical committee has
representation from all interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence
between any IEC Publication and the corresponding national or regional publication shall be clearly
indicated in the latter.
5) IEC provides no marking procedure to indicate its approval and cannot be rendered responsible for any
equipment declared to be in conformity with an IEC Publication.
6) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.
International Standard IEC/IEEE 62142 has been processed through IEC technical
committee 93: Design automation.
The text of this standard is based on the following documents:
IEEE Std FDIS Report on voting
1364.1 (2002) 93/213/FDIS 93/218/RVD
Full information on the voting for the approval of this standard can be found in the report on

voting indicated in the above table.
®
Verilog is a registered trademark of Cadence Design Systems, Inc.
This publication has been drafted in accordance with the ISO/IEC Directives.
The committee has decided that the contents of this publication will remain unchanged
until 2007.
Published by IEC under licence from IEEE. © 2005 IEEE. All rights reserved.

IEEE 1364.1-2002(E)
IEC/IEEE Dual Logo International Standards

This Dual Logo International Standard is the result of an agreement between the IEC and the Institute of

Electrical and Electronics Engineers, Inc. (IEEE). The original IEEE Standard was submitted to the IEC for
consideration under the agreement, and the resulting IEC/IEEE Dual Logo International Standard has been

published in accordance with the ISO/IEC Directives.

IEEE Standards documents are developed within the IEEE Societies and the Standards Coordinating

Committees of the IEEE Standards Association (IEEE-SA) Standards Board. The IEEE develops its standards

through a consensus development process, approved by the American National Standards Institute, which
brings together volunteers representing varied viewpoints and interests to achieve the final product. Volunteers

are not necessarily members of the Institute and serve without compensation. While the IEEE administers the

process and establishes rules to promote fairness in the consensus development process, the IEEE does not

independently evaluate, test, or verify the accuracy of any of the information contained in its standards.
Use of an IEC/IEEE Dual Logo International Standard is wholly voluntary. The IEC and IEEE disclaim liability for
any personal injury, property or other damage, of any nature whatsoever, whether special, indirect,
consequential, or compensatory, directly or indirectly resulting from the publication, use of, or reliance upon
this, or any other IEC or IEEE Standard document.
The IEC and IEEE do not warrant or represent the accuracy or content of the material contained herein, and
expressly disclaim any express or implied warranty, including any implied warranty of merchantability or fitness
for a specific purpose, or that the use of the material contained herein is free from patent infringement.
IEC/IEEE Dual Logo International Standards documents are supplied “AS IS”.
The existence of an IEC/IEEE Dual Logo International Standard does not imply that there are no other ways to
produce, test, measure, purchase, market, or provide other goods and services related to the scope of the
IEC/IEEE Dual Logo International Standard. Furthermore, the viewpoint expressed at the time a standard is
approved and issued is subject to change brought about through developments in the state of the art and
comments received from users of the standard.
Every IEEE Standard is subjected to review at least every five years for revision or reaffirmation. When a
document is more than five years old and has not been reaffirmed, it is reasonable to conclude that its contents,
although still of some value, do not wholly reflect the present state of the art. Users are cautioned to check to
determine that they have the latest edition of any IEEE Standard.
In publishing and making this document available, the IEC and IEEE are not suggesting or rendering
professional or other services for, or on behalf of, any person or entity. Neither the IEC nor IEEE is undertaking
to perform any duty owed by any other person or entity to another. Any person utilizing this, and any other
IEC/IEEE Dual Logo International Standards or IEEE Standards document, should rely upon the advice of a
competent professional in determining the exercise of reasonable care in any given circumstances.
Interpretations – Occasionally questions may arise regarding the meaning of portions of standards as they relate
to specific applications. When the need for interpretations is brought to the attention of IEEE, the Institute will
initiate action to prepare appropriate responses. Since IEEE Standards represent a consensus of concerned
interests, it is important to ensure that any interpretation has also received the concurrence of a balance of
interests. For this reason, IEEE and the members of its societies and Standards Coordinating Committees are
not able to provide an instant response to interpretation requests except in those cases where the matter has
previously received formal consideration.
Comments for revision of IEC/IEEE Dual Logo International Standards are welcome from any interested party,
regardless of membership affiliation with the IEC or IEEE. Suggestions for changes in documents should be in
the form of a proposed change of text, together with appropriate supporting comments. Comments on standards
and requests for interpretations should be addressed to:
Secretary, IEEE-SA Standards Board, 445 Hoes Lane, P.O. Box 1331, Piscataway, NJ 08855-1331, USA and/or
General Secretary, IEC, 3, rue de Varembé, PO Box 131, 1211 Geneva 20, Switzerland.

Authorization to photocopy portions of any individual standard for internal or personal use is granted by the
Institute of Electrical and Electronics Engineers, Inc., provided that the appropriate fee is paid to Copyright
Clearance Center. To arrange for payment of licensing fee, please contact Copyright Clearance Center,
Customer Service, 222 Rosewood Drive, Danvers, MA 01923 USA; +1 978 750 8400. Permission to photocopy
portions of any individual standard for educational classroom use can also be obtained through the Copyright
Clearance Center.
NOTE – Attention is called to the possibility that implementation of this standard may require use of subject
matter covered by patent rights. By publication of this standard, no position is taken with respect to the
existence or validity of any patent rights in connection therewith. The IEEE shall not be responsible for
identifying patents for which a license may be required by an IEEE standard or for conducting inquiries into the
legal validity or scope of those patents that are brought to its attention.

Published by IEC under licence from IEEE. © 2005 IEEE. All rights reserved.

– 6 – IEC 62142:2005(E)
IEEE 1364.1-2002(E) ®
IEEE Standard for Verilog Register
Transfer Level Synthesis
Sponsor
Design Automation Standards Committee
of the
IEEE Computer Society
Approved 10 December 2002
IEEE-SA Standards Board ®
Abstract: Standard syntax and semantics for Verilog HDL-based RTL synthesis are described in
this standard. ®
Keywords: hardware description language, HDL, RTL, synthesis, Verilog

Published by IEC under licence from IEEE. © 2005 IEEE. All rights reserved.

IEEE 1364.1-2002(E)
IEEE Introduction ®
This standard describes a standard syntax and semantics for Verilog HDL-based RTL synthesis. It defines

the subset of IEEE Std 1364-2001 (Verilog HDL) that is suitable for RTL synthesis and defines the seman-

tics of that subset for the synthesis domain.

The purpose of this standard is to define a syntax and semantics that can be used in common by all compliant

RTL synthesis tools to achieve uniformity of results in a similar manner to which simulation and analysis

tools use IEEE Std 1364-2001. This will allow users of synthesis tools to produce well-defined designs
whose functional characteristics are independent of a particular synthesis implementation by making their
designs compliant with this standard.
The standard is intended for use by logic designers and electronic engineers.
Initial work on this standard started as a RTL synthesis subset working group under Open Verilog Interna-
tional (OVI). After OVI approved of the draft 1.0 with an overwhelming affirmative response, an IEEE
Project Authorization Request (PAR) was obtained in July 1998 to clear its way for IEEE standardization.
Most of the members of the original group continued to be part of the Pilot Group under P1364.1 to lead the
technical work. The active members at the time of OVI draft 1.0 publication were as follows:
J. Bhasker, Chair
Victor Berman Don Hejna Doug Smith
David Bishop Mike Quayle Yatin Trivedi
Vassilios Gerousis Ambar Sarkar Rohit Vora
An approved draft D1.4 was ready by April 1999, thanks very much to the efforts of the following task
leaders:
David Bishop (Web Admin.) Don Hejna (Syntax) Doug Smith (Pragmas)
Ken Coffman (Semantics) Yatin Trivedi (Editor)
When the working group was ready to initiate the standardization process, it was decided to postpone the
process for the following reasons:
a) The synthesis subset draft was based on Verilog IEEE Std 1364-1995.
b) A new updated Verilog language was imminent.

c) The new Verilog language contained many new synthesizable constructs.
It wasn’t until early 2001 that Verilog IEEE Std 1364-2001 was finalized. The working group restarted their
work by first looking at the synthesizability aspects of the new features in the language. Thereafter, RAM/
ROM modeling features and new attributes syntax were introduced into the draft standard.
Many individuals from many different organizations participated directly or indirectly in the standardization
process. A majority of the working group meetings were held via teleconferences with continued discussions
on the working group reflector.
Published by IEC under licence from IEEE. © 2005 IEEE. All rights reserved.

– 8 – IEC 62142:2005(E)
IEEE 1364.1-2002(E) ®
VERILOG REGISTER TRANSFER
LEVEL SYNTHESIS
1. Overview
1.1 Scope ®
This standard defines a set of modeling rules for writing Verilog HDL descriptions for synthesis. Adher-
ence to these rules guarantees the interoperability of Verilog HDL descriptions between register-transfer
level synthesis tools that comply to this standard. The standard defines how the semantics of Verilog HDL
are used, for example, to describe level- and edge-sensitive logic. It also describes the syntax of the language
with reference to what shall be supported and what shall not be supported for interoperability.
Use of this standard will enhance the portability of Verilog-HDL-based designs across synthesis tools con-
forming to this standard. In addition, it will minimize the potential for functional mismatch that may occur
between the RTL model and the synthesized netlist.
1.2 Compliance to this standard
1.2.1 Model compliance
A Verilog HDL model shall be considered compliant to this standard if the model:
a) uses only constructs described as supported or ignored in this standard, and
b) adheres to the semantics defined in this standard.
1.2.2 Tool compliance
A synthesis tool shall be considered compliant to this standard if it:
a) accepts all models that adhere to the model compliance definition in 1.2.1.
b) supports all pragmas defined in Clause 6.
c) produces a netlist model that has the same functionality as the input model based on the conform-
ance rules of Clause 4.
NOTE—A compliant synthesis tool may have more features than those required by this standard. A synthesis tool may
introduce additional guidelines for writing Verilog HDL models that may produce more efficient logic, or other mecha-
nisms for controlling how a particular description is best mapped to a particular library.
Published by IEC under licence from IEEE. © 2005 IEEE. All rights reserved.

IEEE 1364.1-2002(E)
1.3 Terminology
The word shall indicates mandatory requirements strictly to be followed in order to conform to the standard

and from which no deviation is permitted (shall equals is required to). The word should is used to indicate

that a certain course of action is preferred but not necessarily required; or that (in the negative form) a certain

course of action is deprecated but not prohibited (should equals is recommended that). The word may indi-

cates a course of action permissible within the limits of the standard (may equals is permitted).

A synthesis tool is said to accept a Verilog construct if it allows that construct to be legal input. The construct
is said to interpret the construct (or to provide an interpretation of the construct) by producing logic that rep-

resents the construct. A synthesis tool shall not be required to provide an interpretation for every construct

that it accepts, but only for those for which an interpretation is specified by this standard.
The Verilog HDL constructs in this standard are categorized as:
— Supported: RTL synthesis shall interpret and map the construct to hardware.
— Ignored: RTL synthesis shall ignore the construct and shall not map that construct to hardware.
Encountering the construct shall not cause synthesis to fail, but may cause a functional mismatch
between the RTL model and the synthesized netlist. The mechanism, if any, by which a RTL synthe-
sis notifies the user of such constructs is not defined. It is acceptable for a not supported construct to
be part of an ignored construct.
— Not supported: RTL synthesis shall not support the construct. An RTL synthesis tool shall fail upon
encountering the construct, and the failure mode shall be undefined.
1.4 Conventions
This standard uses the following conventions:
a) The body of the text of this standard uses boldface font to denote Verilog reserved words (such as
if).
b) The text of the Verilog examples and code fragments is represented in a fixed-width font.
c) Syntax text that is struck-through refers to syntax that is not supported.
d) Syntax text that is underlined refers to syntax that is ignored.
e) “<“ and “>” are used to represent text in one of several different, but specific forms.
f) Any paragraph starting with “NOTE—” is informative and not part of the standard.
g) In the PDF version of this standard, colors are used in Clause 7 and Annex A. Supported reserved
words are in red boldface font. Blue struck-through are unsupported constructs, and blue underlined
are ignored constructs.
1.5 Contents of this standard
A synopsis of the clauses and annexes is presented as a quick reference. There are seven clauses and two
annexes. All the clauses are the normative parts of this standard, while all the annexes are the informative
part of the standard.
a) Clause 1—Overview: This clause discusses the conventions used in this standard and its contents.
b) Clause 2—References: This clause contains bibliographic entries pertaining to this standard.
c) Clause 3—Definitions: This clause defines various terms used in this standard.
d) Clause 4—Verification methodology: This clause describes the guidelines for ensuring functional-
ity matches before and after synthesis.
e) Clause 5—Modeling hardware elements: This clause defines the styles for inferring special hard-
ware elements.
Published by IEC under licence from IEEE. © 2005 IEEE. All rights reserved.

– 10 – IEC 62142:2005(E)
IEEE 1364.1-2002(E)
f) Clause 6—Pragmas: This clause defines the pragmas that are part of this RTL synthesis subset.

g) Clause 7—Syntax: This clause describes the syntax of Verilog HDL supported for RTL synthesis.

h) Annex A—Syntax summary: This informative annex provides a summary of the syntax supported

for synthesis.
i) Annex B—Functional mismatches: This informative annex describes some cases where a potential

exists for functional mismatch to occur between the RTL model and the synthesized netlist.

1.6 Examples
All examples that appear in this document under “Example:” are for the sole purpose of demonstrating the

syntax and semantics of Verilog HDL for synthesis. It is not the intent of this clause to demonstrate, recom-
mend, or emphasize coding styles that are more (or less efficient) in generating synthesizable hardware. In
addition, it is not the intent of this standard to present examples that represent a compliance test suite, or a
performance benchmark, even though these examples are compliant to this standard.
2. References
This standard shall be used in conjunction with the following publication. When the following standards are
superseded by an approved revision, the revision shall apply.
™ 1, 2
IEEE Std 1364 -2001, IEEE Standard Verilog Language Reference Manual.
3. Definitions
This clause defines various terms used in this standard. Terms used within this standard, but not defined in
this clause, are assumed to be from IEEE Std 1364-2001 .
3.1 asynchronous: Data that changes value independent of the clock edge.
3.2 combinational logic: Logic that does not have any storage device, either edge-sensitive or level-
sensitive.
3.3 don’t care value: The value x when used on the right-hand side of an assignment represents a don’t care
value.
3.4 edge-sensitive storage device: Any device mapped to by a synthesis tool that is edge-sensitive to a
clock, for example, a flip-flop.
3.5 event list: Event list of an always statement.

3.6 high-impedance value: The value z represents a high-impedance value.
3.7 level-sensitive storage device: Any device mapped to by a synthesis tool that is level-sensitive to a
clock; for example, a latch.
3.8 LRM: The IEEE Standard Verilog Language Reference Manual, IEEE Std 1364-2001.
IEEE publications are available from the Institute of Electrical and Electronics Engineers, 445 Hoes Lane, P.O. Box 1331, Piscataway,
NJ 08855-1331, USA (http://standards.ieee.org/).
The IEEE standards referred to in Clause 2 are trademarks belonging to the Institute of Electrical and Electronics Engineers, Inc.
Information on references can be found in Clause 2 of this standard.
Published by IEC under licence from IEEE. © 2005 IEEE. All rights reserved.

IEEE 1364.1-2002(E)
3.9 meta-comment: A Verilog comment (//) or (/* */) that is used to provide synthesis directives to a

synthesis tool.
3.10 metalogical: A metalogical value is either an x or a z.

3.11 pragma: A generic term used to define a construct with no predefined language semantics that influ-
ences how a synthesis tool shall synthesize Verilog code into a circuit.

3.12 RHS: Right-hand side.
3.13 RTL: The register transfer level of modeling circuits in Verilog HDL.

3.14 sequential logic: Logic that includes any kind of storage device, either level-sensitive or edge-
sensitive.
3.15 statically computable expression: An expression whose value can be evaluated during compilation.
3.16 synchronous: Data that changes only on a clock edge.
3.17 synthesis tool: Any system, process, or program that interprets register transfer level Verilog HDL
source code as a description of an electronic circuit and derives a netlist description of that circuit.
3.18 timeout clause: Delays specified in an assignment statement, inter-assignment or intra-assignment.
3.19 transient delay: Propagation delay. Delays through multiple paths of logic each with its own propaga-
tion delay.
3.20 user: A person, system, process, or program that generates RTL Verilog HDL source code.
3.21 vector: A one-dimensional array.
4. Verification methodology
Synthesized results may be broadly classified as either combinational or sequential. Sequential logic has
some form of internal storage (level-sensitive storage device, register, memory) that is involved in an output
expression. Combinational logic has no such storage—the outputs are a pure function of the inputs with no
internal loops.
The process of verifying synthesis results consists of applying identical inputs to both the original model and
synthesized models and then comparing their outputs to ensure that they are equivalent. Equivalent in this

context means that a synthesis tool shall provide an unambiguous definition of equivalence for values on
input, output, and bidirectional ports. This also implies that the port list of the synthesized result must be the
same as the original model—ports cannot be added or deleted during synthesis. Since synthesis in general
does not recognize all the same delays as simulators, the outputs cannot be compared at every simulation
time step. Rather, they can only be compared at specific points, when all transient delays have settled and all
active timeout clauses have been exceeded. If the outputs match at the compared ports, the synthesis tool
shall be compliant. There is no matching requirement placed on any internal nodes unless the keep attribute
(see 6.1.4) is specified for such a node, in which case matching shall be ensured for that node.
Published by IEC under licence from IEEE. © 2005 IEEE. All rights reserved.

– 12 – IEC 62142:2005(E)
IEEE 1364.1-2002(E)
Input stimulus shall comply to the following criteria:

a) Input data does not contain “unknowns” or other metalogical values.

b) For sequential verification, input data must change far enough in advance of sensing times for tran-

sient delays to have settled.
c) Clock and/or input data transitions must be delayed until after asynchronous set/reset signals have
been released. The delay must be long enough to avoid a clock and/or data setup/hold time violation.
d) For edge-sensitive based designs, primary inputs of the design must change far enough in advance
for the edge-sensitive storage device input data to respect the setup times with respect to the active

clock edge. Also, the input data must remain stable for long enough to respect the hold times with

respect to the active clock edge.

e) For level-sensitive based designs, primary inputs of the design must change far enough in advance
for the level-sensitive storage device input data to respect the setup times. Also, the input data must
remain stable for long enough to respect the hold times.
NOTE—A synthesis tool may define metalogical values appearing on primary outputs in one model as equivalent to log-
ical values in the other model. For this reason, the input stimulus may need to reset internal storage devices to specific
logical values before the outputs of both models are compared for logical values.
4.1 Combinational logic verification
To verify a combinational logic design or part of a design, the input stimulus shall be applied first. Sufficient
time shall be provided for the design to settle, and then the outputs examined. Typically, this is done in a
loop, so the outputs may be examined just before the next set of inputs is applied, that is, when all outputs
have settled. Each iteration of the loop shall include enough delay so that the transient delays and timeout
clause delays have been exceeded. A model is not in compliance with this standard if it is possible for com-
binational outputs to never reach a steady state (i.e., oscillatory behavior).
Example 1:
always @* a = #5 ~a;
// Example is not compliant with this standard because it
// exhibits oscillatory behavior.
4.2 Sequential logic verification
The general scheme of applying inputs periodically and then checking the outputs just before the next set of
inputs is applied shall be repeated. Sequential designs are either edge-sensitive (typically consisting of edge-
sensitive storage devices) or level-sensitive (typically consisting of level-sensitive storage devices).
The verification of designs containing edge-sensitive or level-sensitive components are as follows:

a) Edge-sensitive models: The same sequence of tasks shall be performed during verification: change
the inputs, compute the results, check the outputs. However, for sequential verification these tasks
shall be synchronized with a clock. The checking portion of the verification shall be performed just
before the active clock edge. The input values may be changed after the clock edge and after suffi-
cient time has elapsed to ensure that no hold time violations will occur. The circuit then has the
entire rest of the clock period to compute the new results before they are latched at the next clock
edge. The period of the clock generated by the stimulus shall be sufficient enough to allow the input
and output signals to settle. When asynchronous data is assigned, the asynchronous data shall not
change during the period in which the asynchronous control (the condition under which the data is
assigned) is active.
Published by IEC under licence from IEEE. © 2005 IEEE. All rights reserved.

IEEE 1364.1-2002(E)
b) Level-sensitive models: These designs are generally less predictable than edge sensitive models due

to the asynchronous nature of the signal interactions. Verification of synthesized results depends on

the application. With level-sensitive storage elements, a general rule is that data inputs should be sta-

ble before enables go inactive (i.e. latch) and checking of outputs is best done after enables are inac-

tive (i.e. latched) and combinational delays have settled. A level-sensitive model in which it is

possible, in the absence of further changes to the inputs of the model, for one or more internal values
or outputs of the model never to reach a steady state (oscillatory behavior) is not in compliance with
this standard.
5. Modeling hardware elements
This clause describes styles for modeling various hardware elements such as edge-sensitive storage devices,
level-sensitive storage devices and three-state drivers.
The hardware inferences specified in this clause do not take into account any optimizations or transforma-
tions. This standard does not specify or limit optimization. A specific tool may perform optimization and not
generate the suggested hardware inferences or may generate a different set of hardware inferences. This
shall not be taken as a violation of this standard provided the synthesized netlist has the same functionality
as the input model.
5.1 Modeling combinational logic
Combinational logic shall be modeled using a continuous assignment or a net declaration assignment or an
always statement.
When using an always statement, the event list shall not contain an edge event (posedge or negedge). The
event list does not affect the synthesized netlist. However, it may be necessary to include in the event list all
the variables read in the always statement to avoid mismatches between simulation and synthesized logic.
A variable assigned in an always statement shall not be assigned using both a blocking assignment (=) and a
nonblocking assignment (<=) in the same always statement.
The event list for a combinational logic model shall not contain the reserved words posedge or negedge. Not
all variables that appear in the right hand side of an assignment are required to appear in the event list. For
example, a variable does not have to appear in the event list of an always statement if it is assigned a value
with a blocking assignment before being used in subsequent expressions within the same always statement.
The event list may be the implicit event expression list (@(*), @*).
Example 2:
always @ (in1 or in2)
out = in1 + in2;
// always statement models combinational logic.
Example 3:
always @ (posedge a or b)
// Not supported; does not model combinational logic.
...
Published by IEC under licence from IEEE. © 2005 IEEE. All rights reserved.

– 14 – IEC 62142:2005(E)
IEEE 1364.1-2002(E)
Example 4:
always @ (in)
if (ena)
out = in;
else
out = 1’b1;
// Supported, but simulation mismatch might occur.
// To assure the simulation will match the synthesized logic, add ena

// to the event list so the event list reads: always @ (in or ena)

Example 5:
always @ (in1 or in2 or sel)
begin
out = in1; // Blocking assignment
if (sel)
out <= in2; // Nonblocking assignment.
end
// Not supported, cannot mix blocking and nonblocking assignments in
// an always statement.
Example 6:
always @* // Implicit event expression yields combinational log
...