Re: [sv-dc] sv-dc: please have a look

Not sure what you mean by "switch-level modeling" or why you think it
will slow down simulation "significantly".

> "The problem is the further complexity of a SV compiler capable of
such modelling. "

We're here discussing this stuff because SV does not have the
capabilities required to model the hardware that folks are designing -
particularly issues related to power management and timing in digital
circuits. While those issues are essentially analog, this committee is
looking at modeling them using discrete methods which will meet users'
performance requirements (which incorporation of Verilog-AMS wouldn't do).

To put it another way: prior work on SV was related to extending the
higher levels of abstraction used for synthesis and verification, this
effort is aimed at extending the actual modeling capabilities, which
have not changed in a couple of decades (despite advances in Silicon).

Kev.

PS: I'd rather just do it all in C++ myself.

On 08/18/2010 11:39 AM, John Michael Williams wrote:
> Currently, popular verilog simulators do not handle triregs
> dependably, at least in the context of general switch-level
> modelling. There is almost no demand for switch-level
> simulation among digital designers, and the additional
> features would slow down the simulation significantly.
>
> Design of digital library components generally is not
> in verilog, but in other languages such as ALF or Liberty,
> so switch-level verilog, including the trireg, has been
> bypassed in the area in which it might be most useful.
>
> Verilog-A/MS permits compilation of SPICE subckt instances,
> and I think the piecewise linear modelling available
> in SPICE would solve all capacitive or timing delay
> problems to which you are alluding. The problem is the
> further complexity of a SV compiler capable of such
> modelling.
>
> I would suggest starting up a new "p1800.1" standard
> proposal to separate all A/MS issues from mainstream
> digital design in SV. This would allow vendors to claim
> 1800 conformance while representing analogue functionality
> as an optional enhancement.
>
> Feature creep already is a terrible burden on SV, and
> adding analogue features without restructuring the
> language would make the burden grow.
>
> Just my opinion, this last . . ..
>
> On 08/17/2010 04:01 PM, Kevin Cameron wrote:
>>
>> You should be able to implement arbitrary length hold-up on nets using
>> the driver access functions in Verilog-AMS - a sort of discrete
>> capacitor model (like trireg) - but it only works properly if you can
>> accumulate the capacitance of the net (multiple discrete models in
>> parallel would just give the behavior of the largest individual
>> instance). Resolution functions can accumulate capacitance so you get
>> more accurate behavior.
>>

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