RE: call for participation in SV-DC

Hi Ken:

I can give you my interpretation of what they mean. I presume that
Kevin may have different/additional ideas.

PWL support to me means a succinct way to specify a piecewise linear
waveform onto a net. Maybe a simple function that can be assigned to a
net with arguments of final value and the time required to get there
(yes, I have something like the Verilog-AMS transition() in mind).
There could be several variants of the function. I am not sure which
variants are the most natural.

Cross-type driver resolution to me means providing a method to resolve a
net of one type onto a port of another type (e.g., a real net onto a
logic port).

Thanks,
Scott

-----Original Message-----
From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On
Behalf Of Bakalar, Kenneth
Sent: Monday, May 17, 2010 11:27 AM
To: Little Scott-B11206
Cc: verilog-ams@eda.org
Subject: RE: call for participation in SV-DC

Hi Scott,

Could you elaborate on what you mean by PWL support and cross-type
driver resolution? I want to take up the challenge of building these on
top of the ADMS_signals package. It may be that it not too ugly.

Best Regards,
Ken

-----Original Message-----
From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On
Behalf Of Little Scott-B11206
Sent: Monday, May 17, 2010 12:11 PM
To: Kevin Cameron
Cc: verilog-ams@eda.org
Subject: RE: call for participation in SV-DC

Hi Kevin:

Yes, when I say "we" I presume I speak for the others at Freescale.
John Havlicek and I are currently the primary Freescale drivers on this
topic. We have had discussions with Sri and Dave Miller. The
trajectory seems to have general agreement. Sri, Dave if I am wrong
please let me know.

Maybe I am not communicating clearly what I mean by first class. We
advocating for a solution that allows for more generic net types. It
seems like having nets that carry real values as well as more complex
data types (e.g., structs) will be useful. With this addition we would
like to see user defined resolution functions. If vendors decide to
provide libraries of commonly used resolution functions that is up to
them.

Yes, Mentor seems to have covered the basic functionality we desire for
real signals with their ADMS_signals package. We would like to make
that type of functionality directly available in the language. To
effectively provide features like PWL support and cross-type driver
resolution it seems to me that we need generic net features directly
supported in the language instead of attempting to build on top of a
"generic signals" package.

Thanks,
Scott

-----Original Message-----
From: Kevin Cameron [mailto:edaorg@v-ms.com]
Sent: Friday, May 14, 2010 4:17 PM
To: Little Scott-B11206
Cc: verilog-ams@eda.org
Subject: Re: call for participation in SV-DC

"We prefer to have first class language constructs" We == Freescale?

I prefer the approach of having a generic/user-defined scheme. You can
put the particular types you want to optimize in a standard header file
and have the simulators recognize them - that's generally how VHDL does
things, and as someone who builds simulators I can say that there will
be no impact on performance. Given that the Cadence proposal had a bunch
of different real-value resolution schemes, making them all "first
class" is not a good way to evolve the language. As an interim measure
you can restrict the "recognized" user-defined types to those in the
standard header.

On timescale: it seems that Mentor have already covered real-valued
signals with their SV/ADMS_signals approach, I would suggest accepting
that methodology and moving on to more difficult problems like PWL
support and cross-type driver resolution.

Kev.

On 05/14/2010 11:12 AM, Little Scott-B11206 wrote:
> Hi Kevin:
>
> The Mentor proposal describes a package that can be created in
> SystemVerilog today. We prefer to have first class language
constructs
> supporting this type of functionality within SystemVerilog and as a
> result eventually SystemVerilog-AMS. We believe it makes sense to
> develop these features in SystemVerilog as they are the responsibility
> of the discrete simulator.
>
> You are correct that just adding the real valued nets doesn't solve
the
> entire problem (actually, more generic net types such as structs would
> also be useful). Once the capability to create real valued nets is in
> place, additional capabilities are needed to be able to use the nets
> effectively. PWL signal support is certainly one item that fits on
the
> list of important companion features.
>
> We need to consider the overall vision, but our immediate concern is
> defining work that can be completed by October 2011. Adding real
valued
> and generic nets to SystemVerilog is likely a big enough job that we
> have decided to focus on that aspect of the problem in the near term.
> This is the type of discussion that we expect to happen in the initial
> meetings of the SV-DC committee. We hope you will attend and
> contribute.
>
> Thanks,
> Scott
>
> -----Original Message-----
> From: Kevin Cameron [mailto:edaorg@v-ms.com]
> Sent: Friday, May 14, 2010 12:03 PM
> To: Little Scott-B11206
> Cc: verilog-ams@eda.org
> Subject: Re: call for participation in SV-DC
>
>
> Why is this not being tackled as the addition of user-defined
(discrete)
> types?
>
> We already have proposals in that area -
>
> http://www.vhdl.org/verilog-ams/hm/3029.html
> http://www.vhdl.org/verilog-ams/hm/3038.html
>
> Just adding "real valued" nets leaves a bunch of problems unaddressed.
>
> Also, analog behavior can (in a lot of cases) be described by
piecewise
> linear waveforms, which are also discrete (in the first derivative)
and
> don't require the use of an analog solver (which is what slows down
the
> simulator). PWL signals are the preferred interface type for getting
in
> and out of the analog domain.
>
> So I think you might want to target this WG at adding user defined
types
> and PWL signal support.
>
> Kev.
>
> On 05/14/2010 07:32 AM, Little Scott-B11206 wrote:
>
>> Hi Folks:
>>
>> The IEEE P1800 (SystemVerilog) Working Group has organized an ad hoc
>> committee, SV-DC (SystemVerilog Discrete Committee), to study and
work
>> on
>> the addition of discrete domain real modeling capabilities to the
>> SystemVerilog language.
>>
>> Discrete domain real models are efficient behavioral abstractions of
>>
> AMS
>
>> components that can run in a digital simulator at speeds greater than
>> Verilog-AMS components and much greater than Spice components. There
>>
> is
>
>> an immediate need for these components to improve simulation
>>
> performance
>
>> for larger mixed models of units, platforms, and systems. A common
>>
> use
>
>> case is to swap out a continuous domain (Spice or Verilog-AMS) model
>> with a discrete domain (SystemVerilog real) model. Various
>>
> verification
>
>> analyses should be used to ensure sufficient correlation between the
>> models being swapped and to validate that the tradeoff between speed
>>
> and
>
>> accuracy is acceptable.
>>
>> The addition of discrete domain real modeling capabilities to
>> SystemVerilog will involve problems like the following:
>>
>> - Provision of real and generic ports and nets.
>>
>> - Connection of entities of mixed types (real to logic, real to
>>
> integer,
>
>> etc.) using appropriate type conversion mechanisms.
>>
>> - Connection of entities of mixed domain (real to electrical, etc.)
>> using appropriate domain conversion mechanisms.
>>
>> - Specification of resolution mechanisms for multiple drivers of real
>> and generic types.
>>
>> Swapping a continuous domain model for a discrete domain model
>>
> involves
>
>> technical details from both domains. Therefore, this work needs to
>> align with a vision for the eventual merging of SystemVerilog and
>> Verilog-AMS. For these reasons, it is important to have both
>> SystemVerilog and Verilog-AMS experts involved in SV-DC.
>>
>> The first assignment given to the committee is to develop a statement
>>
> of
>
>> the scope of the work that can be accomplished within the current
>> SystemVerilog PAR (work closes in October 2011). This is a small
>> window, but we believe we can produce useful capabilities that are
>> aligned with a broader vision for completing the work. The scope
>> description is due to the P1800 Working Group on 2010-05-27.
>>
>> The initial meeting of the SV-DC will be for two hours on Tuesday,
May
>> 18th at 10:00 CDT (UTC-05:00) to begin a discussion of the scope.
>> Dialin information is below.
>>
>> Thanks,
>> John & Scott
>>
>>
>> Dialin information:
>> -------------------
>>
>> Country Number
>>
>> AUSTRALIA 1800009128
>> AUSTRIA 0800291873
>> BELGIUM 080077334
>> CANADA 8008671147
>> CHINA TELECOM (CT) 108001400732
>> CHINA NETCOM (CNC) 108007140759
>> DENMARK 80703159
>> FINLAND 0800770233
>> FRANCE 0800941695
>> GERMANY 08001014519
>> GREECE 0080016122039738
>> HONG KONG 800933578
>> HUNGARY 0680017180
>> INDIA 000 800 650 1482
>> INDONESIA 008800105607
>> IRELAND 1800944116
>> ISRAEL 1809459738
>> ITALY 800782388
>> JAPAN 00531160427
>> LUXEMBOURG 80023985
>> MALAYSIA 1800808386
>> MONACO 80093186
>> NETHERLANDS 08002658223
>> NEW ZEALAND 0800443736
>> NORWAY 80057409
>> POLAND 008001114672
>> PORTUGAL 800819106
>> RUSSIA 81080022801012
>> SINGAPORE 8001011470
>> SOUTH AFRICA 0800992835
>> SOUTH KOREA 00308140540
>> SPAIN 900967020
>> SWEDEN 0201400559
>> SWITZERLAND 0800563054
>> TAIWAN 00801126585
>> THAILAND 0018001562039684
>> UNITED KINGDOM 08005280546
>> UNITED STATES 8008671147
>>
>> Access Code: 7375405
>>
>>
>>
>
>
>

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