Multiple Module instantiation
brian davis
I have a few questions for everybody out there.
I am implimenting repetitive modules (in a multiplier) in verilog,
and I am implimeting these modules using a structural representation.
This prohibits me from using the looping functionality present in Verilog,
and supported by Cadence because the current loop syntaxes are supported
for behavioral representations only. What I desire is a looping construct
for instantiating multiple structural modules.
It is my understanding that Cadence & Open Verilog International
are currently discussing such a construct, but the syntax for this
construct is not finallized yet.
I would like to program a pre-processor for Verilog code which
would take a "looped" representation of multiple modules and generate
standard Verilog code without the "looped" representation. My questions
are these:
1). Does anybody know of the Cadence & OVI proposed syntax for the
structural looping construct. If I could construct a
pre-processor which used the same syntax as that which will later
be incorporated into Verilog, it would prevent me from
having to re-write my source code later.
2). If this syntax is not yet defined, I have heard that VHDL does support
looping within structural models, and I may design the pre-processor
to take VHDL loops and convert them to multiple Verilog modules.
If this is the case, does anybody with experience using VHDL for
instantiating multiple strucural modules have any comments or
advice, or for that matter know the syntax for the VHDL looping?
3). Has anybody in the past generated such a pre-processor for which either
the executable, code or syntax is in the public domain. If this
work has been done before there may be no need for me to repeat it.
If you have any information pertaining to repetitive structural module
generation, even if you can not answer any of the above questions, I would
appreciate hearing from you. If you do not feel comfortable posting on
the newsgroup, please mail me directly.
Thank you,
Brian.
btd...@engin.umich.edu
John Williams
( OVI may want to consider something like this )
A meta language like C that produces code as a side effect of executing.
For example:
/$ for (x = 0; x < 32; x++)
{ $/
buf buf/$printf("%d",x);$/
(out[/$printf("%d",x);$/],in[/$printf("%d",32-x);$/]);
/$ } $/
This is a little verbose, but hopefully you get the picture . . .
John Williams
Steven Greenberg; x6231
"If an instance name is followed by the range specification, an array of
instances of the specified gate type will be generated."
nand #2 t_nand[0:7] ( ... );
.
.
.
"The connections for an array of instances follow these rules:
. The bitlength of each port in the instance is compared with the module or
primitve port's definition.
. If the bitlengths are the same, the port expression is connected to each
instance
. If bitlengths are different, each instance gets a part select of the port
expression as specified in the range, starting with the left hand index.
. A warning message is issued if there are too many or too few bits to connect
to all instamces. If too few bits are specified, the corresponding ports are
left unconnected."
There is too much more to type. I hope this gives you enough of an idea. If
you need more, you should order the LRM from OVI.
/Steve
--
------------------------------------------------------------------------------
Steve Greenberg Phone: (508) 446-6231
Cadence Design Systems, Inc. FAX: (508) 446-6636
270 Billerica Road email: ste...@cadence.com
Chelmsford, MA 01824
Disclaimer: The standard disclaimer applies
Tomas Nopp
>I finally found it on page 6-5 of the OVI LRM 2.0a.
>"If an instance name is followed by the range specification, an array of
>instances of the specified gate type will be generated."
>nand #2 t_nand[0:7] ( ... );
> .
> .
> .
>"The connections for an array of instances follow these rules:
>. The bitlength of each port in the instance is compared with the module or
> primitve port's definition.
>. If the bitlengths are the same, the port expression is connected to each
> instance
>. If bitlengths are different, each instance gets a part select of the port
> expression as specified in the range, starting with the left hand index.
>. A warning message is issued if there are too many or too few bits to connect
> to all instamces. If too few bits are specified, the corresponding ports are
> left unconnected."
>There is too much more to type. I hope this gives you enough of an idea. If
>you need more, you should order the LRM from OVI.
>/Steve
Steve!
What are you saying with this??? Aren't Cadence supporting Verilog manuals
any more???
Is this a way to say that users/buyers of Cadence Verilog should buy their
documentation from OVI instead of having it included in the simulator
package???
>--
>------------------------------------------------------------------------------
>Steve Greenberg Phone: (508) 446-6231
>Cadence Design Systems, Inc. FAX: (508) 446-6636
>270 Billerica Road email: ste...@cadence.com
>Chelmsford, MA 01824
>Disclaimer: The standard disclaimer applies
______ _ __
/_ __/__ __ _ ___ ____ / |/ /__ ___ ___
/ / / _ \/ ' \/ _ `(_-< / / _ \/ _ \/ _ \
/_/ \___/_/_/_/\_,_/___/ /_/|_/\___/ .__/ .__/
/_/ /_/
********************************************************************
* Tomas Nopp Tel : +46 8 727 33 24 *
* Ellemtel Telecom Systems Labs Fax : +46 8 647 80 59 *
* Box 1505 Email : Tomas...@eua.ericsson.se *
* S-125 25 ALVSJO <------ Snailmail *
********************************************************************
John Sanguinetti
>I finally found it on page 6-5 of the OVI LRM 2.0a.
>
>"If an instance name is followed by the range specification, an array of
>instances of the specified gate type will be generated."
>
>nand #2 t_nand[0:7] ( ... );
>
> .
> .
> .
>
>
>
Can you tell us if Cadence has implemented or plans to implement this feature?
Currently, the IEEE 1364 working group is deciding what parts of the OVI LRM
2.0 should be included in the draft standard, and arrays of instances is
not being considered because no one has implemented them. We don't want to
come out with a standard for which there is no compliant simulator. We also
don't want to have anything in the standard which has not been proven to
be implementable. To my knowledge, none of the other Verilog vendors have
implemented instance arrays.
John Sanguinetti
Chronologic Simulation
Steven Greenberg; x6231
> What are you saying with this??? Aren't Cadence supporting Verilog manuals
> any more???
> Is this a way to say that users/buyers of Cadence Verilog should buy their
> documentation from OVI instead of having it included in the simulator
> package???
I am really sorry if I left that impression. Not only does Cadence
support Verilog manuals, but from what I understand they are now
on-line when you install our products. (I say "from what I
understand" because I naturally get access to things before the
customer does and I sometimes get confused about what is already out
there.)
Array's of instances is not a current feature of the Verilog
language. It is a new feature proposed by OVI in their LRM 2.0a. The
way I read the original question was that Richard wanted some insight
into the syntax of the proposed feature.
By the way, Richard sent me some email, but I am unable to respond to him.
When I mail to ric...@hotfoot.sps.mot.com my mailer responds with:
----- Transcript of session follows -----
421 Host hotfoot not found for mailer ether.
550 ric...@hotfoot.sps.mot.com... Host unknown
----- Unsent message follows -----
Received: by motsps.sps.mot.com (4.1/SMI-4.1/Email-2.1)
id AA08541; Wed, 16 Feb 94 10:28:55 MST
Received: from mailgate.cadence.com by spsgate.sps.mot.com (4.1/SMI-4.1/Email 2.1 10/25/93)
id AA22449; Wed, 16 Feb 94 10:19:07 MST
If Richard is listening, please send email with a better address or call me.
/Steve
Steven Greenberg; x6231
> Can you tell us if Cadence has implemented or plans to implement this feature?
> Chronologic Simulation
I am sorry that I don't have the answer to this question. I'll try to follow it
up with our marketing and R&D Management to see if I can get an answer.
George Lippincott
>Can you tell us if Cadence has implemented or plans to implement this feature?
>Currently, the IEEE 1364 working group is deciding what parts of the OVI LRM
>2.0 should be included in the draft standard, and arrays of instances is
>not being considered because no one has implemented them. We don't want to
>come out with a standard for which there is no compliant simulator. We also
>don't want to have anything in the standard which has not been proven to
>be implementable. To my knowledge, none of the other Verilog vendors have
>implemented instance arrays.
This seems like such a trivial feature that I can't believe you wouldn't implement
it and include it in the standard. As one previous poster already mentioned,
this feature makes it possible to write parameterized modules which are compatible
with specify blocks and SDF back-annotation.
I wish, though, that the 2.0 spec went a little further and included a way to
conditionally create instances. Generating instances using loops and conditional
statements is something that schematic entry tools have been able to do for years.
It's hard to believe that the same thing can't be done in Verilog.
--
George
Paul Menchini
In article <2j970n...@srvr1.engin.umich.edu>, btd...@engin.umich.edu (brian davis) writes:
|> I have a few questions for everybody out there.
|> I am implimenting repetitive modules (in a multiplier) in verilog,
|> and I am implimeting these modules using a structural representation.
|> This prohibits me from using the looping functionality present in Verilog,
|> and supported by Cadence because the current loop syntaxes are supported
|> for behavioral representations only. What I desire is a looping construct
|> for instantiating multiple structural modules.
|> 2). If this syntax is not yet defined, I have heard that VHDL does support
|> looping within structural models, and I may design the pre-processor
|> to take VHDL loops and convert them to multiple Verilog modules.
|> If this is the case, does anybody with experience using VHDL for
|> instantiating multiple strucural modules have any comments or
|> advice, or for that matter know the syntax for the VHDL looping?
VHDL has a generate statement, which comes in two forms:
1. "for" generate. A concurrent statement that specifies the repetitive
generation of other concurrent statements. For example,
L: for i in 1 to width generate
A: FullAdder (A(i), B(i), C(i-1), Sum(i), C(i));
end generate;
generates width instances of FullAdder.
2. "if" generate. A concurrent statement that specifies the conditional
generation of other concurrent statements. For example,
L: if i = 0 generate
A: FullAdder (A(0), B(0), Cin, Sum(0), C(0));
end generate;
generates the FullAdder only if i=0.
--Paul
Path: sod.nacto.lkg.dec.com!menchini
From: menc...@sod.nacto.lkg.dec.com (Paul Menchini)
Newsgroups: comp.lang.verilog
Distribution: world
References: <2j970n...@srvr1.engin.umich.edu>
From: menc...@sod.nacto.lkg.dec.com (Paul Menchini)
Organization: Digital Equipment Corporation
Subject: Re: Multiple Module instantiation
In article <2j970n...@srvr1.engin.umich.edu>, btd...@engin.umich.edu (brian davis) writes:
|> I have a few questions for everybody out there.
|> I am implimenting repetitive modules (in a multiplier) in verilog,
|> and I am implimeting these modules using a structural representation.
|> This prohibits me from using the looping functionality present in Verilog,
|> and supported by Cadence because the current loop syntaxes are supported
|> for behavioral representations only. What I desire is a looping construct
|> for instantiating multiple structural modules.
|> ...
|> 2). If this syntax is not yet defined, I have heard that VHDL does support
|> looping within structural models, and I may design the pre-processor
|> to take VHDL loops and convert them to multiple Verilog modules.
|> If this is the case, does anybody with experience using VHDL for
|> instantiating multiple strucural modules have any comments or
|> advice, or for that matter know the syntax for the VHDL looping?
VHDL has a generate statement, which comes in two forms:
1. "for" generate. A concurrent statement that specifies the repetitive
generation of other concurrent statements. For example,
L: for i in 1 to width generate
A: FullAdder (A(i), B(i), C(i-1), Sum(i), C(i));
end generate;
generates width instances of FullAdder.
2. "if" generate. A concurrent statement that specifies the conditional
generation of other concurrent statements. For example,
L: if i = 0 generate
A: FullAdder (A(0), B(0), Cin, Sum(0), C(0));
end generate;
generates the FullAdder only if i=0.
--Paul
Dave Rich; x6337
Let me shed a little light and some history on the subject. I was on
the OVI task force that developed the specification for arrays of
instances. This feature was also the first Verilog enhancement request
I received as a new Gateway AE back in 1987.
A large part of the Verilog language grammar comes from HILO (Same
developer). People converting from HILO to Verilog are always
supprized to learn that Verilog is missing arrays of instances, given
that the basic structural syntax is identical. I am not familiar with
Verilog internals, but it seems that this feature should be
implementable in Verilog.
Before "Top-Down" design came around, people used schematics to enter
structure and wrote Verilog models as leaf cells (i.e. no other
intanciations in their modules) Since most Verilog netlisters took
care of generating instances, enhancing Verilog to support arrays of
instances was a low priority.
With the advent of synthesis, people are abandoning their schematic
editors. Vendors are creating parameterized modules for synthesis
tools to map to. This raises the priority.
About 2 years ago, an OVI task force was created to look at a number
of Verilog enhancement requests closely related to synthesis, this
being one of them. We first looked at VHDL "GENERATE" statement. To
fully implement the GENERATE capability in Verilog, we found that it
would require many other Verilog enhancements (e.g. multi-dimensional
arrays, scoped declarations) This would heavily impact the Verilog
language.
Given the resources we had, we went back to the HILO syntax. This has
a very low impact on the language, plus is does not preclude a
GENERATE statement in the future. Also, looking at the way people use
structural looping constructs, the HILO syntax covers a large
majority of cases.
I hope the IEEE 1364 working group does not drop this enhancement from
consideration.
--
___________________________________________________________
Dave Rich tel 1-508-446-6337 email dav...@cadence.com
Cadence Design, 270 Billerica Rd., Chelmsford MA 01824-4140
"I used to have Time. Now I have Twins+1"
___________________________________________________________
John Sanguinetti
The issue that the IEEE working group has is that we are trying to get a
draft standard ready as soon as possible. Our goal is by June, which is
very aggressive. We have another goal, and that is to have an unambiguous
spec. We feel that, from first principles, if it hasn't been implemented,
the adequacy of the specification must be questioned. That is the case with
most of the 2.0 extensions. Many are good ideas, but we can't be sure
that they are adequately spec'ed and that they don't have unintended side-
effects with the rest of the language.
Arrays of instances and macro parameters are both pretty straightforward,
and I could be convinced that they should go in the spec (I don't speak
for the rest of the committee, however). However, if we did
that, we would have a spec with no compliant simulators on the market. Is
that what we want?
John Sanguinetti
Robert Brashears
>|> j...@chronologic.com (John Sanguinetti) writes:
>|>
>|> >Can you tell us if Cadence has implemented or plans to implement this feature?
>|> >Currently, the IEEE 1364 working group is deciding what parts of the OVI LRM
>|> >2.0 should be included in the draft standard, and arrays of instances is
>|> >not being considered because no one has implemented them. We don't want to
>|> >come out with a standard for which there is no compliant simulator. We also
>|> >don't want to have anything in the standard which has not been proven to
>|> >be implementable. To my knowledge, none of the other Verilog vendors have
>|> >implemented instance arrays.
>|>
>|> This seems like such a trivial feature that I can't believe you wouldn't implement
>|> it and include it in the standard. As one previous poster already mentioned,
>|> this feature makes it possible to write parameterized modules which are compatible
>|> with specify blocks and SDF back-annotation.
Instance arrays do give the ability to create parameterizable modules with
specify blocks. That alone does not give the ability to fully support
sdf backannotation.
A path could be specified
(posedge clk => (q +: d)) = (1,2);
where the width of the flip-flop is parameterizable. There is no
ability to back-annotate different values to each bit of this path.
One option to get around this is to lump all of the extra delay
associated with loading into interconnect but I would not consider
this full specify block and backannotation support.
Does the 2.0 spec address this? Maybe this is just an implementation
issue and Verilog HDL simulators other than Verilog-XL allow
annotation to each bit of a path even when not individually
specified. Seems like this impacts the PLI reference manual also
since it affects how one would retrieve path handles.
By the way, even with these issues, I am strongly for instance arrays
in Verilog.
--Robert Brashears
email rob...@cadence.com
George Lippincott
>The issue that the IEEE working group has is that we are trying to get a
>draft standard ready as soon as possible. Our goal is by June, which is
>very aggressive. We have another goal, and that is to have an unambiguous
>spec. We feel that, from first principles, if it hasn't been implemented,
>the adequacy of the specification must be questioned. That is the case with
>most of the 2.0 extensions. Many are good ideas, but we can't be sure
>that they are adequately spec'ed and that they don't have unintended side-
>effects with the rest of the language.
>Arrays of instances and macro parameters are both pretty straightforward,
>and I could be convinced that they should go in the spec (I don't speak
>for the rest of the committee, however). However, if we did
>that, we would have a spec with no compliant simulators on the market. Is
>that what we want?
I don't see any problem in having a spec with no compliant simulators
on the market. I am not aware of any VHDL simulators on the market which
support all of the constructs in VHDL-93.
I understand the point about questioning extensions which haven't been
implemented, but I am wondering why there is so much more caution with the
IEEE draft standard than there was with the 2.0 draft. Why is it that
OVI was willing to add these extensions but the IEEE working group is not?
--
George
Steven Leung
> Arrays of instances and macro parameters are both pretty straightforward,
> and I could be convinced that they should go in the spec (I don't speak
> for the rest of the committee, however). However, if we did
> that, we would have a spec with no compliant simulators on the market. Is
> that what we want?
Is it possible to have a compromise to accomodate this? Say, to have a
special section (call it advanced feature or optional/recommended
implementation) that separated from the rest and explicitly states that
that part is not required but if implemented, it should be conformed to
as specified.
Steven
--
"Life is a series of problems. ... Yet it is in this whole process of
meeting and solving problems that life has its meaning."
From "The Road Less Traveled" by M. Scott Peck
John Williams
I think instantiation arrays are not critical to Verilog. There are dozens
of Unix tools that are capable of doing the same thing ( including emacs or
vi ). I don't think there are many users who think it makes a big difference
either way.
John Williams
PS: m4 has `define statements beaten by miles.
Bob Wood
(snip)
|> > ... we would have a spec with no compliant simulators on the market. Is
|> > that what we want?
In article <CLyIy...@tandem.com>, le...@storage.tandem.com (Steven Leung) writes:
|> Is it possible to have a compromise to accomodate this? Say, to have a
|> special section (call it advanced feature or optional/recommended
|> implementation) that separated from the rest and explicitly states that
|> that part is not required but if implemented, it should be conformed to
|> as specified.
I think John was saying that by not having actually implemented the feature
in any simulator, you aren't really sure whether the suggested implementation
will turn out to be the right way to do it. I don't think you'd want to
suggest conformance to a standard that may be poorly thought out.
But I would think that the various designers of simulators could make an
intelligent decision about whether or not a particular implementation makes
sense. I think that as long as the correct people review the standard
before it's adopted, you can avoid mandating a feature that can't be
implemented well.
-- bob wood
data general corp.
leung_steven
> |> j...@chronologic.com (John Sanguinetti) wrote:
> (snip)
> |> > ... we would have a spec with no compliant simulators on the market. Is
> |> > that what we want?
>
> In article <CLyIy...@tandem.com>, le...@storage.tandem.com (Steven Leung) writes:
> |> Is it possible to have a compromise to accomodate this? Say, to have a
> |> special section (call it advanced feature or optional/recommended
> |> implementation) that separated from the rest and explicitly states that
> |> that part is not required but if implemented, it should be conformed to
> |> as specified.
>
> I think John was saying that by not having actually implemented the feature
> in any simulator, you aren't really sure whether the suggested implementation
> will turn out to be the right way to do it. I don't think you'd want to
Well, John also said (and I have quoted in my response but was snipped
out in your quote here) that
JS> Arrays of instances and macro parameters are both pretty straightforward,
JS> and I could be convinced that they should go in the spec (I don't speak
JS> for the rest of the committee, however).
If John can be convinced, I'm convinced.:) So, my interpretation of
what John said is simply: if enough people say "Yes, that is what we
want," then it can be put into the spec. (if the rest of the committe
can be convinced as well). Besides, George Lippincott already pointed
out that when VHDL-93 is passed, there is no sim. on the market compliant
to that spec. - so, it is not unprecedented.
> suggest conformance to a standard that may be poorly thought out.
Yeah, may be, i.e., may be very well thought out too (at least it is
in the OVI 2.0, i.e., already thought out at least once by people who
have interests and experiences on the subject). Given that is the choice,
I opt for a more forward-looking standard.