generic parameter while instantiating design at top level if allowed

[sky_above]

Can a module be instantiated with a generic variable for parameter value as done in the following codes for the instances
multiplier #(k) multiplier0, divider #(v) divider0, block_p #(k,v) block_p0?

Here multiplier0 is the instance of multiplier module whose rtl has a parameter named z inside it. The block_p0 is the instance of a module named block_p whose rt has two parameter named u and x inside it. The divider0 is also an instance of a module named divider whose rtl also has a paramer declared.

module toplevel (.....);

parameter k =6;
parameter v=9;

input .......
output ......
reg ..........


multiplier #(k) multiplier0

divider #(v) divider0

block_p #(k,v) block_p0

............

endmodule

 

[pancho_hideboo]

Can a module be instantiated with a generic variable for parameter value as done in the following codes for the instances
multiplier #(k) multiplier0, divider #(v) divider0, block_p #(k,v) block_p0?

Yes.
However "defparam statements" are used in general.

http://fullchipdesign.com/verilog_defparam.htm
http://www.asic-world.com/verilog/para_modules1.html

 

[ads-ee]

Yes.
However "defparam statements" are used in general.

http://fullchipdesign.com/verilog_defparam.htm
http://www.asic-world.com/verilog/para_modules1.html

No defparam has been depricated it is not the recomended method of setting parameters for modules

 

[pancho_hideboo]

No defparam has been depricated
it is not the recomended method of setting parameters for modules

I don't think so.

"defparam" have many merits than instance parameter.

 

[ThisIsNotSam]

I don't think so.

"defparam" have many merits than instance parameter.

I haven't seen anyone use it in the last few years. defparam is not a thing anymore. which is great, it was always messy.

 

[ads-ee]

I haven't seen anyone use it in the last few years. defparam is not a thing anymore. which is great, it was always messy.

Not just messy how about code breaking...

A defparam can be define ANYWHERE in any portion of code, so a defparam in another file that was mistakenly copied into another file can override the defparam you wanted defined. If you have multiple defparams for the same parameter in the same file then the last one takes precedence. There are many ways to abuse this and cause design failures and wasted time.

Pancho maybe you should read this. Cummings has been a part of the working groups that define the language, so if you don't want to take my word for it, then take his word for it. defparam IS deprecated (see bottom of pg 5).

Using passed parameters with named association is a much better approach.

 

[dave_59]

Agreed, but the IEEE standard is the last word. Section C.4.1 Defparam statementsIt says defparam has been identified for depreciation, which is not the same IS deprecated. The reason is that the SystemVerilog committee is unlikely to completely remove features that would make existing working code inoperable. Features that actually get deprecated are ones that no one ever implemented, or had too many problematic issues to make it work.

 

[ads-ee]

thanks dave, I'll admit I didn't check the exact wording in the LRM, but I tend to switch to newer (usually better) techniques once tools catch up and especially if something has been "identified for depreciation".

Even if it isn't deprecated but only identified for depreciation I'd still avoid using it as it's is messy and can get you in trouble (first hand experience, i.e. running a long simulation (hours) that fails because someone left some "test" code with a parameter set differently than the correct value).