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

---------- Forwarded message ----------
Date: Fri, 18 Jun 2004 12:10:01 +0100
From: Daryl Stewart <daryl.stewart@tenison.com>
To: dwsmith@synopsys.com, Shalom Bresticker <Shalom.Bresticker@motorola.com>
Subject: Re: [sv-ec] Quick poll for AMS extension to overload modules

Hi David, Shalom,

a couple of days ago I tried to post a response to the above thread but
it bounced. I'm unable to contact any address @eda.org, even the
majordomos. I suspect my mail server is blacklisted for SPAM.

I would be most grateful if one of you could forward my comments below
to the sv-ec list.
The comments on p4 of 16 in the paramsets-v4.pdf would appear to justify
this syntax erratum.

with thanks
Daryl

 -- Original posting --

Hi Kevin,

I'm not on the AMS list (nor can I find how to subscribe!), but looking
at the LRM referenced below I notice that the syntax for module
instantiation does not allow a paramset to be referenced (7.3.2 para.1
implies it should). I would assume that the table "Syntax 7-3" should
say

module_instantiation ::=
module_or_paramset_identifier [parameter_value_assignment]
instance_list

(where module_or_paramset is italicised)
Perhaps you could pass this on to the appropriate list (or please
correct me if I'm wrong)

regards
Daryl

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

-- 
Tenison Technology
System Emulation in Software
Tel:   +44 1223 706479
Fax:   +44 1223 470030
Email:  Daryl.Stewart@tenison.com <mailto:Daryl.Stewart@tenison.com> 
Web:    www.tenison.com <http://www.tenison.com>