Re: AW: Strawman Ideas for SV-DC

Hello John,

I am worried this mail has become too long,
nobody will read it any more, anyway:

> 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.
So you are going for SystemVerilog-AMS (SVAMS)
(SystemVerilog + Verilog-AMS = SVAMS).

> Why would anyone want to make verilog incompatible with verilog-A/MS by
> adding redundant "analog" constructs into SystemVerilog?
In order to keep Verilog-AMS out, despite ritual lip service says the
contrary.

Psychological Reasons:
most SV experts are feeling very uneasy about the idea to integrate
"analog" things into their language. The official statement is that
"analog" features will significantly degrade simulation speed.
((remark: I do not understand this statement: users do not have to apply
these features, so nothing will be slowed down; and if they apply them,
they will have a very good reason for it.))

EDA vendors:
the momentum is behind SV, my impression is there is not much support
for Verilog-AMS right now, so I do not expect, that resources will be
allocated for SVAMS integration. Currently AMS solutions tend to go the
proprietary or GUI-based way.

> 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.
How ? Inaccurately, as you say. SV experts are mainly interested
in sequential checks with a "clock-cycle"-accurate timing.
In my opinion the vast majority of the practical AMS verification
use-cases is not addressed by this; unfortunately many potential users
of SVAMS, like system architects, analog designers, A/MS verification
engineers, test engineers or board-level designers, are not represented
in our committee.

> 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?
Yes!
The users (including me) are tired of patch-work flows, multiple syntax
rules for each tool/language, buggy and restricted interfaces and a
thousand options to set. A comprehensive and versatile SVAMS would solve
these problems.
We have a vicious circle here:
* the existing AMS-HDL implementations do not fully meet practical
  requirements and are difficult to handle, so they are rarely used
* Because they are rarely used, they are lower-priority for EDA vendors,
  so they are not extended and enhanced as required
* cycle back to first *

> Verilog-A/MS already exists and does a good job of allowing
> customers to simulate analog constructs in verilog.
Yes, absolutely, no doubt about that!

> If you want to add new "analog" approximations somewhere,
> my suggestion would be to add them to verilog-A/MS, not to SV.
I would not necessarily differentiate like this. If "mixed" features
like "cross", that can be used in the discrete Verilog-part of
Verilog-AMS, could also be used in a discrete SystemVerilog-part, that
would be SVAMS for me.

> 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.
Henry Ford once said: "if I had asked my customers, what they wanted,
they would have said a faster horse".
My experience is, that the methodology or solution is something, that
rarely comes from the customers. Users appreciate good solutions, but
unfortunately they will not lobby for them! Besides users of EDA
software rarely are involved in the buying decision. The managers in
charge of this often favor a cheap flow and this is not necessarily the
most powerful or most user-friendly one.

> Does any SV user (except dc members) really want digitized "analog" simulation
> in their SV design?
Some SV users will. But the main practical obstacle for the verification
of complex mixed-signal circuits will be: who writes all the real-value
models, that are required to replace the AMS transistor-level modules?
There are hardly resources or time left for that in my experience. And
efficient reuse from existing HDL-libraries is limited, because
generate-commands and other important HDL-features have never been fully
implemented by the EDA vendors.

Regards, Achim

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.