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

Kevin,

While the Accellera goal is to merge with SystemVerilog the goal of
SystemVerilog was to be compatible with 1364 unless someone is doing a lot
of marketing spin. So in general I think we should make sure what we do
(being the tail in the standards process) does not screw up either 1364 or
SystemVerilog without very good reasons. If we pass that general rule I
think the rest is more what is best for us and our users.

If we define a new meaning for macromodules then it must be applicable to
both the digital and analog sides or be clear to users why macromodules
behave differently in analog than digital. One of the reasons why we
created "analog functions" rather than try to treat functions differently
depending on which side used them. Of course originally we overloaded it
for Verilog-A and then got burned as we merged the two languages.

Likewise the reason we created connectmodules rather than try to make it
fit in modules or macromodules was for clarity to the standard and
especially end users. I have not read all of the appends but in some cases
we want generic solutions and in other case "application" specific
solutions. Paramsets are just enough different that I would think an
application specific approach might be the best course of action (less
confusing to analog and digital users) but I have not dug into this
one. Maybe the discussion should be which way do we go (general purpose or
application specific) and then the solution becomes easier, rather than
debating two viable and reasonable solutions?

Jon

At 10:07 AM 6/22/2004, Kevin Cameron wrote:

>Geoffrey.Coram wrote:
>>
>>Kevin Cameron wrote:
>>
>>>
>>>If the LRM says macromodules shouldn't introduce hierarchy that's good
>>>enough for me :-)
>>>
>>
>>
>>
>>Where does it say that, Kevin?
>>
>>The Verilog-AMS LRM (2.1) says only (in section 7.1) that:
>>
>> The keyword macromodule can be used interchangeably with
>> the keyword module to define a module. An implementation
>> can choose to treat module definitions beginning with the
>> macromodule keyword differently.
>>
>>which is essentially the same as what Shalom excerpted from
>>the 1364-2001 LRM.
>>
>>
>It was my understanding that macromodules don't introduce hierarchy -
>obviously an invalid assumption :-(
>>
>>Obviously, since paramsets don't exist yet, we can say that
>>they don't introduce hierarchy.
>>
>But it's just a easy to be strict about macromodules, the treatment should
>be consistent across all simulators, "An implementation can choose to
>treat module definitions beginning with the macromodule keyword
>differently." seems inappropriate for an LRM to me.
>
>NB: We are not merging with IEEE 1364 Verilog, we are merging with
>SysytemVerilog, and the original question was:
>
> Do we want to use paramsets for module overloading or do we want a
> more general mechanism for module overloading?
>
>I suggested an alternative for the sake of argument, since the
>functionality in paramsets seemed a little too narrowly focused for me,
>and module overloading seems like useful functionality. In particular, if
>at some future time we want to overload based on port types I don't want
>to have an entirely different mechanism from parameter based overloading
>for doing it.
>
>Kev.
>>
>>
>>
>>-Geoffrey
>>
>
>***********************************************************
>Jonathan L. Sanders
>Product Engineering Director
>Custom IC Solutions
>Cadence Design Systems, Inc.
>555 River Oaks Pkwy
>San Jose, CA. 95134
> INTERNET:jons@cadence.com Tel: (408) 428-5654 Fax : (408) 944-7027
>***********************************************************
Received on Tue Jun 22 10:37:37 2004