Subject: Re: problem with incomplete type references in draft 8
From: Paul Graham (pgraham@cadence.com)
Date: Wed May 08 2002 - 18:30:53 PDT
Peter,
Regarding the issue of deferred types in SystemVerilog, you pointed out that
there are already two Verilog-2001 constructs which hurt modular
compilation, parameters and generate blocks.
Parameters certainly are a problem for modular compilation. That is one
reason that we are deprecating the use of defparams. A module which is
instantiated with certain parameter values might still be changed by a later
defparam. A tool which no longer supports defparams can fully process a
module as soon as it is instantiated.
As for generate blocks, it is true that you can do something like:
module ...
generate
if (<condition>)
wire x;
else
reg x;
endgenerate
assign x = 1'b1;
endmodule
and you don't know until elaboration time whether the assignment is legal.
I suspect that many of those who approved the Verilog-2001 ballot may not
have been entirely aware of this feature. This problem could be fixed by a
rule that any declarations occuring within a generate statement have scope
restricted to the generate statement. This would be compatible with the
SystemVerilog feature of allowing declarations to occur in an unnamed block.
Another case of a deferred construct is a function or task which is declared
after use. But this is not much different from a module which is declared
after use. The main difference is that for a function call the sign and
width of the return value are not known at the point of the call, so that
expression sign and width computation must be deferred until the function
declaration is seen.
With the deferred type, we are adding a new feature which will severly hurt
modular compilation. Not only can expression sign and width be deferred,
but also many issues of expression legality. For instance, it will not be
known whether a type is a struct, union, or array, or if it is an array, how
many dimensions it has, or whether it is packed or unpacked. An array or
struct literal cannot be interpreted except as a list of values if the type
is not known.
Even if deferred types are not frequently used, a conforming tool must be
able to handle them in all cases. I don't see a point for having deferred
types, except for the special case of allowing a pointer to a deferred type.
Paul
This archive was generated by hypermail 2b28 : Wed May 08 2002 - 18:32:14 PDT