From: Tom Fitzpatrick (tfitz@cadence.com)
Date: Mon Sep 14 1998 - 09:12:16 PDT
BAD MSG:
Hi Gang,
-Lines: 165
Content-Type: text/plain; charset="us-ascii"
Content-Length: 5372
X-Status: $$$$
X-UID: 0000000647
Status: RO
Here are my thoughts on B32, B33 and some other things we've been discussing.
B33 - Parameter type declarations
Consider the following example:
module b33;
parameter [3:0] mux_selector = 4'b1010;
parameter [0:3] mux_sel1 = 4'b1010;
parameter r1 = 3.5e17;
parameter p1 = 13'h7e;
parameter [31:0] dec_const = 'b1;
parameter [31:0] dec_const1 = 1'b1;
initial begin
$display("%b",mux_selector);
$display("%b",mux_selector[0]);
$display("%b",mux_sel1);
$display("%b",mux_sel1[0]);
$display(r1);
$display("%b",p1);
$display("%b",p1[1:0]);
$display("%b",dec_const);
$display("%d",dec_const);
$display("%b",dec_const1);
$display("%d",dec_const1);
end
endmodule
The output is:
1010
0
1010
1
3.5e+17
0000001111110
10
0000000000000000000000000000001
1
1
1
Verilog-XL does not allow explicit typing of constants. The following
statements result in an error:
parameter signed [3:0] mux_selector = 4'b1010; // "signed" is illegal
parameter real r1 = 3.5e17; // "real" is illegal
It does currently allow for explicit sizing of parameters, although the
size of the value assigned overrides the declared size, as in the case of
dec_const1 above.
Verilog-AMS allows for lots of new syntax to be associated with parameter
declarations. In addition to explicit typing of parameters, Verilog-AMS
also allows a default value and a range specification, including inclusive
and exclusive bounds, and allowed and disallowed ranges within the overall
range, as in:
parameter real neg_rail = -15 from [-50:0) exclude (-20:-10];
This means that neg_rail is a real parameter with the default value -15.
It's allowable values are from -50 (including -50) up to but not including
-20, and from -10 up to but not including 0. The Verilog-AMS spec also
states that the value range check for parameters is a build-time check and
not a runtime assertion check.
We could allow explicit typing to be consistent, but I certainly don't want
to include the new range specification syntax for parameters. There's
enough different between Verilog and Verilog-AMS that it seems perfectly OK
to require the user to specify on a per-module basis whether they are
parsing Verilog or Verilog-AMS.
B32 - Transport Delay for Events
I'm awaiting a reply from Ted Elkind about this one. Doesn't seem like a
high priority, since you could do pretty much the same thing either with
PLI (as was pointed out) or with a fork/join.
B08 - Implicit Sensitivity List
I think I understand Karen's side of it. Please correct me if I'm wrong Karen.
We had been referring to this construct at the last conference call as a
"combinational" sensitivity list, intended to make an always block so
triggered behave essentially like a continuous assignment. When approached
from this perspective, then Karen's point about not allowing delays is a
valid one. However, that is apparently not the perspective of a majority of
the task force, myself included.
What we want is a shorthand way of specifying an event_expression (since
that's officially what is enclosed in the parentheses after the "always @")
that implicitly and automatically encompasses all elements on the RHS of
assignments within the following statement. That's not all that easy to
define.
always @*
a = b;
would be semantically equivalent to
always @(b)
a = b;
What about
always @*
if (c)
a = b;
It's pretty clear that @* ought to mean "@(b or c)" in this case. What about
always @*
if (c == d)
a = b;
Seems like this ought to mean "@(b or c or d)", so we're getting to include
any expression contained in conditional statements. By extension, we should
also include case expressions:
always @*
case(foo)
2'b00: a = b;
2'b01: a = c;
2'b10: a = ~a;
2'b11: a = a;
endcase
This would be "@(foo or b or c)"
There was some discussion about what to do with tasks and task arguments.
There was general agreement that the task declaration would have to be
local to the module containing the @*, or it should be an error. The
implicit event_expression ought to include the RHS (or conditional
expressions or case expressions) within the task itself.
The general intent is that we have a static syntax, @*, to have a dynamic
interpretation based on what's contained in the associated statement(s). If
I change the first example to
always @*
a = c;
Then I've automatically changed the interpretation of @* to "@(c)".
Some of the sticky situations are going to be:
1) What about nesting?
always @* begin
a = c;
@* b = d;
end
I don't think we should allow nesting, since it'll get confusing. Besides,
I think the requirement for an implicit event_expression within an always
block like this isn't quite as strong. I guess that means that we only
allow the implicit event_expression to be part of an always construct.
Something like (BNF):
always_construct ::= always statement
| always implicit_event_expression non_event_expression_statement
implicit_event_expression ::= @*
Not sure exactly how you'd specify this via BNF, but I hope you get the idea.
-Tom
---------------
Tom Fitzpatrick
Senior Technical Marketing Manager Cadence Design Systems, Inc.
Cycle Simulation Products 270 Billerica Rd.
Logic Design and Verification Business Unit Chelmsford, MA 01824
x6438 (978)446-6438
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:53:00 PDT
and
sponsored by Boyd Technology, Inc.