RE: hierarchical parameter passing in DC sweep

Hi Arpad,

This situation exists in Verilog-AMS also and its been very difficult once people have implemeted features in their toolset and we are trying to fit it into LRM. Once its raised as a proposal/extension to be added to LRM, people want to make sure it is consistent and sometimes it become very difficult for people to compromise because of customers that need to be supported, backward compatibility in their tools etc.

But given the reality of the situation, any implementation done outside the LRM, which is planned to be added to the language at a later date needs to be done with an understanding that this feature that they are delivering in the tool may not be compatible with current implementation of the vendor. But that isnt always the case.

Regards,
Sri

-----Original Message-----
From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On Behalf Of Muranyi, Arpad
Sent: Wednesday, 24 August 2005 4:02 AM
To: Verilog-A Reflector
Subject: RE: hierarchical parameter passing in DC sweep


Kevin,

That is perfectly fine and understood.  I was just talking about tool "features" which never make it into the LRM (i.e. non-compliance).

However, talking about experience in IBIS, there is a problem with this some times.  A tool vendor may implement something their own way before the LRM has it.  Then the LRM people start thinking and discover a bunch of compatibility, and consistency issues, and write it up slightly differently. Then the tool vendor says, we don't want to change it any more, because we already have such and such an amount of models written this way, and we don't want to start over again...

Arpad ===============================================================

-----Original Message-----
From: Kevin Cameron [mailto:kevin@sonicsinc.com] 
Sent: Tuesday, August 23, 2005 10:42 AM
To: Muranyi, Arpad
Cc: Verilog-A Reflector
Subject: Re: hierarchical parameter passing in DC sweep


...
...

Most of the stuff that gets put into LRMs at Accellera and the IEEE is originally non-standard extension done by vendors, so it's not unusual for support to be inconsistent for "new" features.

The committee's job to a large extent is to look at proposed extensions and merge them into the LRM in clean and extensible ways - which is generally easier if you have an implementation you can try out. Since some ideas don't work that well in practice it's better for someone to try them out first, also, the fact that someone has spent resource on adding a feature implies that it is actually needed.

...
...