Recursive module instantiation - tool support?

A

Allan Herriman

Guest
Hi,

I have an application that can be coded quite elegantly using
recursive module instantiation (i.e. my module will instantiate
itself, and there will be a generate statement that will stop it at
some point).

Recursive instantiation seems to be allowed by the LRM.

Question: Will I have any problems with tool support?


BTW: this is tail-end recursion, and I can convert it to a
generate-for loop if I have to.

Thanks,
Allan.
 
Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in message news:<41tp60hnmkt7n5n7qf6f3u0qvp9o7m1npr@4ax.com>...
I have an application that can be coded quite elegantly using
recursive module instantiation (i.e. my module will instantiate
itself, and there will be a generate statement that will stop it at
some point).

Recursive instantiation seems to be allowed by the LRM.
The IEEE working group is in agreement that it should be allowed,
and the next version of the LRM will probably say so explicitly.

Question: Will I have any problems with tool support?
NC-Verilog supports it, and a number of other vendors are at
least aware of the possibility.

BTW: this is tail-end recursion, and I can convert it to a
generate-for loop if I have to.
You might want to convert it, for several reasons. Debugging
could become awkward with this kind of long chain in your
hierarchy (think of how long the hierarchical name of the
bottom instance would be, with a long tail-recursion). If you
want to debug instance 17 in the chain, it is a lot easier to
type in a subscript of 17 than trying to count 17 repetitions
of the hierarchy for each level. NC-Verilog has a maximum
depth allowed for the hierarchy, to catch infinite recursion,
which you might run into for a large value with tail-recursion.
Other tools might have something similar. And of course there
is the issue with tool support for recursion.

I would suggest reserving recursive instantations for situations
where there is no good alternative, such as treelike structures.
 
On 5 Apr 2004 13:45:15 -0700, sharp@cadence.com (Steven Sharp) wrote:

Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in message news:<41tp60hnmkt7n5n7qf6f3u0qvp9o7m1npr@4ax.com>...

I have an application that can be coded quite elegantly using
recursive module instantiation (i.e. my module will instantiate
itself, and there will be a generate statement that will stop it at
some point).

Recursive instantiation seems to be allowed by the LRM.

The IEEE working group is in agreement that it should be allowed,
and the next version of the LRM will probably say so explicitly.

Question: Will I have any problems with tool support?

NC-Verilog supports it, and a number of other vendors are at
least aware of the possibility.

BTW: this is tail-end recursion, and I can convert it to a
generate-for loop if I have to.

You might want to convert it, for several reasons. Debugging
could become awkward with this kind of long chain in your
hierarchy (think of how long the hierarchical name of the
bottom instance would be, with a long tail-recursion). If you
want to debug instance 17 in the chain, it is a lot easier to
type in a subscript of 17 than trying to count 17 repetitions
of the hierarchy for each level. NC-Verilog has a maximum
depth allowed for the hierarchy, to catch infinite recursion,
which you might run into for a large value with tail-recursion.
Other tools might have something similar. And of course there
is the issue with tool support for recursion.

I would suggest reserving recursive instantations for situations
where there is no good alternative, such as treelike structures.
Thanks Steve,

I ended up coding it using iteration.

I didn't establish whether XST could handle the recursion, because the
Xilinx project manager gave errors while trying to extract the
hierarchy!

A demo version of Modelsim seemed to handle it ok. Icarus Iverilog
couldn't, but that seems to be because of an inability to handle
generate statements rather than anything to do with recursion.

Regards,
Allan.
 
Allan Herriman wrote:

Icarus Iverilog
couldn't, but that seems to be because of an inability to handle
generate statements rather than anything to do with recursion.
Correct.

And absent generate statements, any recursive module instantation
is infinite, so it explicitly disallows that, too. Unless someone
can tell me why I'm wrong:)
--
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
 
On Wed, 07 Apr 2004 11:52:52 -0700, Stephen Williams
<spamtrap@icarus.com> wrote:

Allan Herriman wrote:

Icarus Iverilog
couldn't, but that seems to be because of an inability to handle
generate statements rather than anything to do with recursion.

Correct.

And absent generate statements, any recursive module instantation
is infinite, so it explicitly disallows that, too. Unless someone
can tell me why I'm wrong:)
I would have said implicitly rather than explicitly.

Steve, are you planning to add Verilog 2001 support (e.g. generate)
to Icarus?
Even the low cost synthesisers (e.g. XST) support it properly now.

Thanks,
Allan.
 
Allan Herriman wrote:

Steve, are you planning to add Verilog 2001 support (e.g. generate)
to Icarus?
Even the low cost synthesisers (e.g. XST) support it properly now.
It's a matter of finding development time. I am planning to add
it, certainly, but it is not a small job. But I too noticed that
XST supports it, and if even XST supports it, it's time has come:)

I'm hoping to find time to make a 0.8 release so that I can
put to rest a lot of support issues and get moving again on
new development.


--
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."
 
On Wed, 07 Apr 2004 23:03:02 -0700, Stephen Williams
<spamtrap@icarus.com> wrote:

Allan Herriman wrote:

Steve, are you planning to add Verilog 2001 support (e.g. generate)
to Icarus?
Even the low cost synthesisers (e.g. XST) support it properly now.

It's a matter of finding development time. I am planning to add
it, certainly, but it is not a small job. But I too noticed that
XST supports it, and if even XST supports it, it's time has come:)

I'm hoping to find time to make a 0.8 release so that I can
put to rest a lot of support issues and get moving again on
new development.
Thanks Steve. I'm sure everyone in c.l.v appreciates the effort you
put in to Iverilog.

Regards,
Allan.
 
Stephen Williams <spamtrap@icarus.com> wrote in message news:<758cd$40744e06$40695902$19930@msgid.meganewsservers.com>...
And absent generate statements, any recursive module instantation
is infinite, so it explicitly disallows that, too. Unless someone
can tell me why I'm wrong:)
It might be possible to use Verilog-2001 configs to terminate the
recursion also, by binding the last instance to a different
module definition that doesn't instantiate the module again.

But in Verilog-1995, I don't see any way recursive instantiation
could be finite.
 
We sure appreciate this great simulation, synthesis ... tool :)

Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in message news:<66r970hl3588ikvmqg8vgsie55he2uua39@4ax.com>...
On Wed, 07 Apr 2004 23:03:02 -0700, Stephen Williams
spamtrap@icarus.com> wrote:

Allan Herriman wrote:

Steve, are you planning to add Verilog 2001 support (e.g. generate)
to Icarus?
Even the low cost synthesisers (e.g. XST) support it properly now.

It's a matter of finding development time. I am planning to add
it, certainly, but it is not a small job. But I too noticed that
XST supports it, and if even XST supports it, it's time has come:)

I'm hoping to find time to make a 0.8 release so that I can
put to rest a lot of support issues and get moving again on
new development.

Thanks Steve. I'm sure everyone in c.l.v appreciates the effort you
put in to Iverilog.

Regards,
Allan.
 

Welcome to EDABoard.com

Sponsor

Back
Top