Subject: Re: problem with incomplete type references in draft 8
From: Peter Flake (flake@co-design.com)
Date: Thu May 09 2002 - 01:56:14 PDT
Paul,
For modular compilation, surely what matters is that the definitions of the
types are available to the particular run of the compiler?
I do not see why this depends upon the order of definition and use,
provided both are visible at the same time.
Peter.
At 06:30 PM 5/8/02 -0700, Paul Graham wrote:
>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 : Thu May 09 2002 - 04:03:55 PDT