SpyGlass® simulation

Rules Reference Guide

Version L-2016.06, June 2016
Copyright Notice and Proprietary Information
©2016 Synopsys, Inc. All rights reserved. This Synopsys software and all associated
documentation are proprietary to Synopsys, Inc. and may only be used pursuant to the
terms and conditions of a written license agreement with Synopsys, Inc. All other use,
reproduction, modification, or distribution of the Synopsys software or the associated
documentation is strictly prohibited.

Destination Control Statement

All technical data contained in this publication is subject to the export control laws of the
United States of America. Disclosure to nationals of other countries contrary to United
States law is prohibited. It is the reader's responsibility to determine the applicable
regulations and to comply with them.

Disclaimer
SYNOPSYS, INC., AND ITS LICENSORS MAKE NO WARRANTY OF ANY KIND, EXPRESS
OR IMPLIED, WITH REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO,
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE.

Trademarks
Synopsys and certain Synopsys product names are trademarks of Synopsys, as set forth
at http://www.synopsys.com/Company/Pages/Trademarks.aspx.
All other product or company names may be trademarks of their respective owners.

Third-Party Links
Any links to third-party websites included in this document are for your convenience
only. Synopsys does not endorse and is not responsible for such websites and their
practices, including privacy practices, availability, and content.

Synopsys, Inc.
690 E. Middlefield Road
Mountain View, CA 94043
www.synopsys.com
Report an Error
The SpyGlass Technical Publications team welcomes your feedback and suggestions on
this publication. Please provide specific feedback and, if possible, attach a snapshot.
Send your feedback to [email protected].
Contents

Preface..........................................................................................7
About This Book ...................................................................................... 7
Contents of This Book ............................................................................. 8
Typographical Conventions ..................................................................... 9

Using the Rules in the SpyGlass simulation Product ....................11

Rule Severity Classes ............................................................................ 12
SpyGlass simulation Product Rule Parameters ...................................... 13
check_complete_sensitivity_list ............................................................. 13
effort_level_sim_race........................................................................... 13
effort_simloop_level............................................................................. 14
overlapsimloops .................................................................................. 14
handle_large_bus ................................................................................ 15
strict.................................................................................................. 15
waiver_compat.................................................................................... 16

Rules in SpyGlass simulation.......................................................19

Overview............................................................................................... 19
sim_race01 : Reports signals that are assigned and used in the same
simulation cycle............................................................... 21
sim_race02 : Reports signals that have multiple assignments in the same
simulation cycle............................................................... 28
sim_race03 : Avoid assigning flip-flop outputs in blocking manner ........ 32
sim_race04 : Avoid Event Counting Code .......................................... 34
sim_race05 : Avoid Time Zero race .................................................. 36
sim_race06 : Flip-flop data path should not be entirely blocking ........... 38
sim_race07 : Non-blocking assignment should not be used in clock or
enable path .................................................................... 40
sim_race08 : Control signals of a sequential device should not be multiply
driven ............................................................................ 42
sim_race11 : Detect Read-Write Race globally ................................... 45
sim_loop01 : Possible mismatch in gate-RTL simulation due to simulation
event loops ..................................................................... 47

v
Synopsys, Inc.
vi
Synopsys, Inc.
 Preface

About This Book

The SpyGlass® simulation Rules Reference Guide describes the SpyGlass
rules that check Verilog designs for improved simulation performance.

7
Synopsys, Inc.
Preface

Contents of This Book

Contents of This Book

The SpyGlass simulation Rules Reference Guide consists of the following
chapters:

Chapter Describes...
Using the Rules in the SpyGlass Describes how to use the rules in
simulation Product the SpyGlass simulation product
Rules in SpyGlass simulation Describes the rules related to
constructs that are likely to cause
race conditions and therefore non-
determinism during simulation

8
Synopsys, Inc.
 Preface

Typographical Conventions

Typographical Conventions
This document uses the following typographical conventions:

To indicate Convention Used

Program code OUT <= IN;
Object names OUT
Variables representing <sig-name>
objects names
Message Active low signal name '<sig-name>' must end
with _X.
Message location OUT <= IN;
Reworked example OUT_X <= IN;
with message removed
Important Information NOTE: This rule...

The following table describes the syntax used in this document:

Syntax Description
[ ] (Square brackets) An optional entry
{ } (Curly braces) An entry that can be specified once or multiple
times
| (Vertical bar) A list of choices out of which you can choose
one
... (Horizontal Other options that you can specify
ellipsis)

9
Synopsys, Inc.
Preface

Typographical Conventions

10
Synopsys, Inc.
Using the Rules in the
SpyGlass simulation
Product

The SpyGlass® simulation product has the following usage features:

 Rule Severity Classes
 SpyGlass simulation Product Rule Parameters

11
Synopsys, Inc.
Using the Rules in the SpyGlass simulation Product

Rule Severity Classes

Rule Severity Classes

The rule severity labels in the SpyGlass simulation product have been
classified under the SpyGlass predefined rule severity classes, as follows:

Rule Severity Class Contains the Rule Severity Labels...

WARNING Race, Simulation-Race

Refer to the Atrenta Console Reference Guide for more information about
SpyGlass predefined rule severity classes.

12
Synopsys, Inc.
 Using the Rules in the SpyGlass simulation Product

SpyGlass simulation Product Rule Parameters

SpyGlass simulation Product Rule Parameters

This section provides detailed information on the SpyGlass simulation
product rule parameters.
You can set these parameters in both Atrenta Console and Tcl by using the
following syntax:
set_parameter <parameter_name> <parameter_value>
For more information on setting the parameters, refer to the SpyGlass Tcl
Interface User Guide and Atrenta Console User Guide.

check_complete_sensitivity_list
Checks for the implicit or complete always block.
By default, the value of the check_complete_sensitivity_list
parameter is yes and the sim_race01 rule reports violation for implicit or
complete always block.
When the value of the parameter is set to no, the rule will not report any
race for implicit or complete always block with respect to the other always
block.

Used by sim_race01
Options yes, no
Default value yes
Example
Console/Tcl-based usage set_parameter
check_complete_sensitivity_list no
Usage in goal/source -check_complete_sensitivity_list=no
files

effort_level_sim_race
Specifies the amount of effort to be put by the sim_race01 rule while
detecting the race condition.

13
Synopsys, Inc.
Using the Rules in the SpyGlass simulation Product

SpyGlass simulation Product Rule Parameters

By default, the value of this parameter is 0. Set this parameter to an

integer value in case of high run time to specify the amount of effort to be
applied while detecting the race condition.

Used by sim_race01
Options Positive integer value
Default value 0
Example
Console/Tcl-based usage set_parameter effort_level_sim_race 100
Usage in goal/source -effort_level_sim_race=100
files

effort_simloop_level
Specifies the amount of efforts put by the sim_loop01 rule in detecting a
simulation loop
Use this parameter to restrict the traversal through a particular scalar net
while detecting a simulation loop. By default, a net is traversed 200 times
during loop detection. When you set this parameter to a higher value, the
rule might require higher run-time.

Used by sim_loop01
Options Positive integer value
Default value 200
Example
Console/Tcl-based usage set_parameter effort_simloop_level 250
Usage in goal/source -effort_simloop_level=250
files

overlapsimloops
Specifies whether the sim_loop01 rule reports overlapping simulation loops
By default, the rule does not report overlapping simulation loops. Set this

14
Synopsys, Inc.
 Using the Rules in the SpyGlass simulation Product

SpyGlass simulation Product Rule Parameters

parameter to yes to report overlapping simulation loops.

Used by sim_loop01
Options yes, no
Default value no
Example
Console/Tcl-based usage set_parameter overlapsimloops yes
Usage in goal/source -overlapsimloops=yes
files

handle_large_bus
Specifies whether the sim_race01 rule should process large bus signals.
By default, this parameter is set to no and the rule does not process large
bus signals.
Set this parameter to yes to enable the sim_race01 rule to process large
bus signals.

Used by sim_race01
Options yes, no
Default value no
Example
Console/Tcl-based usage set_parameter handle_large_bus yes
Usage in goal/source -handle_large_bus=yes
files

strict
Specifies whether strict rule checking should be enforced by the sim_loop01
and sim_race11 rules.
By default this parameter is set to no and these rules check against
reasonable guidelines, to avoid over-reporting.

15
Synopsys, Inc.
Using the Rules in the SpyGlass simulation Product

SpyGlass simulation Product Rule Parameters

Set this parameter to yes to enforce strict rule checking. If the strict
parameter is specified with the list of rule names, strict checking is done
only for the rules specified in the list.

Used by sim_loop01, sim_race11

Options yes, no, comma separated list or rules
Default value no
Example
Console/Tcl-based usage set_parameter strict no
Usage in goal/source -strict=no
files

waiver_compat
Enables the waivers in the sim_race01 and sim_race02 rules to work
correctly even if the line numbers of the RTL get changed.
By default, this parameter is set to no and the violations are not waived
when:
 Rule message has line number string
 Waivers are applied based upon the message string (having line
number), and during subsequent runs
 RTL has changed and hence the line number
If you set the value of this parameter to yes or <rule-name>, it ensures
that the rules do not generate the line number information in the first run
itself. Thus waivers work correctly even if the line numbers of the RTL gets
changed in the subsequent runs.

Used by sim_race01, sim_race02

Options no, yes, comma or space separated list of rules
Default value no
Example

16
Synopsys, Inc.
 Using the Rules in the SpyGlass simulation Product

SpyGlass simulation Product Rule Parameters

Console/Tcl- set_parameter waiver_compat yes

based usage
Usage in goal/ -waiver_compat=yes
source files

17
Synopsys, Inc.
Using the Rules in the SpyGlass simulation Product

SpyGlass simulation Product Rule Parameters

18
Synopsys, Inc.
 Rules in SpyGlass
simulation

Overview
The SpyGlass simulation product has the following race condition detection
rules that detect constructs in RTL designs that are likely to cause race
conditions and therefore non-determinism during simulation:

Rule Flags...
sim_race01 Signals that are assigned and used in the same simulation
cycle in the same module
sim_race02 Signals that have multiple assignments in the same simulation
cycle
sim_race03 Flip-flop outputs that have been assigned using blocking
assignment statements
sim_race04 always constructs with functionality that depends on the
number of times the always construct is invoked in the same
simulation step
sim_race05 Time Zero race conditions
sim_race06 Flip-flop data path of a sequential device if any path in the
fan-in cone of the data path has blocking assignments only
sim_race07 Non-blocking assignments in clock path

19
Synopsys, Inc.
Rules in SpyGlass simulation

Overview

Rule Flags...
sim_race08 Clock, asynchronous set, and asynchronous reset signals of
sequential devices that are directly driven by multiple drivers
sim_race11 Signals that are assigned and used in the same simulation
cycle across different modules
sim_loop01 Possible mismatch in gate-RTL simulation due to simulation
event loops

NOTE: As SpyGlass does not have the concept of simulation step or simulation cycle, it is
not possible to pinpoint the occurrence of real race condition based on the time
concept only.
NOTE: All Race Condition Detection rules are primarily meant for RTL designs. SpyGlass
will not find race conditions for components or gates instantiated in the netlist.
However, SpyGlass checks initial like constructs subject to the limitations
described in this document.

20
Synopsys, Inc.
 Rules in SpyGlass simulation

Overview

sim_race01
Reports signals that are assigned and used in the same simulation
cycle

When to Use
Use this rule to detect signals that are assigned and used in the same
simulation cycle.

Description
The sim_race01 rule reports signals that are assigned and used within the
same module in the same simulation cycle. This rule detects signals that
are in two always constructs in the same module or one always
construct and one continuous assignment statement in the same module.
NOTE: The sim_race01 rule reports read-write race conditions within the same module
whereas the sim_race11 rule reports read-write race conditions across different
modules. Therefore, all possible read-write races in the design are reported by one
or the other rule.
Rule Exceptions
The sim_race01 rule does not report race conditions based on the time
concept only, as shown in Example 6: Rule Limitations.

Parameters
 check_complete_sensitivity_list: The default value is yes. Set the value of
the parameter to no to ignore any violation for race with respect to
implicit or complete always block.
 waiver_compat: Default value is no. If you set the value of this parameter
to yes or <rule-name>, it ensures that the rule does not generate
the line number information in the first run itself. Thus waivers work
correctly even if the line numbers of the RTL gets changed in the
subsequent runs.
 effort_level_sim_race: Default value is 0. Set this parameter to an integer
value in case of high run time to specify the amount of effort to be
applied while detecting the race condition.
 handle_large_bus: Default value is no. Set this parameter to yes to
enable the sim_race01 rule to process large bus signals.

21
Synopsys, Inc.
Rules in SpyGlass simulation

Overview

Constraints
None

Messages and Suggested Fix

The following message appears at the location where the signal
<sig-name> is assigned (line <num1>) and read (line <num2>) in the
same simulation cycle:
[RACE] <type> Read-Write Race for signal '<sig-name>'
(assigned/read on line <num1> and line <num2>)
Where, <type> can be Direct or Multi-level.
The message is back-annotated to the RTL display.
Potential Issues
This violation appears when a signal is assigned and used in the same
simulation cycle.
Consequences of Not Fixing
Assigning and using signals in the same simulation cycle leads to a read-
write race condition.
How to Debug and Fix
Double-click the violation message. The HDL Viewer window highlights the
location of the signal that is either assigned or read after read or assigned,
respectively, somewhere else in RTL in the same simulation cycle. Trace
back the RTL from this line to see other usage of the violating signal. The
violation message itself shows the line number of both the usages of
signal, read and assigned, which helps to debug in RTL.
To fix this problem, avoid read and assign on the same signal in the same
simulation cycle.

Example Code and/or Schematic

Example 1: Race Condition Based on Triggering and Logic
In the following example, the signal b is assigned and read by the same
triggering event that is a change in the signal a or c:
assign b = a | c;
always @(a or c)

22
Synopsys, Inc.
 Rules in SpyGlass simulation

Overview

begin
if (b)
begin
...
end
end
Example 2: Blocking Assignment Resulting in Concurrent Assign and
Use
In the following example, when there is a change in the signal d, the signal
a is reevaluated that in turn causes the signal b to be updated in the
assign statement. However, the updated value of the signal b may not be
visible to the if statement in the always construct, which leads to a race
condition.
assign b = a | c;
always @ (d)
begin
a = 0;
if (b)
begin
...
end
end
In the above example, change the blocking assignment to signal a to a
nonblocking assignment to avoid the race condition.
Example 3: No Race Condition
Consider the following example where assignment to the signal a is a
nonblocking assignment that prevents the race condition:
assign b =a | c;
always @ (d)
begin
a <= 0;
if (b)
begin
...
end

23
Synopsys, Inc.
Rules in SpyGlass simulation

Overview

end
There is no race condition even if the assign statement is replaced by the
equivalent always construct.
Example 4: Race Conditions in Flip-Flop Descriptions
Consider the following example where the output of one flip-flop is fed to
the input of another flip-flop at the same clock event:
always @(posedge clk)
sig1 = data;

always @ (posedge clk)

sig2 = sig1;

always @ (posedge clk)

sig = sig2;
To fix this issue, remodel the example so that there exists at least one
nonblocking assignment in each path leading to the data input of the
flip-flop to ensure determinism between the clock and the data path.
Example 5: Multilevel Race Condition
Consider the following example where signals ad and bd depend on the
same clock clk through signals a and b:
module test (reset, clk);
input reset, clk;

reg [3:0] b;
reg [5:0] out;
reg a;
wire ad;
wire [3:0] bd;

always @(posedge clk)

if ( reset ) a = 0;
else a = ~a;

always @(posedge clk)

if ( reset ) b = 0;

24
Synopsys, Inc.
 Rules in SpyGlass simulation

Overview

else b = b + 1;

assign ad = a;
assign bd = b;

always @(bd or ad)

if ( ad ) out = out + 1;
endmodule
Depending on which signal out of ad and bd achieves the new value first,
signal out may or may not be reevaluated. Therefore, there is a multilevel
race condition between signals ad and bd.
Example 6: Rule Limitations
The sim_race01 rule does not report race conditions based on the time
concept only, as shown in the following example:
initial
begin
fork
#5 a = 1’b0;
#7 b = 1’b0;
join
#8 a = 1’b1;
end

initial
begin
...
#15 if (a)
$display("....");
end
Example 7: Implicit always blocks
Consider the following examples where, by default, the rule reports a
violation for the implicit always block. However, the rule does not report a
violation when the check_complete_sensitivity_list parameter is set to no.
 module test;
reg a, b, c, d,e;

25
Synopsys, Inc.
Rules in SpyGlass simulation

Overview

always@(*) begin
a= 1'b0;
a= 1'b1;
b = c;
end

always@(*) begin
c = 1'b0;
c = 1'b1;
d = a;
end
endmodule
 module test;
reg a, b, c, d,e;
always@(*) begin
a= 1'b0;
a= 1'b1;
b = c;
end

always@(d) begin
c = 1'b0;
c = 1'b1;
d = a;
end
endmodule
 module test;
reg a, b, c, d,e;

always@(*) begin
a= 1'b0;
a= 1'b1;
b = c;
end
always@( posedge d) begin
c = 1'b0;
c = 1'b1;
a = d;
end
endmodule

26
Synopsys, Inc.
 Rules in SpyGlass simulation

Overview

Default Severity Label

Race

Rule Group
simulation

Reports and Related Files

None

27
Synopsys, Inc.
Rules in SpyGlass simulation

Overview

sim_race02
Reports signals that have multiple assignments in the same
simulation cycle

When to Use
Use this rule to detect signals that have multiple assignments in the same
simulation cycle.

Description
The sim_race02 rule reports signals that have multiple assignments in the
same simulation cycle. Design may contain assignments to a signal in two
always constructs in the same simulation cycle.
Rule Exceptions
The sim_race02 rule has the following limitations:
1. This rule checks for race conditions across two always constructs only.
2. This rule does not report race conditions based on the time concept
only, as shown in Example 4.
NOTE: If you want to detect multi-driven nets, it is better to use the W415 rule instead of
sim_race02.

Parameters
 waiver_compat: Default value is no. If you set the value of this parameter
to yes or <rule-name>, it ensures that the rule does not generate
the line number information in the first run itself. Thus waivers work
correctly even if the line numbers of the RTL gets changed in the
subsequent runs.

Constraints
None

Messages and Suggested Fix

The following message appears at the assignment of the signal
<sig-name> at the line <num2> when the signal has already been
assigned at the line <num1>:

28
Synopsys, Inc.
 Rules in SpyGlass simulation

Overview

[RACE] Write-Write Race for signal '<sig-name>' (assignments on

line <num1> and line <num2>)
The message is back-annotated to the RTL display.
Potential Issues
This violation appears when signals have multiple assignments in the same
simulation cycle.
Consequences of Not Fixing
Multiple assignments in the same simulation cycle leads to a race condition
as which assignment is executed first is not defined by Verilog runtime
semantics.
How to Debug and Fix
Double-click the violation message. The HDL Viewer window highlights the
second instance of the signal assignment inside the other always block.
You can confirm the multiple assignments to a signal in one of the following
ways:
 Simple visual inspection of the block
 Scrolling up the HDL Viewer window till you reach the always block
 Search for the signal assigned value in the always blocks of a design
unit
To fix this problem, avoid multiple assignments to a signal in the same
simulation cycle.

Example Code and/or Schematic

Example 1
Consider the following example where a race condition exists in
combinational logic for the signal b:
always @ (a)
b = a | c;

always @(a)
begin
b = d & e;
end

29
Synopsys, Inc.
Rules in SpyGlass simulation

Overview

Example 2
Consider the following example where a race condition exists in sequential
logic for the signal b:
always @(posedge clka)
b = a;

always @(posedge clka)

begin
b = d & e;
f = a;
end
Example 3
Consider the following example that illustrates a design containing multiple
assignments to the signal b in two always constructs in the same
simulation cycle:
module test(a,b);

input a;
output b;
reg b,c,e,d;
always @ (a)
b = a | c;
always @(a)
begin
b = d & e;
end
endmodule
Example 4
This rule does not report race conditions based on the time concept only, as
shown in the following example.
initial
begin
fork
#5 a = 1’b0;
#7 b = 1’b0;

30
Synopsys, Inc.
 Rules in SpyGlass simulation

Overview

join
#8 a = 1’b1;
end

initial
begin
...
#15 if (a)
$display("....");
end

Default Severity Label

Race

Rule Group
simulation

Reports and Related Files

None

31
Synopsys, Inc.
Rules in SpyGlass simulation

Overview

sim_race03
Avoid assigning flip-flop outputs in blocking manner

The sim_race03 rule flags flip-flop outputs that have been assigned using
blocking assignment statements in an always construct.
Using blocking assignment for flip-flop outputs may lead to race conditions
if the output of one flip-flop is the data input of another flip-flop. Then, the
sampling of data input of the second flip-flop may be occurring in the same
simulation step as the output of the first flip-flop, resulting in a race
condition.
Using non-blocking assignments for flip-flop outputs orders the setting and
sampling of signals.

Message Details
The following message appears at the location of a blocking assignment of
a flip-flop output <sig-name>:
[SIMULATION-RACE] Blocking assignment used for flip-flop output
'<sig-name>'
The message is back-annotated to the RTL display.

Rule Severity
Simulation-Race

Examples
Consider the following example where the flip-flop output a of instance
dff0 of module dff is being used as the data input of the flip-flop dff1
of the module dff and the flip-flop output q of the module dff is being
assigned using blocking assignment:
module test (out, in, clk);
input in, clk;
output out;

wire a;

dff dff0(a, in, clk);

32
Synopsys, Inc.
 Rules in SpyGlass simulation

Overview

dff dff1(out, a, clk);

endmodule

module dff (q, d, clk);

input d, clk;
output q;

reg q;

always@(posedge clk)
q = d;
endmodule
For this example, SpyGlass generates the following message:
Blocking assignment used for flip-flop output 'q'
To fix this message, change the blocking assignment to non-blocking
assignment as follows:
always@(posedge clk)
q <= d;
NOTE: The sim_race03 rule flags a message for the module dff even if it was not
instantiated anywhere.

33
Synopsys, Inc.
Rules in SpyGlass simulation

Overview

sim_race04
Avoid Event Counting Code

The sim_race04 rule flags always constructs with functionality that

depends on the number of times the always construct is invoked in the
same simulation step.
If a value is updated in an always construct, this value should be
insensitive to the number of times that construct can be invoked in a
simulation time step. An always construct can be invoked more than once
in a simulation time step if its sensitivity list contains more than one signal.
If there is logic in the always construct that depends on the value of a
variable set during the previous invocation of the same always construct,
then that functionality can be implementation dependent.
The sim_race04 rule checks for the following situations and flags the
constructs that meet both the following conditions:
1. A statement in the body of always construct has at least one variable
used in both LHS and RHS.
2. There are more than one item in the sensitivity list

Message Details
The following message appears at the location of an event counting
statement:
[SIMULATION-RACE] Event counting code used
The message is back-annotated to the RTL display.

Rule Severity
Simulation-Race

Examples
Consider the following examples where the sensitivity list of the always
construct has two variables and the variable i counts the number of times
the always construct is invoked:
always @(A or B)
begin

34
Synopsys, Inc.
 Rules in SpyGlass simulation

Overview

i = i + 1;
end
always @ (event1 or event2)
begin
i = i + 1;
end

35
Synopsys, Inc.
Rules in SpyGlass simulation

Overview

sim_race05
Avoid Time Zero race

The sim_race05 rule flags signals in event triggers that are initialized to
values that could cause non-deterministic event trigger.

Message Details
The following message appears when there is a possible race condition for
signal <sig-name> due to initialization at line <num1> and use at line
<num2>:
[SIMULATION-RACE] Time Zero Race condition for signal <sig-
name> on line <num1> and line <num2>
The message is back-annotated to the RTL display.

Rule Severity
Simulation-Race

Examples
Consider the following example where the always construct could be
triggered if the event trigger is established before the initial value is
assigned to the clock signal clk:
initial
begin
clock = 1;
forever #50 clock = ~clock;
end

always @(posedge clk)

$display(“...”)
The always construct may or may not be triggered at time 0 depending
on when the clock clk is initialized and when the event trigger is set by
the simulator.
Since the clock has been initialized to 1, the always construct could be
triggered if the event trigger is established before the initial value is
assigned to the clock signal but there would not have been any problem if

36
Synopsys, Inc.
 Rules in SpyGlass simulation

Overview

either clock was initialized with 0 or event triggering would have been
happening on a negative edge.
This race condition can be fixed by ensuring that there is no transition at
time 0 as follows:
initial
begin
clock = 1’bx;
#50 clock = 1’b0;
forever #50 clock = ~clock;
end

37
Synopsys, Inc.
Rules in SpyGlass simulation

Overview

sim_race06
Flip-flop data path should not be entirely blocking

The sim_race06 rule flags data path of a sequential device if any path in
the fan-in cone of the data path has blocking assignments only.
To ensure that the new value of data arrives after the current edge of the
clock has been processed, the data path should appear as the LHS of a
non-blocking assignment statement. It is not necessary for all the
expressions involved in the data path computation to be non-blocking
assignments. However, all paths having a cone-in into the data pin of a flip-
flop or a latch should have at least one non-blocking assignment.

Message Details
The following message appears when a path from net <sig1-name> to
the data input <sig2-name> of a flip-flop has blocking assignments only:
[SIMULATION-RACE] Entire data path from <sig1-name> to <sig2-
name> (Data pin) is Blocking
The message is back-annotated to the RTL and schematic display.

Rule Severity
Simulation-Race

Examples
Consider the following example where there is no non-blocking assignment
in the path from signal d3 to signal data (data pin of flip-flop q_reg):
module test (clk, d1, d2, d3, d4, out);
input clk, d1, d2, d3, d4;
output out;

reg q_reg;
reg data1, data2;
wire data;

assign out = q_reg;

always @(d1 or d2)

38
Synopsys, Inc.
 Rules in SpyGlass simulation

Overview

data1 <= d1 & d2;

always @(d3 or d4)

data2 = d3 || d4;

assign data = data1 ^ data2;

always @ (posedge clk)

q_reg = data;
endmodule
For this example, SpyGlass generates the following message:
Entire data path from d3 to data (Data pin) is Blocking

39
Synopsys, Inc.
Rules in SpyGlass simulation

Overview

sim_race07
Non-blocking assignment should not be used in clock or enable
path

The sim_race07 rule flags non-blocking assignment statements in the clock

or enable path to a sequential element.
In order to ensure determinism between clock and data-paths, it is
necessary that the clocks are evaluated before the change in data path, so
that the current clock can capture the data before the data takes its new
value.
All assignments leading to evaluation of clock signal should be a blocking
assignment. Similarly, all signals that appear in the clock path (including
control circuitry) should be evaluated as LHS of blocking assignments. Any
signal that would eventually reach the clock pin of a flip-flop or enable pin
of a latch should be generated using a blocking assignment only.
The sim_race07 rule also checks the paths that are sourced by clock
dividers.

Message Details
The following message appears when a path from net <sig1-name> to
the clock or enable input <sig2-name> of a flip-flop has a non-blocking
assignment:
[SIMULATION-RACE] Non-blocking assignment used in clock path
from <sig1-name> to <sig2-name> (Clock/Enable pin)
The message is back-annotated to the RTL and schematic display.

Rule Severity
Simulation-Race

Examples
Consider the following example where the clock clk1 of the flip-flop
q_req is generated by using a non-blocking assignment:
module test (gating_sig1, clk, data_in, out);
input gating_sig1, clk, data_in;
output out;

40
Synopsys, Inc.
 Rules in SpyGlass simulation

Overview

reg q_reg;
reg clk1;
wire clk_w;

assign out = q_reg;

assign clk_w = clk1;

always @(gating_sig1 or clk)

clk1 <= gating_sig1 & clk;

always @(posedge clk1)

q_reg <= data_in;
endmodule

41
Synopsys, Inc.
Rules in SpyGlass simulation

Overview

sim_race08
Control signals of a sequential device should not be multiply driven

The sim_race08 rule flags control signals (clock, asynchronous set, and
asynchronous reset signals) of sequential devices that are directly driven
by multiple drivers.
Multi-driven clock, set, or reset signals may drive the sequential element to
unknown or incorrect states.
The sim_race08 rule checks all control signals in the sensitivity list of a
sequential element and flags a message if any control signal is directly
driven by multiple drivers in the same or different module.
NOTE: Multi-driven data input to sequential elements is allowed.

Message Details
The following message appears at the location where a multi-driven signal
<sig-name> is encountered in the sensitivity list of a sequential element:
[RACE] Multiple driven signal '<sig-name>' fed to Clock/Set/
Reset input of sequential element.
The message is back-annotated to the RTL and schematic display.

Rule Severity
Race

Examples
Example of Multi-driven Signal Used in the Same Module
Consider the following example where signal muxed_clk is a multi-driven
signal and is in the sensitivity list of the sequential element q_reg:
module test (scan, clk, tclk, data, scan_in, out);
input scan, clk, tclk, data, scan_in;
output out;

reg q_reg;
wire muxed_clk, non_scan;

assign out = q_reg;

42
Synopsys, Inc.
 Rules in SpyGlass simulation

Overview

assign muxed_clk = scan ? tclk : 1'bz;

assign non_scan = ~ scan;
assign muxed_clk = non_scan ? clk : 1'bz;

always @(posedge muxed_clk)

q_reg <= scan ? scan_in : data;
endmodule
For this example, SpyGlass generates the following message:
Multiple driven signal 'muxed_clk' fed to Clock/Set/Reset input
of sequential element.
Example of Multi-driven Signal Used in a Different Module
Consider the following example where the signal clock is multi-driven in
module test and is used as a clock signal for sequential element through
instantiation of module inst:
module test (tclk1, tclk2, scan1, scan2, d);
input tclk1, tclk2, scan1, scan2;
output d;

reg d;
wire clock;

assign clock = scan1 ? tclk1 : 1'bz;

assign clock = scan2 ? tclk2 : 1'bz;

inst inst1 (.clock(clock));

endmodule

module inst (d, in1, clock);

input in1, clock;

output d;

reg d;

always @(posedge clock)

d <= in1;

43
Synopsys, Inc.
Rules in SpyGlass simulation

Overview

endmodule
For this example, SpyGlass generates the following message:
Multiple driven signal 'clock' fed to Clock/Set/Reset input of
sequential element.

44
Synopsys, Inc.
 Rules in SpyGlass simulation

Overview

sim_race11
Detect Read-Write Race globally

The sim_race11 rule flags signals that are assigned and used in the same
simulation cycle across different modules.
Assigning and using the signals in the same simulation cycle leads to a race
condition.
The sim_race11 rule detects such signals that are in two always
constructs in different modules or one always construct and one
continuous assignment statement in different modules.
When you set the strict parameter to yes, the rule reports violation inside
module hierarchy.
NOTE: The sim_race01 rule flags read-write race conditions within the same module
whereas the sim_race11 rule flags read-write race conditions across different
modules. Therefore, all possible read-write races in the design are flagged by one
or the other rule.

Message Details
The following message appears at the location where a signal
<sig1-name> is assigned in module <module1-name> when it is read
as <sig2-name> in module <module2-name> in the same simulation
cycle:
[RACE] Read-Write Race for signal '<sig1-name>' (assigned in
module '<module1-name>' and read as signal '<sig2-name>' in
module '<module2-name>')
The message is back-annotated to the RTL display.

Rule Severity
Race

Examples
Consider the following example:
module top(out, in, clk);
input in, clk;
output out;

45
Synopsys, Inc.
Rules in SpyGlass simulation

Overview

wire out1;

instA p1 (out, in, clk);

instU p2 (out1, out, clk);
endmodule

module instA (out1, in1, clk);

input in1, clk;
output out1;

reg out1;

always @(posedge clk)

out1 = in1;
endmodule

module instU (out1, out, clk);

input out, clk;
output out1;

reg out1;

always @(posedge clk)

out1 = out;
endmodule
In the same simulation step (posedge of signal clk), the signal out1 is
assigned in instance p1 of module instA and its connected signal out is
read in instance p2 of module instU. Therefore, SpyGlass generates the
following message:
Read-Write Race for signal 'out1' (assigned in module 'instA' and read as
signal 'out' in module 'instU')

46
Synopsys, Inc.
 Rules in SpyGlass simulation

Overview

sim_loop01
Possible mismatch in gate-RTL simulation due to simulation event
loops

When to Use
Use this rule to detect event simulation loops in a module.

Description
The sim_loop01 rule reports event simulation loops in a module. These
loops create possible mismatch in gate-RTL simulation.
During simulation, an event can be propagated in any of the following
ways:
 From a signal in the sensitivity list to a signal in LHS of blocking
assignment statements of an always block
 From a signal in RHS to a signal in LHS of a continuous assignment
statement, which includes a wire assignment
 From input ports to output ports in case of Verilog built-in gates
instantiation
An event simulation loop is detected when an event on a signal in the
sensitivity list of a combinatorial always block, say A1, directly or
indirectly triggers continuous assignment statements or combinatorial
always blocks or built-in gate, which again triggers the always block A1.
An event loop should meet the following criteria:
 At least one combinatorial always block
 A cyclic loop among the combinatorial always block or built-in gate
instantiation or continuous assignment statements
Rule Exceptions
The sim_loop01 rule does not propagate an event on a signal across RTL
modules. Refer to Example 5 for an illustration.

Parameters
 effort_simloop_level: Default value is 200. This indicates a net is
traversed 200 times during loop detection. Set this parameter to a

47
Synopsys, Inc.
Rules in SpyGlass simulation

Overview

different integer to change the amount of efforts put by the rule in

detecting a simulation loop.
 overlapsimloops: Default value is no. This indicates the rule does not
report overlapping simulation loops. Set this parameter to yes to report
overlapping simulation loops. Refer to Example 4 for an illustration.
 strict: Default value is no. Set this parameter to yes to report loops
containing multiple always blocks.

Constraints
None

Messages and Suggested Fix

The following message appears when the event simulation loop
<loop-name> is detected inside the module <module-name>.
[WARNING] Simulation loop <loop-name> detected in module
<module-name> [Hierarchy: ‘<hier-path>’]
Potential Issues
This violation appears when an event simulation loop is detected inside a
module.
Consequences of Not Fixing
An event simulation loop leads to possible mismatch in gate-RTL
simulation.
How to Debug and Fix
Double-click the violation message. The HDL Viewer window highlights the
line where an event simulation loop is detected in a module.
To fix the problem, review the RTL and break the undesired loop. It is
advisable to avoid using an event simulation loop in a module.

48
Synopsys, Inc.
 Rules in SpyGlass simulation

Overview

Example Code and/or Schematic

Example 1
Consider the following example:

assign c = b;

always @(a or c)
begin
d = c;
b = a;
end

In this case, signal b is assigned in the always block. The signal triggers
signal c of the continuous assignment statement, which again triggers the
the always block. This creates an event simulation loop. As a result, the
sim_loop01 rule reports a violation.
Example 2
Consider the following example:

assign c = f; //first continuous assignment statement

assign f = b; //second continuous assignment statement

always @(a or c)
begin
d = c;
b = a;
end

In this case, signal b is assigned in the always block. The signal triggers
signal f of the second continuous assignment statement, which further
triggers signal c of the first continuous assignment statement. Signal c
again triggers the always block. This creates an event simulation loop. As
a result, the sim_loop01 rule reports a violation.

49
Synopsys, Inc.
Rules in SpyGlass simulation

Overview

Example 3
Consider the following example that contains two always blocks:

always @(b) //first always block

c = b;

always @(a or c) //second always block

begin
d = c;
b = a;
end

In this case, signal b is assigned in the second always block. The signal
triggers signal c of the first always block, which again triggers the second
always block. This creates an event simulation loop. As a result, the
sim_loop01 rule reports a violation.
Example 4
Consider the following example that contains three always blocks:

//first always block //second always block

always @(b) always @(b)
c = b; e = b;

always @(a or c or e) //third always block

begin
d = c & e;
b = a;
end

50
Synopsys, Inc.
 Rules in SpyGlass simulation

Overview

In this case, the two overlapping loops are created as follows:

 First overlapping loop: Signal b is assigned in the third always
block. The signal triggers signal c of the first always block, which
again triggers the third always block. This creates an event simulation
loop.
 Second overlapping loop: Signal b is assigned in the third always
block. The signal triggers signal e of the second always block, which
again triggers the third always block. This creates an event simulation
loop.
By default, the rule reports only one violation for any one loop. If you set
the overlapsimloops parameter to yes, the rule reports two violations for
these overlapping loops.
Example 5
Consider the following example:

assign c = f;

always @(a or c or e)
begin
d = c & e;
b = a;
end

mod A1(.in(b), .out(f)); //mod A1 is an RTL module

In this case, module A1 is an RTL module. As the sim_loop01 rule does not
propagate an event on a signal across RTL modules, the rule does not
report a violation.

Default Severity Label

Warning

51
Synopsys, Inc.
Rules in SpyGlass simulation

Overview

Rule Group
SimulationRules

Reports and Related Files

None

52
Synopsys, Inc.
List of Topics

About This Book ............................................................................................. 7

check_complete_sensitivity_list...................................................................... 13
Contents of This Book ..................................................................................... 8
effort_level_sim_race.................................................................................... 13
effort_simloop_level ..................................................................................... 14
handle_large_bus ......................................................................................... 15
overlapsimloops ........................................................................................... 14
Overview..................................................................................................... 19
Rule Severity Classes.................................................................................... 12
SpyGlass simulation Product Rule Parameters .................................................. 13
strict .......................................................................................................... 15
Typographical Conventions .............................................................................. 9
waiver_compat ............................................................................................ 16

53
Synopsys, Inc.
54
Synopsys, Inc.