From: Paul Campbell (paul@taniwha.com)
Date: Tue Dec 05 2000 - 03:39:29 PST
On Tuesday 05 December 2000 02:39 pm, Adam Krolnik wrote:
> Good morning Paul;
>
> > generate and configuration management (basicly in both cases you
> > need to perform elaboration to decide which are the top modules,
> > but you need to know which are then top modules in order to do
> > elaboration, .... do you start with chickens? or eggs? I think
>
> Depending on your usage model, you might have these problems or not.
> If your usage model is to compile all verilog source into libraries,
> then
> in the end, one will ask to compile a specific configuration - and
> mention
> one specific config. This will then define what is the top modules, etc.
Actually this was an area where I found reading the chapter on configuration
management rather confusing - and may have led to the way that I wrote up
this issue - let me explain my (maybe naive thought process) as I worked my
way through D5's CM chapter:
Initially I read it and thought - "great the config blocks show which modules
are at the top" - but then I read further and thought about it for a while
and realized that some of the config blocks were hierarchical and didn't
match to top level modules - and that you couldn't figure out which ones were
hierarchical and which ones were top level without doing elaboration - and of
course you couldn't do that unless you knew which modules were the top level
ones. The examples show hierarchical configs that specify designs (for
example 'bot' on page 209) but the module referenced by these configs
obviously wasn't intended to be instantiated as a top level module.
So I figured I'd misunderstood the intent - in fact the only way that it made
sense to me was for the top level modules to be determined by some other
mechanism (like the one that we've always used) and then the config block's
'design' clauses were used to match the config blocks to the modules in order
to determine which config blocks applied to which top level modules.
Now as I said it took me quite a bit of thinking as I worked my way though
the chapter to come to this point (which may well be wrong - but hopefully
my confusion will help to find a way to make the language clearer in the
future).
I think that the missing piece of information - that's almost at the end of
the CM chapter - that I probably didn't put together is that either you have
a starting config specified from the command line (here it would be great to
have a standard way of doing this, say '-C [lib.]config ) which in turn
specifies the root modules or you just use the default library mapping lists
and use the 'traditional' mechanism for determining the top level modules.
I think I got sidetracked by trying to figure out what the config block's
'design' clause ment for non top-level modules (shouldn't it be optional? and
just required for the top level ones?).
Notice that the CM spec references chapter 12 for how to find the top level
module when no config is specified - however in this context it probably
should specify which CM libraries (for example only 'work') are searched.
Also in existing (pre V2000) implementations things are a little more complex
than this - you can think of as being like this - 'work' is populated with 2
classes of modules - ones that are searched for top level modules and ones
that aren't (introduced by the +v - what we currently consider as
'libraries') while this is currently implementation specific it's probably
appropriate to allow this sort of behavior for backwards compatability.
> If one does not use any configuration blocks, then you are resolved to
> searching for a top level module in the source not unconditionally
> instantiated. You show a strange possibility of two modules, you may
> then also need to consider this example...
>
> module A(a, b, c);
> input a, b;
> output c;
> parameter inside = 1;
>
> generate
> if (inside == 1)
> A ohhhhnoooo (a, b, c);
> endgenerate
>
> endmodule
actually this one's an old pre-v2000 problem that was always been possible,
even before generate etc one could:
module A;
A x();
endmodule
or things as complex or more complex than:
module A;
B x();
endmodule
module B;
A x();
endmodule
This is an easy thing to detect prior to V200 without elaorating to infinity,
I think our compiler gives an error message something like "recursive module
instantiation, buy dram stock".
The interesting thing about V2000 is not that this is possible - but that
recursive module instantiation is potentially usefull because it's possible
to create recursive modules that don't run away to infinity - detecting these
without trying to elaborate is very difficult, if not impossible - you're
going to groan when I provide this example of an implementation of factorial:
module fact;
parameter f = 10;
parameter g = 1;
generate
if (f == 1) begin
initial $display(g);
end else begin
f #(f-1, g*f)f();
end
endgenerate
endmodule
Anyone want to take bets on how long it is before John Cooley starts an
obfusticated-verilog contest? :-)
Seriously though I believe that the language should just plain ban recursive
module instantiation - compilers have always barfed at them in the past - now
they occupy a gray area where they might be useful but you don't know without
a potentially infinite elaboaration that's going to end with a 'compiler out
or memory' error of some sort.
Paul Campbell
paul@verifarm.com
This archive was generated by hypermail 2.1.4
: Mon Jul 08 2002 - 12:54:15 PDT
and
sponsored by Boyd Technology, Inc.