Re: [sv-dc] Disciplines from AMS

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

-- 
      John Michael Williams
      Senior Adjunct Faculty
Silicon Valley Technical Institute
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.