Generate statement in verilog?
Paul
I have some experience with VHDL and now I'm doing some small designs
in verilog, but I miss some VHDL constructions. The one I miss the
most is the generate statement to instantiate the same module more
than once with out writing a line for each instantiation (or also to
do conditional instantiation) like:
for I in 0 to 32 generate
FA: FULL_ADDER port map (
A => X(I), B => Y(I), C => TMP(I),
S => Z(I), Co => TMP(I+1));
end generate;
How could I do something like this in verilog?
Thanks in advance,
Paul.
Jonathan Bromley
<dor...@hotmail.com> writes
>How could I do something like this in verilog?
>
> for I in 0 to 32 generate
> FA: FULL_ADDER port map (
> A => X(I), B => Y(I), C => TMP(I),
> S => Z(I), Co => TMP(I+1));
> end generate;
By waiting patiently until your tool suppliers support the new
Verilog-2001 standard, which has generates.
At FDL'01 in Lyon last month, Serge Maginot of Synopsys pointed out
that tool vendors will make only those changes that they perceive the
users want; and, more surprisingly, said that he only rarely
receives requests from users for language enhancements like this.
The moral is that we have a duty to besiege our tool suppliers with
polite but firm requests for full support of the latest standards in
a timely manner. Synopsys's new "Presto" synthesis front-end supports
quite a lot of Verilog-2001; ModelSim has implemented a few of the
easier bits of the new standard (sadly not including generates);
I'm sure other vendors are "on the case" - but it's all irrelevant
until the new standard is properly supported across the board!
Start writing those support emails!
--
Jonathan Bromley
DOULOS Ltd.
Church Hatch, 22 Market Place, Ringwood, Hampshire BH24 1AW, United Kingdom
Tel: +44 1425 471223 Email: jonathan...@doulos.com
Fax: +44 1425 471573 Web: http://www.doulos.com
**********************************
** Developing design know-how **
**********************************
This e-mail and any attachments are confidential and Doulos Ltd. reserves
all rights of privilege in respect thereof. It is intended for the use of
the addressee only. If you are not the intended recipient please delete it
from your system, any use, disclosure, or copying of this document is
unauthorised. The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Kevin Neilson
"Jonathan Bromley" <Jonathan...@doulos.com> wrote in message
news:CQulB5Au...@doulos.co.uk...
I wrote all those emails before the standard was even ratified, and I was
ignored. Every time I go to a seminar I bug vendors to at least put in the
generate statement but nobody thinks there's a demand. I could understand
if it were hard, but implementing a generate statement doesn't seem
difficult. You could make a precompiler that would expand the generate
block in about 5 lines of Perl.
I currently use "parameterizable mux-based collapsing" in which I
instantiate all possible instances and then use a non-synthesizable mux
based switched with a parameter to mux the outputs from the instantiations
to the module output. All instantiations that don't have outputs muxed to
the module outputs will be collapsed by the synthesizer.
-Kevin
Paul
> By waiting patiently until your tool suppliers support the new
> Verilog-2001 standard, which has generates.
But then... what would be the result of a VHDL2Verilog trasnlator
tool? (if the CHDL file has generates)
Thanks,
Paul.
Steven Sharp
> I wrote all those emails before the standard was even ratified, and I was
> ignored. Every time I go to a seminar I bug vendors to at least put in the
> generate statement but nobody thinks there's a demand. I could understand
> if it were hard, but implementing a generate statement doesn't seem
> difficult. You could make a precompiler that would expand the generate
> block in about 5 lines of Perl.
If you can get the functionality you need with a simple script, then by
all means use a script. But Verilog generates are much harder than that,
and can't be done by a simple preprocessor approach.
Verilog generates can be controlled by the values of Verilog parameters.
Different instances of a module can have different values for the same
parameters and thus get different expansions. No simple processing of
the source text can do that.
A preprocessor can't even determine the values of parameters. That
requires performing the instantiation process to determine the effects
of parameter overrides. The instantiation of one module containing a
defparam can affect the values of parameters used in generates in
other arbitrary modules. This leads to order dependencies where one
module may need to be instantiated before another. Partial parameter
propagation may need to be done partway through instantiation,
instead of waiting until instantiation is done. This changes how
instantiation has to be done, and probably requires rewriting significant
portions of most tools.
In my opinion, Verilog generates are one of the most difficult of
the new features to implement. The fact that they aren't included
in the subsets of the new features being supported by various tools
may indicate that other implementors agree.
--
Steven Sharp
sh...@cadence.com
Jonathan Bromley
<sh...@cadence.com> writes
>In my opinion, Verilog generates are one of the most difficult of
>the new features to implement. The fact that they aren't included
>in the subsets of the new features being supported by various tools
>may indicate that other implementors agree.
Can you expand a little on this? I'm at a loss to see why it is hard
given the "existence proof" from VHDL tools. Agreed, Verilog-2000
generates have a couple of extra features ("else" on if-generate,
and case-generate) but that doesn't seem like a whole new area.
And some vendors' tools (!) have been supporting Verilog-1995
arrays of modules for a while, so that kind of thing is obviously OK.
I wonder if it isn't the 2-D arrays of nets that require a bigger
culture shift?
--
Jonathan Bromley
DOULOS Ltd.
John_H
flat collection of instances. I design hierarchically, I expect the compiler to
work hierarchically. Any parameterizable instance needs to be treated as a
separate entity. Why, then, is the extension of the concept to a parameterizable
instance with a generate statement any different? If the compiler has to produce
an instance driven by parameters, why is it unreasonable to expand the text at
that time?
Are parameters treated in a very different way?
Your answers can help me form my expectations from the tool vendors since I see
things clearly only on my side of the fence.
Paul Campbell
> In my opinion, Verilog generates are one of the most difficult of
> the new features to implement. The fact that they aren't included
> in the subsets of the new features being supported by various tools
> may indicate that other implementors agree.
Actually I found that basic implementation of generate in my compiler was
really pretty straight forward - I had working stuff in about 2 weeks work
- and that took that long because I had to reorganize some of the internal
passes to process the instance hierarchy in a different order in order to
continue to do a lot of the existing optimizations.
What is hard are a bunch of difficult issues in and around the intersection
of generate, parameters and the new configuration management stuff that are
much harder to deal with, and I suspect, much less likely to be used by
most people than plain generate. The process of figuring out the minimal
number of versions of each module instance to actually compile is also made
a lot harder by generate too (esp. in combination with relative
hierarchical references :-)
Paul
Stephen Williams
> most is the generate statement to instantiate the same module more
> than once with out writing a line for each instantiation
In the case of just creating a bunch of module instances, you can
use module instance arrays:
foomodule foo[32:0] (ports....);
Failing that, the Verilog 200x standard includes a generate syntax.
--
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
steve at picturel.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
Steven Sharp
>
> Can you expand a little on this? I'm at a loss to see why it is hard
> given the "existence proof" from VHDL tools.
Proof that something is possible is not the same as proof that it is
easy. However, I believe it is easier in VHDL than in Verilog. VHDL
does not have an equivalent to the Verilog defparam construct.
If I understand it correctly, VHDL instantiation can occur with a
straightforward traversal of the hierarchy. All the information
needed to determine the values of generics for an instance is
guaranteed to be available when the traversal reaches it.
In Verilog, the values of parameters for an instance cannot always
be known when it is instantiated. A defparam in another instance
anywhere else in the design could change their values, directly
or indirectly (e.g. by making changes to values of parameters above
them in the hierarchy, which need to propagate down to them).
And since generates can depend on parameter values, a module
containing generates cannot finish being instantiated until its
parameter values are known.
Without generates, defparams can be handled by instantiating
everything first, and then processing the defparams to determine
final parameter values. With generates, final parameter values
are needed during instantiation, so this is impossible. A more
complex instantiation procedure is required.
Generate and defparam do not play well together. From a language
design viewpoint, I think that defparam should never have been
included. However, defparam is already in the language and is
already being used. Therefore, generate has to be made to work
with it, complicating implementation.
> Agreed, Verilog-2000
> generates have a couple of extra features ("else" on if-generate,
> and case-generate) but that doesn't seem like a whole new area.
Those aren't major issues.
> And some vendors' tools (!) have been supporting Verilog-1995
> arrays of modules for a while, so that kind of thing is obviously OK.
Arrays of instances do cause similar problems. That is presumably
why so many tools don't support them, even 6 years after 1995. Those
tools that do support them will probably have an easier time extending
to handle generates.
> I wonder if it isn't the 2-D arrays of nets that require a bigger
> culture shift?
Those aren't trivial either.
I think that "constant functions" may be the worst, especially since
I don't see them as important to many users.
Steven Sharp
sh...@cadence.com
Steven Sharp
> If the compiler has to produce
> an instance driven by parameters, why is it unreasonable to expand the text at
> that time?
Compilers do not work with a text representation internally. The first
thing they do is convert your source text into an internal form that more
directly represents the "meaning" of the text. Then they work with that
higher level representation, generally figuring out more information and
adding that to the internal representation. By the time a Verilog compiler
is figuring out the values of parameters, there is no text to be expanded.
Instead, the internal representation is modified appropriately.
> Are parameters treated in a very different way?
I am not sure what you are asking. Different from what? If you mean
different from a text preprocessor, then the answer is yes. Verilog
parameters are not handled by textual replacement the way C preprocessor
macros are.
A text preprocessor doesn't understand the text it is processing any
more than a text editor does. It just performs text substitutions,
based on simple embedded directives. Determining the values of Verilog
parameters requires processing the "meaning" of the Verilog source (and
of information that may be in other files, and therefore not available
during preprocessing). Since a text preprocessor or simple script
cannot determine the values of Verilog parameters, it is incapable of
expanding Verilog generates.
Steven Sharp
sh...@cadence.com
Srinivasan Venkataramanan
Thanks for this detailed explanation, I really appreciate it.
Few comments below:
"Steven Sharp" <sh...@cadence.com> wrote in message
news:3a8e124e.01101...@posting.google.com...
> Jonathan Bromley <Jonathan...@doulos.com> wrote in message
news:<NWSGAKAa...@doulos.co.uk>...
> >
> > Can you expand a little on this? I'm at a loss to see why it is
hard
> > given the "existence proof" from VHDL tools.
>
> Proof that something is possible is not the same as proof that it is
> easy. However, I believe it is easier in VHDL than in Verilog.
VHDL
> does not have an equivalent to the Verilog defparam construct.
>
> If I understand it correctly, VHDL instantiation can occur with a
> straightforward traversal of the hierarchy. All the information
> needed to determine the values of generics for an instance is
> guaranteed to be available when the traversal reaches it.
>
> In Verilog, the values of parameters for an instance cannot always
> be known when it is instantiated. A defparam in another instance
> anywhere else in the design could change their values, directly
> or indirectly (e.g. by making changes to values of parameters above
> them in the hierarchy, which need to propagate down to them).
> And since generates can depend on parameter values, a module
> containing generates cannot finish being instantiated until its
> parameter values are known.
>
I think the problem is equally worse in VHDL as well, we can have
"constants" whose value depend on "generics" and which can be used in
"generate" statements.
> Generate and defparam do not play well together. From a language
> design viewpoint, I think that defparam should never have been
> included. However, defparam is already in the language and is
> already being used. Therefore, generate has to be made to work
> with it, complicating implementation.
>
How about just supporting "generate" and putting a restriction
saying "defparam" for these kind of stuff in *not implemented* yet?
That would give us a very big benefit, instead of saying "it is too
complex".
I can even imagine that you add a simple pre-processor kind-of
support for this to start with.
<SNIP>
>
> Arrays of instances do cause similar problems. That is presumably
> why so many tools don't support them, even 6 years after 1995.
Those
> tools that do support them will probably have an easier time
extending
> to handle generates.
>
I just don't understand why EDA Vendors don't think like
designers. Give us a basic support and then say "you are working on
further improvements", rather than saying the entire possibilities are
too complex to implement etc..
Thanks,
Srinivasan
--
Srinivasan Venkataramanan
ASIC Design Engineer
Software & Silicon Systems India Pvt. Ltd. (An Intel company)
Bangalore, India, Visit: http://www.simputer.org)
Parvathy Uma
>
> I just don't understand why EDA Vendors don't think like
> designers. Give us a basic support and then say "you are working on
> further improvements", rather than saying the entire possibilities are
> too complex to implement etc..
If all EDA vendors did that , what you will end up with is a lot of
dangling
"features" and no way to link them up...If you look carefully at the
Verilog language you see a lot of these dangling features even now.
Someone has to think of the whole picture and not just keep implementing
"features" however compelling the need may "seem" to be. In a HDL as
widely used and as quirky as Verilog, I think it is more important to get
the specification correct and then implement it uniformly across different
vendors rather that putting in and taking out features in each version of
the standard.( as I am told VHDL87/93/2000? did. )
-Uma