On Wed, 16 Jun 2004, Shalom Bresticker wrote:
> Kevin,
>
> I read the section on paramsets and as a first-time reader of that section,
> I would not interpret it to say that it does what you say it does. If your
> description is correct, then either you worded it unclearly or section 7.3 needs
> to be rewritten to describe it as you do.
>
I agree, my original impression was that we were instantiating a module
and then locating a paramset for it, but it transpired (discussing it with
Geoffrey - the proposer) that the paramset is actually more like an
overloaded macromodule.
> Specifically about module overloading, Verilog has the 'configuration'
> mechanism, which is maybe what Brad was trying to refer to. (Brad mentioned
> SV 3.1a 23.2, but maybe he meant 22.2). However, neither the configuration
> mechanism nor generates, nor even their combination seems to allow to you to
> choose a different version of the SAME module depending on parameter values.
>
> Shalom
I'm not familiar with the configuration mechanism - but I'd be glad to
hear how it could be used to solve the problem:
The problem is how do we select the right transistor model depending on
instance parameters (length, width, fingers etc.), and we would like to be
able to add more special cases at any time without rewriting much code.
Kev.
>
>
> Kevin Cameron wrote:
>
> > There is a proposal in the latest draft AMS LRM for "paramsets" (sec. 7.3):
> >
> > http://www.eda.org/verilog-ams/htmlpages/public-docs/AMS-LRM-2-2-draft-e.pdf
> >
> > What this does is allow different modules to be selected for a given
> > instance depending on the instance parameters, i.e. the paramset name is
> > treated as being like a module name, and there are multiple paramsets
> > with the same name - one is selected according to the instance
> > parameters and its associated module wil be instantiated. There is
> > nothing about this functionality that restricts it to analog usage.
> >
> > In my opinion this is just a very specific case of module overloading,
> > and it might be better to use a more general syntax which would allow
> > extension into module overloading based on port types.
> >
> > So my question is: would you prefer to have paramsets for module
> > overloading or a more general extension of the [macro]module syntax to
> > perform the task?
> >
> > Bear in mind: Verilog-AMS will be merged with SV at some point in the
> > future, so if the SV-EC decides to add module overloading by a
> > different mechanism we could end up with multiple mechanisms that might
> > not be reconcilable.
> >
> > Kev.
>
> --
> Shalom Bresticker Shalom.Bresticker @freescale.com
> Design & Reuse Methodology Tel: +972 9 9522268
> Freescale Semiconductor Israel, Ltd. Fax: +972 9 9522890
> POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 5441478
>
> [ ]Freescale Internal Use Only
> [ ]Freescale Confidential Proprietary
>
>
>
Received on Wed Jun 16 09:40:27 2004
This archive was generated by hypermail 2.1.8 : Wed Jun 16 2004 - 09:40:31 PDT