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.