From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Wed Sep 13 2000 - 23:53:17 PDT
BTF Conference Call - 20000907
Adam, Mike, Steve, Stefen, Anders, Cliff
Thursday - 10 PDT
Some proposals in response to the no-votes from Cadence employees.
More discussion will continue on Thursday, September 14th.
Regards - Cliff
----------------------------------------------------------------------------
Section 2.8 Page 15 - The last line:
PROBLEMS:
Why should the standard define the use model for attributes? There can be
cases when the module definition attribute should override the one on the
module instantiation.
New issue: What happens if someone tries attach an attribute more than once
to the same object?
(* foo=0, foo=1 *)
Proposed: Steve
Second: Adam
WAS: For attributes that can be attached to both module definitions and
module instantiations, the attribute value associated with the module
instantiation shall override the attribute value associated with the
module definition.
PROPOSED REPLACEMENT: If the same attribute name is defined more than once
for the same language element, the last attribute value shall be used and a
tool may give a warning that a duplicate attribute specification has occurred.
NOTE: The Standard will not discuss how attributes might be overridden.
Since attributes are primarily intended for annotating information into
Verilog source files for use by other tools, this behavior will be left to
be tool dependent. Attributes are intended to replace pseudo-comments such
as "// Synopsys ...", which force certain non-Verilog tools to parse all
comments to find tool-specific attribute-like information.
----------------------------------------------------------------------------
Section 2.8 Page 15 - Next to last line
PROBLEM: This line says that an attribute value can be either
true or false. The BNF says that the attribute can be assigned any
constant expression. Which of these is correct? See examples 6 and 7 in
section 2.8.1 (page 17)
Proposed: Steve
Second: Adam
WAS:
If a value is not specifically assigned to the attribute or a non-zero
value is assigned, then its value shall be true. If 0 is assigned, then the
attribute is false.
PROPOSED IS:
If a value is not specifically assigned to the attribute, then its value
shall be 1.
----------------------------------------------------------------------------
Section 2.8 Page 15
If inheritance is to be defined in the standard, what is defined for the
following case for the input wire "in" and the iodecl "in"? ...
NOTE: Inheritance was not defined, no proposal necessary.
----------------------------------------------------------------------------
Section 2.8, Page 15
PROPOSAL: remove ; form syntax for attributes syntax box 2-3 and the BNF
Proposed: Cliff Cummings
Second: Stefen
----------------------------------------------------------------------------
Section 2.8.1 Page 16
PROBLEM: There are typos in the first example:
GLOBAL SEARCH WAS: parallee_case
GLOBAL REPLACE WITH: parallel_case
----------------------------------------------------------------------------
Section 3.12, page 41
*** NOT RESOLVED!! ***
PROBLEM: To which name space does the configuration names belong?
What is the name space for attributes?
The first paragraph last line of this section says:
Once a name is used to define a module, macromodule, or primitive,
the name shall not be used again to define another module, macromodule,
or primitive.
This no longer holds true if you use configurations.
The name space for configurations should be specified.
NOTE: The BTF agrees - but defer for new wording - Uma to submit new wording
----------------------------------------------------------------------------
Section 9.2.2 Page 128 the paragraph after example 3 says:
PROBLEM: When multiple nonblocking assignments are scheduled to occur *in*
the same variable in a particular time slot, the order in which the
assignments are evaluated in not guaranteed--the final value is
indeterminate.
(Also note the typo)
Section 5.4.1 guarantees the order in which the nonblocking assignments
occur.
PROPOSED: Mac
SECOND: Cliff
PROPOSED NEW WORDING:
The order of the execution of distinct nonblocking assignments to a given
variable shall be preserved. This means that if there is clear ordering of
the execution of a set of nonblocking assignments, then the order of the
resulting updates of the destination of the nonblocking assignments shall
be the same as the ordering of the execution.
Example 4:
module multiple2;
reg a;
initial a = 1;
// The assigned value of reg a is determinate
initial begin
a <= #4 0; // schedules a = 0 at time 4
a <= #4 1; // schedules a = 1 at time 4
end // At time 4, a = 1
endmodule
If the simulator executes two procedural blocks concurrently, and if these
procedural blocks contain nonblocking assignment operators to the same
variable, the final value of that variable is indeterminate. For example,
the value of reg a is indeterminate in the following example.
Example 5:
module multiple3 ;
reg a;
initial a = 1;
initial a <= #4 0; // schedules 0 at time 4
initial a <= #4 1; // schedules 1 at time 4
// At time 4, a = ??
// The assigned value of the reg is indeterminate
endmodule
Note: the fact that two nonblocking assignments targeting the same variable
are in different blocks is not by itself sufficient to make the order of
assignments to a variable indeterminate. For example, the value of reg a at
the end of time cycle 16 is determinate in the following example.
module multiple2a ;
reg a;
initial #8 a <= #8 1; // executed at time 8; schedules
// an update of 1 at time 16
initial #12 a <= #4 0; // executed at time 12; schedules
// an update of 0 at time 16
// Because it is determinate that the update of a to
// the value 1 is scheduled before the update of a to
// the value 0, then it is determinate that a will have the
// value 0 at the end of time slot 16.
endmodule
END OF PROPOSAL
NOTE: We still need to make additional clarifications to parts of section 5
per additional e-mail messages.
----------------------------------------------------------------------------
Section 9.7.5 Page 144
NO PROPOSED CHANGE, LEAVE AS IS.
NOTE: Although the concern expressed that some engineers will mistakenly
believe that this construct will automatically force any always block to
model combinational logic is a real possibility, this enhancement is too
value to omit solely because it might be confusing to inexperienced Verilog
designers.
The @* construct is intended primarily to be used at the top of the always
block to accurately model combinational logic. This construct will help
engineers doing synthesis to avoid coding styles that would cause a
mismatch between pre- and post-synthesis simulations that could introduce
errors into actual designs.
The @* construct is also a very nice shorthand and will become an easily
identifiable coding style for power Verilog-synthesis users.
END OF NOTE
Comment from Cadence ballot follows:
The main problem is that it is based on a common misconception about
always blocks, fostered by the synthesis tools. Many people read
always @(a or b)
c = a & b;
as "Always when a or b changes, do assignment". This is actually
"Repetitively do statement", where statement is "wait for a or b to change,
then do assignment". The event control is not attached to the "always", it
is attached to the assignment. It is not clear to what this new
combinational
sensitivity list is attached. If it is attached to the "always" and can
only appear immediately after "always", then it presumably includes
everything
read inside the always block. The problem with this is that it follows
different rules from a normal event control, which can appear on any
statement or as an intra-assignment delay. If it is attached to the
statement
like an event control, then it presumably includes sensitivity to everything
read by the statement (or right-hand side expression for an intra-assignment
delay). This is likely to be confusing to designers who don't really
understand that event controls are attached to statements, not to always
blocks. For example
always @(a or b)
begin
c = a;
d = b;
end
is equivalent to
always
begin @(a or b)
c = a;
d = b;
end
however
always @* // equivalent to @(a or b), because attached to begin-end
begin
c = a;
d = b;
end
would not be equivalent to
always
begin @* // equivalent to @(a), because attached to c = a;
c = a;
d = b;
end
The introduction of this construct may also lead designers further into
thinking that an always block with a combinational sensitivity list is
equivalent to a continuous assignment. Many designers believe that an always
block containing a delay will trigger again if the event control occurs again
while the block is waiting for the delay. E.g. they believe that
always @(a or b)
c = #(5) a & b;
or perhaps
always @(a or b)
#(5) c = a & b;
is equivalent to
assign #(5) c = a & b;
which is not correct. The continuous assignment will behave like
combinational logic, re-evaluating whenever the inputs change. Output
pulses narrower than #5 will be filtered due to event cancellation, but the
final result after the inputs settle will be correct. In the first
"always" case, changes to the inputs within #5 of the first change will not
be seen, and the expression will not be re-evaluated. The final result may
be wrong as a result. In the second "always" case, the final result should
be correct, but the propagation delay for changes after the first will be
strange. Adding a new mysterious shorthand and calling it a combinational
sensitivity list may further lead designers into thinking that the results
will be the same as combinational logic.
For more complex always blocks, it is also unclear what should go into the
implied sensitivity list. Presumably something used in a bit select index
or memory address on the left-hand side should be included, though it does
not appear on the right hand side. Are output arguments from tasks
included? What about inout arguments? What about values used as counts in
repeat loops? What about values used as repeat counts in event repeats for
intra-assignment delays? What about values used to calculate variable
delays for delay controls? What about temporary variables assigned and
then used within the always block? For a more extreme case of that, what
about the index variable of a for-loop within the block, which is read
every time it is incremented and compared, but which never gets its value
from outside the always block? Note that there is no way of detecting and
excluding such variables in the general case. Note that there may also be
a performance cost to being sensitive to extra signals. If the block has
side effects, any ambiguity in what should go into the lists could create
simulation differences between implementations.
Section 9.7.5 should be removed from the standard.
----------------------------------------------------------------------------
Other issues and comments will be discussed at the September 14th BTF
conference call.
Regards - Cliff Cummings
//*****************************************************************//
// Cliff Cummings Phone: 503-641-8446 //
// Sunburst Design, Inc. FAX: 503-641-8486 //
// 15870 SW Breccia Drive E-mail: cliffc@sunburst-design.com //
// Beaverton, OR 97007 Web: www.sunburst-design.com //
// //
// Expert Verilog, Synthesis and Verification Training //
//*****************************************************************//
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:54:13 PDT
and
sponsored by Boyd Technology, Inc.