Re: [Iverilog-devel] state of VHDL (mixed-language) support

[Kevin C. <iv...@gr...>]

Here's some stuff for AMS -

http://cameron-eda.com/2020/06/03/rolling-your-own-ams-simulator/

If you are on the VHDL committee reflector, I posted something there 
last week on doing multi-type resolution on nets for handling power 
(which could be done in Icarus too), pasted below.

If you move the multi-type driver/receiver resolution stuff into C++ as 
a language independent thing you can use it for cosim - I used DPI in SV 
for AMS at Synopsys because the VCS crew will do nothing to support analog.

Kev.

On 2/21/2020 9:48 AM, Bryan Murdock wrote:
> I did a little internet searching to try to find out the current state 
> of VHDL (mixed-language) support in iverilog is.  It sounds like there 
> is interest and some work going on.  I'm interested in helping out 
> with that.  Any pointers on where I can start?
>
> Bryan
> https://msd.llc/
>
>
> _______________________________________________
> Iverilog-devel mailing list
> Ive...@li...
> https://lists.sourceforge.net/lists/listinfo/iverilog-devel
>
-----------------------------

(Recapping from the call)

Modeling analog using discrete techniques is not particularly difficult. 
Most analog simulators are actually an event driven framework using PWL 
signals which are discrete (just in the derivatives). The major 
differences between an analog simulator and a (classical) digital 
simulator are:

 1. Models interact during evaluation (requiring the matrix solvers).
 2. Wires carry potential and flow rather than potential or flow.

Potential and flow form a discipline as described in the Verilog-AMS LRM 
(3.6.2 Disciplines)

https://accellera.org/images/downloads/standards/v-ams/VAMS-LRM-2-4.pdf

If you want to do power calculations in a  simulator you need to have 
both potential and flow on wires, and resolve the natures independently 
(current and voltage for electrical), whatever drives a voltage needs to 
be a sink for (unbalanced) current on the net, and power is the multiple.

Combining analog and digital behavior on a net in Verilog-AMS meant 
resolving drivers from opposite ends of the type spectrum, but with VHDL 
and newer SV you can have "real number" drivers and receivers. Resolving 
logic and real-number drivers is 90% the same job as doing a full AMS 
resolution -

 1. Convert drivers to a common level (losslessly).
 2. Resolve at the common level
 3. Distribute resolved value (possibly with lossy down conversion) to
    receivers.

In a purely digital context that's the sort of thing you want to do in a 
level shifter between power domains, i.e. a logic value in -> Voltage in 
the shifter (a lossless resolution), and Voltage goes to logic on the 
output (a lossy resolution). All that is just done in the Voltage 
nature, so can work in existing simulators fairly easily. Power-domain 
designation is done through discipline sub-classing.

A secondary problem (not addressed in Verilog-AMS) is handling Xs, for 
that you want to slice the nature into 3 parts - value, certainty and 
strength. The resolution process above only applies to the value 
dimension, and the certainty aspect is just passed through the level 
shifter model. If the certainty value is defined separately in the 
driver type it is easy to handle automatically, where burying it in 
(say) a 0/1/X/Z enum makes life very hard 
(http://cameron-eda.com/2020/06/16/unnecessary-problems-x-propagation/).

The discipline annotation in Verilog-AMS was designed to work 
orthogonally to the type system and in a way that can be back-annotated 
so that existing code would still work without it. Driver conversion in 
an AMS context sometimes requires state to be saved so conversions were 
done with modules rather than functions, the selection of the module was 
determined by using a sub-classing system for the natures and a set of 
rules (7.5 in the LRM above). In VHDL you could consider drivers as 
implicit signals attached to a net, and something you can wait on 
(tidier than Verilog-AMS).


Having worked in mixed-signal simulation for many years, it has become 
apparent that there is quite a lot of similarity in the math used for 
things like "Fast-SPICE", and what you do to evaluate neural networks. 
The analog subset of VHDL is somewhat poorer than Verilog-AMS, and VHDL 
lacks the automatic boundary handling, however it is probably sufficient 
for defining neural network behavior for AI applications. Drivers in and 
out of such a description would match the real-number modeling mentioned 
above. That might make VHDL the right language for doing neural-network 
synthesis.

Neural networks and data-flow descriptions are the level above RTL, and 
having no clocks in the specification makes simulation a lot faster for 
functional verification, but synthesis can be to synchronous logic 
(correct by construction).


The upshot of that is doing the work to enable power modeling in VHDL, 
would probably give you the ability to do some interesting things in 
synthesis for low-power analog/AI applications that are currently not 
served by SystemVerilog, with the possibility of displacing the RTL 
methodology further down the line.

Kev.


------------------------------------------------------------------------

To unsubscribe from the VHDL-200X list, click the following link: 
https://listserv.ieee.org/cgi-bin/wa?SUBED1=VHDL-200X&A=1