12. Verilog 2000
Our Verilog implementation is currently a rapidly growing subset of
the proposed Verilog 2000 standard. This chapter documents some
of the new V2000 features and how they are implemented in out compiler.
Like any new standard Verilog 2000 has a small number of inconsistencies that
will probably be ironed out as they are first implemented, our take
on these are outlined here.
12.1 V2000 Things not yet implemented
At this point we believe we've implemented the full V2000 feature set
if you think you've found something we've missed please let us know.
12.2 Finding Top Level Modules
In the original Verilog model determining which modules are at the top level
was relatively simple - look at all the modules, all those not specified
as being in a library and not referenced by any other module in the source
are top level modules and are instanced by the compiler - elaboration
(creation of the hierarchical tree of dependent instances) continues from there.
In Verilog 2000 this is problematical - basically in order to determine which modules
are not referenced elaboration must occur (because generate statements
can cause conditional instantiation depending on which parameters are passed
down from modules above, and because the Configuration Management subsystem can replace
one module with another with hierarchical path names [again requiring elaboration]).
For these reasons in some situations the compiler is faced with a 'chicken and egg' sort
of situation when trying to determine which modules are 'top level'. It is even possible
to generate verilog programs with no obvious 'top' module, or two mutually
exclusive 'top' modules.
For this reason
we use the following much simpler mechanism for determining whether a module
is a top level module.
- A top level module must be in the library 'work' (the default library in
which all modules from files not explicitly placed in a library are
- A top level module must not be file a file included as a library using
a '-v' flag
- If any non-library modules in 'work' references a module of the same
name as a second module in 'work' the second module can not be a top
level module (even if it's a conditional module
in a generate statement that is never actually instanced or is replaced
by another module in another library by a configuration management
12.3 Generate Statements
This section is intended as a quick introduction to the new 'generate' statements,
it's not intended as an in-depth reference.
Verilog 'generate' statements allow conditional declarations of variables,
instantiation of other modules or of always statements.
The basic syntax is:
.... generate statements
Valid 'generate' statements include:
if (<expression>) <generate statement>
if (<expression>); <generate statement> else
begin : <block name> <generate statements> end
<expression>: <generate statement>
default: <generate statement>
for (<assign>; <expression>; <assign>)
begin : <block name>
as well as any:
a module or primitive instance
In addition you can declare compile-time variables using:
genvar <name> ;
That can be used in a generate block's for statements for the
<assign> statements and can be accessed as constants within
the scope of the for block. Apart from genvar variables
all <expression> in the above blocks must be compile-time constants
expressions consisting of constants or parameters passed into module instances.
genvar variables can only be accessed within the for loop that
assigns them and for loops that use the same variable may not be nested.
module x(input in, output out);
parameter p = 1; // set when x is instantiated
parameter y = 1;
wire w[p:0]; // an ARRAY of wires
assign out = w[p];
assign w = in;
if (p == 2) reg x; // x is only declared if p = 2
if (y > 8) reg [y:0]r; else reg [7:0]r; // r is min 8 bits wide
1: initial r = 3;
2: initial begin x = 1; r = 4; end
default:initial r = p;
for (xx = 0; xx < p; xx=xx+1) begin:block
b #(xx+1)b(.in(w[xx]), .out(w[xx+1]));
In this example the if and case statements are just intended to show
you their formats and show how various things can be used with them,
however look carefully at the for statement - it not only instantiates
'p' copies of the module 'b' it also passes unique parameters to them and
stitches them into a chain of instances with wires connected in between.
Great care should be taken with generate for statements - they can
result in the compiler entering an infinite loop - since we can't put
any reasonable upper side limit to the number of times you go around such a
loop our compiler wont stop you from doing this - however we will issue a warning
the 10,000th time you go around a loop.
12.4 Configuration Management
Verilog 2000 has a new feature called 'configuration management' this process
is basically a formalized description of how verilog source libraries are managed.
This mechanism allows you to do things like have two versions of a module, one
in RTL and another the compiled gate version of the same thing and then switch
backwards and forwards between them easily.
Each library has a unique name and modules are collected into them. For each
particular source file all the modules in that file are placed in the same
library. The standard ways for describing library mapping (ie which source file's
modules will be in which library) are supported along with the '-v+<library>
<file name>' flag (which is recommended). We resolve library mappings in
the following order:
Note: the Verilog 2000 specification is somewhat vague about the syntax
of 'library' statements in mapping files - some examples terminate them with
';'s others don't, also some examples enclose the <pattern>s with
double quotes, others don't - we support all of these syntax forms.
- If a file is included with a '-v+<library> <file name>' flag
then it will be in the library <library>
- If there are one or more '-L' flags that introduce library mapping files
containing statements of the form 'library <library> <pattern>'
and a file name matches the <pattern> then modules from it will be
included in the library named <library>
- If there are no '-L' flags and there exists a file called 'lib.map' in the
current working directory then it is used as if it were introduced
with a '-L flag
- Modules from all source files that don't match any of the above ways of
assigning libraries are assigned to a library called 'work'
One of the few places where V2000 is actually slightly incompatable with the traditional
verilog is in the area of module parameter passing. Previously any range size on a parameter was
quietly ignored - in V2000 if no range size is given then the parameter gets the size of
the value assigned to it, if a size or type is given then any value is coerced to that size.
You can also declare a parameter to be a signed, real, time etc type.
This change can possibly cause a program to behave differently under V2000 - however this
is highly unlikely to actually happen in most existing programs.