Re: SV, packages, and statistical block in paramset proposal

J.A. Barby wrote:

>Kevin,
>
>Last night and this morning in trying to get our minds around
>alternative ways to specifiy the statistical stuff associated the
>paramsets and keep it all in one place. One idea that was mentioned
>was VHDL-like packages which SystemVerilog is looking at may be an
>alternative. Will SystemVerilog have the equivalent of VHDL library
>and use statements?
>
>
SV will probably have something like packaages eventually - but I'm not
sure how that helps with what you are trying to do.

>You have read the paramset document. One of the big issue is the
>statistical stuff where some things are one random number call per
>simulation shared by all devices while others for mismatch have a
>random number call per instance. All these map into parameters.
>I have skimmed through section 18.2 in the SystemVerilog_3.1a.pdf LRM
> http://www.eda.org/sv/SystemVerilog_3.1a.pdf
>entitled Packages. What is your take on using packages for setting up
>the statistical block for process/devices data? Will this be cleaner than
>any language extension to handle random number calls in assigning
>parameter/constant values?
>
>Jim
>
>
A question in my mind is how much needs to be in the language? A lot
of it can be done with attributes if most of the work is being done by
the simulator.

If you want to give a lot of control to the user within the language
then I think you need to add a mechanism for calling user functions
that can modify the parameters of an instance when it is created - e.g.
add "generate" functions and bind them to the module:

       module foo;
          real parameter p1,p2;
          ...
       endmodule

       generate function foo::tweak; // called when foo is instantiated
but before its children
          defparam p1 = $global_dist(p1); // PLI call
          defparam p2 = $local_dist(p2);
       endfunction

Distribution information can be held in the generate functions or as
attributes on the parameters.

Since a paramset is just a subclass of a module the generate functions
would apply to the paramset the same way as to the base module, i.e. the
generate functions would be inherited, and you could have more than one
generate function per module. If you declare the generate function in
the module or a paramset you can omit the <module name>:: since it will
be implied.

Just a thought :-)

Kev.

-- 
Altera Corp, 101 Innovation Drv, San Jose, CA 95134. T# (408) 544 7126