Vl-vardecl
Representation of a single variable or net (e.g., wire) declaration.
This is a product type introduced by defprod.
Fields
- name — stringp
- Name of the variable being declared.
- type — vl-datatype
- Kind of net or variable, e.g., wire, logic, reg, integer, real,
etc. Also contains sizing information.
- nettype — vl-maybe-nettypename
- If NIL, then this is really a variable, not a net.
- constp — booleanp
- (Variables only). Indicates whether the const keyword was
provided.
- varp — booleanp
- (Variables only). Indicates whether the var keyword was
provided.
- lifetime — vl-lifetime-p
- (Variables only). See SystemVerilog-2012 Section 6.21. There
are pretty complex rules for variable lifetimes. BOZO we don't
really support this yet in any meaningful way, and the
lifetime field is currently just used to record whether a
static or automatic keyword was found during parsing.
- initval — vl-maybe-expr
- (Variables only). BOZO. When present, indicates the initial
value for the variable, e.g., if one writes integer i = 3;,
then the initval will be the vl-expr-p for 3.
When wire declarations have initial values, the parser turns them
into separate continuous assignment statements, instead. It
should turn these into separate initial blocks, I think.
- vectoredp — booleanp
- (Nets only) True if the vectored keyword was explicitly
provided.
- scalaredp — booleanp
- (Nets only) True if the scalared keyword was explicitly
provided.
- delay — vl-maybe-gatedelay
- (Nets only) The delay associated with this wire, if any.
For instance, wire #1 foo.
- cstrength — vl-maybe-cstrength
- (Trireg nets only). The charge strength associated with the
net, if any. For instance, trireg medium foo.
- atts — vl-atts
- Any attributes associated with this declaration.
- loc — vl-location
- Where the declaration was found in the source code.
Verilog-2005 and SystemVerilog-2012 distinguish between variables
and nets. Historically, VL also separated these concepts in its basic
syntactic representation. However, we eventually decided that merging together
the two concepts into a single syntactic representation would be simpler. So,
today, vl-vardecl-p objects are used for both net declarations and
for reg/variable declarations.
Net declarations introduce new wires with certain properties (type,
signedness, size, and so on). Here are some examples of basic net
declarations.
module m (a, b, c) ;
wire [4:0] w ; // <-- plain net declaration
wire ab = a & b ; // <-- net declaration with assignment
...
endmodule
Net declarations can also arise from using the combined form of port
declarations.
module m (a, b, c) ;
input wire a; // <-- net declaration in a port declaration
...
endmodule
You can also string together net declarations, e.g., by writing wire w1,
w2;. In all of these cases, our parser generates a separate
vl-vardecl-p object for each declared wire. When an assignment is also
present, the parser creates a corresponding, separate vl-assign-p object
to contain the assignment. Hence, each vl-vardecl-p really and truly only
represents a declaration. Similarly, combined variable declarations such as
"integer a, b" are split apart into multiple, individual declarations.
Arrays
The dims fields is for arrays. Normally, you do not encounter these.
For instance, a wide wire declaration like this is not an array:
wire [4:0] w;
Instead, the [4:0] part here is the range of the wire and its
dims are just nil.
In contrast, the dims are a list of ranges, also optional, which follow
the wire name. For instance, the arrdims of v below is a singleton list
with the range [4:0].
wire v [4:0];
Be aware that range and dims really are different things; w
and v are not equivalent except for their names. In particular,
w is a single, 5-bit wire, while v is an array of five one-bit
wires.
Things are more complicated when a declaration includes both a range and
dims. For instance
wire [4:0] a [10:0];
declares a to be an 11-element array of five-bit wires. The range
for a is [4:0], and the arrdims are a list with one entry, namely the
range [10:0].
At present, the translator has almost no support for arrdims. However, the
parser should handle them just fine.
Vectorness and Signedness
These are only set to t when the keywords vectored or
scalared are explicitly provided; i.e., they may both be nil.
I do not know what these keywords are supposed to mean; the Verilog-2005
specification says almost nothing about it, and does not even say what the
default is.
According to some random guy on the internet, it's supposed to be a syntax
error to try to bit- or part-select from a vectored net. Maybe I can find a
more definitive explanation somewhere. Hey, in 6.1.3 there are some
differences mentioned w.r.t. how delays go to scalared and vectored nets.
4.3.2 has a little bit more.
Delay
Net delays are described in 7.14, and indicate the time it takes for any
driver on the net to change its value. The default delay is zero when no delay
is specified. Even so, we represent the delay using a vl-maybe-gatedelay-p, and use NIL when no delay is specified.
Note (from 6.1.3) that when delays are provided in the combined declaration
and assignment statement, e.g.,
wire #10 a = 1, b = 2;
that the delay is to be associated with each assignment, and NOT with the
net declaration for a. See vl-assign-p for more information.
BOZO consider making it an explicit vl-gatedelay-p and setting
it to zero in the parser when it's not specified.
Warning: we have not really paid attention to delays, and our
transformations probably do not preserve them correctly.
Strengths
If you look at the grammar for net declarations, you may notice drive
strengths. But these are only used when the declaration includes assignments,
and in such cases the drive strength is a property of the assignments and is
not a property of the declaration. Hence, there is no drive strength field
for net declarations.
The cstrength field is only applicable to trireg-type nets. It
will be nil for all other nets, and will also be nil on trireg
nets that do not explicitly give a charge strength. Note that
vl-vardecl-p does not enforce the requirement that only triregs have
charge strengths, but the parser does.
Warning: we have not really paid attention to charge strengths, and
our transformations may not preserve it correctly.
Subtopics
- Vl-vardecl-p
- Recognizer for vl-vardecl structures.
- Vl-vardecl-fix
- Fixing function for vl-vardecl structures.
- Make-vl-vardecl
- Basic constructor macro for vl-vardecl structures.
- Vl-vardecl-equiv
- Basic equivalence relation for vl-vardecl structures.
- Change-vl-vardecl
- Modifying constructor for vl-vardecl structures.
- Vl-vardecl->nettype
- Get the nettype field from a vl-vardecl.
- Vl-vardecl->cstrength
- Get the cstrength field from a vl-vardecl.
- Vl-vardecl->vectoredp
- Get the vectoredp field from a vl-vardecl.
- Vl-vardecl->scalaredp
- Get the scalaredp field from a vl-vardecl.
- Vl-vardecl->name
- Get the name field from a vl-vardecl.
- Vl-vardecl->lifetime
- Get the lifetime field from a vl-vardecl.
- Vl-vardecl->initval
- Get the initval field from a vl-vardecl.
- Vl-vardecl->delay
- Get the delay field from a vl-vardecl.
- Vl-vardecl->varp
- Get the varp field from a vl-vardecl.
- Vl-vardecl->type
- Get the type field from a vl-vardecl.
- Vl-vardecl->loc
- Get the loc field from a vl-vardecl.
- Vl-vardecl->constp
- Get the constp field from a vl-vardecl.
- Vl-vardecl->atts
- Get the atts field from a vl-vardecl.
