Re: [oc] module instantiation

[John Sheahan <jrsheahan@optushome.com.au>]

On Tue, Mar 26, 2002 at 07:17:41AM -0800, jae lim wrote:
> Hello Everyone
> 
> I have some questions about the module instantiation
> in Verilog. Suppose I have three modules, the
> RANDOMGEN module, which is to generate random number,
> RANDOM, using LFSR; the second one is MODULO module,
> which is to round the RANDOM to the limited range,
> let's say the final random number out of the modulo is
> REMINDER; the third one is ARBITER module, it is used
> to implement the arbitration algorithm which will use
> the random number REMINDER generated by MODULO module.
> OK, in this case, should I instantiate the RANDOMGEN
> module in the MODULO module, and the MODULO module in
> the ARBITER module or, I should instantiate all the
> modules in the TEST_TOP, which is the highest test
> bench module?

in my opinion a top module should instantiate at most 5-10 chunks 
(ignoring pad things) (and there will alwsys be different designs)

If the top module wants to see the random or the twiddled random,
instantiate them directly.  If something else wants to share 
that sate, ditto.

If its a design feature inside of/only of interest to the ARBITER
instantiate them inside ARBITER.  don't clutter the thing
instantiating ARBITER (top here) with nneccessary detail. 

and another general rule is not to mix RTL and structural in the 
same module. 

> 
> And one more thing, how should I keep the timing? When
> the RANDOM is generated and then generate REMINDER,
> and when REMINDER is generated, then start arbitrate. 
> 

don't really understand the direction of this question. 
this is hardware. (except for power reasons), why would you not have 
random always generating,  and modulo always running, and stat always
available to arbiter whenever it wanted/needs it?

john 

> Thank you all for the help!!
> 
> Jay 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Movies - coverage of the 74th Academy Awards?
> http://movies.yahoo.com/
> --
> To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml
--
To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml