Jonathan Sanders wrote:
> 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.
Since the behavior of macromodule is not well defined making it
definitely follow one of the existing behaviors is not going to make it
much more (backward) incomptabile, than it is currently incompatible
across simulators. The other stuff is pure extension which is also
backward compatible.
> 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
My concern is that if we add paramsets as proposed and then someone
decides to add module overloading in SytemVerilog with some different
mechanism we will have trouble reconciling the mechanisms when we merge
the languages.
Kev.
> 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 11:53:55 2004
This archive was generated by hypermail 2.1.8 : Tue Jun 22 2004 - 11:53:57 PDT