Re: [sv-dc] Disciplines from AMS

Which companies involved in this effort do not have both simulators? (I have neither)

The Verilog-AMS stuff is in use and should take precedence given that backward compatibility will be required.

NB: Disciplines by themselves have nothing to do with continuous time modelling, they are just an attribute scheme that gets used to direct type conversions and connectivity rules.

Kev.

On 02/07/2011 02:34 PM, John Michael Williams wrote:
> Hi All.
>
> I'm very much in favor of avoiding conflicts, but I would
> like the AMS aspects to be worked upon by IEEE as an explicit
> branch from SV, perhaps as Std 1800.1 or something similar.
>
> SV as described by Std 1800 already is very big and complex,
> and an unstructured inclusion of analogue compatibility,
> rather than a more structured approach, would make it
> more, not less, complex.
>
> Complexity risks user disagreement and ambiguity.
> For example, including Verilog-AMS without structural
> boundaries would make the continuous-time simulator
> very difficult to implement -- I think that assertions
> alone would be a difficult task.
>
> On 02/07/2011 01:58 PM, Little Scott-B11206 wrote:
>> Hi Sundaram and Abhi:
>>
>> Yes, I think we are all in agreement there. We don't want to complicate the future SV-VAMS merger. What isn't within our scope is to start the merger. We should be aware that disciplines exist and as such not propose a similar yet different solution to that problem.
>>
>> Thanks,
>> Scott
>>
>>> -----Original Message-----
>>> From: Sangameswaran, Sundaram [mailto:suam@ti.com]
>>> Sent: Monday, February 07, 2011 3:53 PM
>>> To: 'Abhi Kolpekwar'; Little Scott-B11206
>>> Cc: Kevin Cameron; sv-dc@eda.org
>>> Subject: RE: [sv-dc] Disciplines from AMS
>>>
>>> I am in agreement with Abhi. We have to make sure there are no future
>>> conflicts or complication.
>>>
>>> Regards
>>> sundaram
>>>
>>> -----Original Message-----
>>> From: owner-sv-dc@eda.org [mailto:owner-sv-dc@eda.org] On Behalf Of
>>> Abhi Kolpekwar
>>> Sent: Monday, February 07, 2011 3:19 PM
>>> To: Little Scott-B11206
>>> Cc: Kevin Cameron; sv-dc@eda.org
>>> Subject: RE: [sv-dc] Disciplines from AMS
>>>
>>> Hi Scott,
>>>
>>> My thoughts -
>>>
>>> While it may be difficult to bring in AMS extensions (like disciplines)
>>> directly in the scope of SV-DC work, I think it is still very important
>>> for us to make sure we keep the door open for these and avoid creating
>>> any conflicts with future possibilities.
>>>
>>> The AMS extensions can act as guiding points for SV-DC proposal. For
>>> e.g. As Kevin stated, the disciplines in AMS are used to annotate
>>> properties that can be used to define a supply sensitivity of a given
>>> net. The SV-DC proposal should allow for this possibility and avoid
>>> embedding supply sensitivity information directly into SV net types as
>>> this can complicate SV-AMS work down the line.
>>>
>>> Thanks,
>>> Abhi
>>>
>>> +-----Original Message-----
>>> +From: owner-sv-dc@eda.org [mailto:owner-sv-dc@eda.org] On Behalf Of
>>> +Little Scott-B11206
>>> +Sent: Monday, February 07, 2011 1:37 PM
>>> +To: Kevin Cameron; sv-dc@eda.org
>>> +Subject: RE: [sv-dc] Disciplines from AMS
>>> +
>>> +Hi Kevin:
>>> +
>>> +Yes, I object. The work currently being discussed in SV-DC must be
>>> +finished by Oct. 1, 2011. The merger between SV and VAMS will not be
>>> +completed in that time, so we should not assume anything from that
>>> +merger will be available to us. It is not within the scope of SV-DC
>>> to
>>> +do any merger work, so we should not consider adding disciplines to SV
>>> +as part of our work.
>>> +
>>> +Thanks,
>>> +Scott
>>> +
>>> +> -----Original Message-----
>>> +> From: owner-sv-dc@eda.org [mailto:owner-sv-dc@eda.org] On Behalf Of
>>> +> Kevin Cameron
>>> +> Sent: Monday, February 07, 2011 12:57 PM
>>> +> To: sv-dc@eda.org
>>> +> Subject: [sv-dc] Disciplines from AMS
>>> +>
>>> +>
>>> +> From the last AMS meeting it seems like there is a fairly strong
>>> +> commitment to bringing the Verilog-AMS stuff into SV sooner rather
>>> +than
>>> +> later.
>>> +>
>>> +> The disciplines section of Verilog-AMS is fairly independent, and is
>>> +> a useful framework for adding attributes to nets. Does anybody have
>>> +> an objection to assuming that it is available for the SV-DC work?
>>> +>
>>> +> Disciplines are the correct place to put attributes about Vdd/Vss,
>>> +> logic thresholds and other technology dependent info. It's useful
>>> for
>>> +> adding rules about what things can/cannot be connected, e.g. generic
>>> +> types like wreal can also be marked as having a discipline, and nets
>>> +> can only
>>> +have
>>> +> one base discipline, so you can avoid accidentally connecting an
>>> +> electrical wire to a fiber-optic, or a 1V logic to a 2V logic (by
>>> +> connect rules).
>>> +>
>>> +> Kev.
>>> +>
>>> +>
>>> +> --
>>> +> This message has been scanned for viruses and dangerous content by
>>> +> MailScanner, and is believed to be clean.
>>> +>
>>> +
>>> +
>>> +
>>> +--
>>> +This message has been scanned for viruses and
>>> +dangerous content by MailScanner, and is
>>> +believed to be clean.
>>> +
>>>
>>>
>>> --
>>> This message has been scanned for viruses and
>>> dangerous content by MailScanner, and is
>>> believed to be clean.
>>>
>>>
>>
>>
>>
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.