Re: [sv-dc] Disciplines from AMS

Hi,

I think the disciplines might be a good place to store general DEFAULT
values,
e.g. for supply sensitivity or relative thresholds.
But they are no substitute for associating e.g. supply sensitivity directly
with SV net types,
because this association in practice is highly SPECIFIC;
e.g. a certain SV port "real_value_signal_out" might be associated with
another real value (supply) port "VDD_low",
which might be given by the function: t * c/T for t<T and c for t>=T
and in practice two instances of the same module often not even have the
same supply voltages.

Achim

----- Original Message -----
From: "Abhi Kolpekwar" <abhijeet@cadence.com>
To: "Little Scott-B11206" <B11206@freescale.com>
Cc: "Kevin Cameron" <edaorg@v-ms.com>; <sv-dc@eda.org>
Sent: Monday, February 07, 2011 10:19 PM
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.