Re: [sv-ec] Quick poll for AMS extension to overload modules

I found a much more detailed proposal on paramsets on
http://www.eda.org/verilog-ams/htmlpages/compact.html

This is much more detailed than the information which appears in the AMS 2.2/DraftE.
If the intention of the DraftE doc is to implement the proposal doc, then it needs
much
more detail. Currently DraftE simply does not implement what the proposal says.
I think copy-paste of most of it, with only minimal editing, would suffice.

Shalom

I think
Kevin Cameron wrote:

> 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
> >
> >
> >

--
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