Re: AW: Strawman Ideas for SV-DC

On 07/14/2010 12:09 PM, Achim Bauer wrote:
>
> Hi John,
>
>> John:> Why not simply adopt (maybe by stages) the Accellera Verilog-A/MS
> Std?
> What aspects do you mean, are you thinking of the connect module insertion ?

ALL of them! Including execution in continuous time.

Why would anyone want to make verilog incompatible with verilog-A/MS by
adding redundant "analog" constructs into SystemVerilog?

How could a verilog-A/MS always block with SV "analog" constructs
be simulated in verilog-AMS? The digital kernel would be adding
inaccurate digitizations which should be run by the continuous-time
kernel.

It seems to me that an SV simulator which could simulate analog
constructs would have to have an option to turn off all SV
constructs, to to permit pure verilog, only, so that verilog-A/MS
would run correctly. A simpler solution would be to import
verilog-A/MS stage-by-stage into SV, so that an SV simulator
could turn on verilog-AMS features as an option.

Don't you think that customers are getting sick and tired of
trying to use SV, when there isn't any such thing, just a
moving target of incompatible tools trying to keep up
with runaway standards ideas?

Verilog-A/MS already exists and does a good job of allowing
customers to simulate analog constructs in verilog.

If you want to add new "analog" approximations somewhere,
my suggestion would be to add them to verilog-A/MS, not to SV.

At least, instead of discussing the "straw" ideas in a private
group which forbids voting by anyone but a select few, try
soliciting ideas among the SV customer base. Does any SV user
(except dc members) really want digitized "analog" simulation
in their SV design? The demand for verilog-A/MS is even weaker
at present than that for SV, so I would guess that hardly anyone
would benefit -- and every SV tool would become riskier to use, with
further "analog" constructs to support and debug.

>
>> John:> You would not want a simulation kernel which included analog
> scheduling.
> Absolutely, no "analog" scheduling is required indeed, just event-based
> steps.
>
>> John:> anyway: It would be very bad for digital performance.
>
> If a mixed-signal(real-value) verification needs custom resolution with
> powerful datatypes
> and the user is not supplied with these features, a fast, but evtl.
> meaningless
> simulation does not help very much.
> The simulation must be skipped (which is even faster ;)
> and certain aspects will stay unverified.
>
> Regards,
> Achim
>
>

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