Re: [Iverilog-devel] verilogams support

[Cary R. <cy...@ya...>]

Hi Kevin,

I understand your consternation on interconnect. I need to study it more to understand exactly how it is intended to work and why extending wire was not good enough. I don't know enough of the details to say more at this time.


Icarus had wire real long before it supported wreal and wreal is still just an alias to the base wire real functionality. I agree that in open source we have some leeway regarding enhancements, but our users have an expectation that we try to follow the language standard. If this was a new simulation language then there would be much more freedom. That's not the goal of Icarus Verilog so we have some constraints set by the language definition.

Analog PWL is basically what I'm doing. The one enhancement over straight PWL is some of the models generate their output using a pseudo adaptive time step to give a specified output accuracy (e.g. a 1.0V sine wave with 1mV accuracy/steps can use different delays between the points).

Cary



________________________________
 From: Kevin Cameron <iv...@gr...>
To: Cary R. <cy...@ya...>; Discussions concerning Icarus Verilog development <ive...@li...> 
Sent: Monday, May 27, 2013 11:31 PM
Subject: Re: [Iverilog-devel] verilogams support
 



Hi Cary,

"just interconnect" is open to interpretation: I thought "wire"
      was just interconnect until Gord got his hands on it at the SV
      committee and decided it wasn't and needed to add "interconnect"
      as a new "net type". At this point I think the SV and Verilog-AMS
      versions of "wire" may be irreconcilable.

The advantage of working in open-source is that you can implement
      stuff differently so that it works right. I don't think you can do
      what you want with wreal or any discrete approach that doesn't
      incorporate derivatives. A key piece of Verilog-A[MS] is
      supporting PWL signals, but the performance issues of Verilog-A
      modeling are because of the solvers used trying to do spice-level
      accuracy - not the PWL representation (which is of itself
      discrete).

My current take on modeling stuff like asynchronous circuits (or
      non-precision analog) is that you can probably do it with neural
      network models that don't need the solver - a technique based on
      Bernard Widrow's adaptive filtering work. Here's a picture -

  http://ars.els-cdn.com/content/image/1-s2.0-S0893608097000324-gr2.gif

- the "plant" in (a) can be a reference Spice or Verilog-A model.

Kev.

On 05/27/2013 10:53 AM, Cary R. wrote:

Hi Kevin,
>
>You need to understand wreal, $realtobits/$bitstoreal or really
        anything else, at the moment, is mostly the same to me; it is
        just interconnect. Of the two explicitly mentioned methods wreal
        is better since it can easily be viewed in a waveform viewer
        where the two conversion functions do not have a defined binary
        representation so you have to port the bus where you want to
        view the real value it is representing. 
>
>I'm specifically looking at ways to model analog functionality
        accurately and efficiently using straight Verilog-D. The issue
        driving this is I design complicated asynchronous control
        systems that interact with fairly complicated analog circuitry
        and using AMS or an analog simulator to test this is too slow to
        get good coverage. I could likely use AMS with Verilog-A models
        and for other reasons that may be what I end up doing, but
        something that works in straight Verilog-D should be fast and is
        more cost effective from a license stand point, especially if
        Icarus can be used.
>
>I have read your proposal and have also looked at what actually
        made it into the standard so I understand where you are coming
        from. At the moment I'm concerned with modeling functionality
        and the existing interconnection functionality has been adequate
        for my needs.
>
>
>
>Cary
>
>
>
>
>________________________________
> From: Kevin Cameron _&subject=Re:_[Iverilog-devel]_verilogams_support&date=1369723390" alt="mailto:dk...@gr..."> To: Cary R. <cy...@ya...>; Discussions concerning Icarus Verilog development <ive...@li...> 
>Sent: Sunday, May 26, 2013 9:46 PM
>Subject: Re: [Iverilog-devel] verilogams support
> 
>
>
>
>Hi Cary,
>
>Wreal was a bit of a last minute hack on one of the
                    early LRM cycles, I've been trying to deprecate it
                    for years - it wasn't necessary since you should be
                    able to just assign voltages to nets in in a
                    discrete/digital context, having a separate wire
                    type just causes problems. Deprecation would just
                    mean having a "rewrite rule" so that wreal would
                    just be treated like a regular wire and assignments
                    would be treated as potential (x = V(...)). 
>
>I proposed the following for user defined types in
                    SV which would cover the wreal functionality -
>
>  http://www.eda.org/twiki/pub/VerilogAMS/DiscreteAnalogModelingInSV/3398-alt.pdf
>
>- basically with that approach wires are treated as
                    carrying orthogonal information for value, strength
                    and certainty, and the difference between wreal (if
                    it worked right) and wire (logic) types is the value
                    aspect. If you do stuff that way it's easier to push
                    it into user space and just call the standard math
                    functions.
>
>Kev. 
>
>
>On 05/25/2013 08:45 AM, Cary R. wrote:
>
>I have not mentioned much about this and that is not going to change significantly today, but I am spending much of my free time investigating the limits of discrete real valued modeling. The only requirements so far are single driver wreal support which both Cadence and Icarus support, the standard 1364-2005 math functions and a few custom VPI routines that I'm writing. At the moment the custom routines are mostly missing math functions (e.g. abs, min, max, fmod) and a custom routine to do some checking of the timeunit and timeprecesion of the analog blocks. I know I still need a custom delay implementation and plan to finish the table model I started a while ago. I am specifically trying to write as much of this in Verilog-D as possible.
>>
>>
>>
>>Cary
>>
>>
>>
>>
>>________________________________
>> From: Kevin Cameron <iv...@gr...>
>>To: wi...@ya... 
>>Cc: ive...@li... 
>>Sent: Saturday, May 25, 2013 1:56 AM
>>Subject: Re: [Iverilog-devel] verilogams support
>> 
>>
>>
>>
>>Gnucap might handle the Verilog-A
                                  code- http://www.gnucap.org/dokuwiki/doku.php?id=gnucap:about
>>
>>For Icarus it might be a good support
                                  discrete PWL signals even if the
                                  solver (needed for Verilog-AMS) isn't
                                  there because there's a bunch of
                                  useful modeling one could do at that
                                  level. Better still would be
                                  user-defined types on wires since the
                                  SV committee seems to have choked on
                                  that.
>>
>>BTW, I was thinking it would be good
                                  to build a wire-level interconnect API
                                  for different simulators to connect
                                  through if anyone wants to work on it.
>>
>>Kev.
>>
>>On 05/24/2013 08:41 PM, Cary R. wrote:
>>
>>Hi Dezai,
>>>
>>>
>>>Icarus supports very little Verilog-A. What's there is mostly preliminary infrastructure. We have not worked on Verilog-A in a long time. Our development focus has shifted to SystemVerilog and other enhancements. From you example I know that at least contribution statements <+ are not currently supported.
>>>
>>>
>>>Cary
>>>
>>>
>>>
>>>
>>>________________________________
>>> From: Dezai G <wi...@ya...>
>>>To: "ive...@li..." <ive...@li...> 
>>>Sent: Friday, May 24, 2013 6:01 PM
>>>Subject: [Iverilog-devel] verilogams support
>>> 
>>>
>>>
>>>
>>>
>>>Hello everyone
>>>I  would like to compile the veriloga file below with iverilog -gverilog-ams
>>>The compilations failes
>>>Is expected ?
>>>What is exactly the ams subset supported by icarus verilog
>>>Thanks
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
// Various Resistor Models
>>>//
>>>// Version 1a, 11 Apr 03
>>>//
>>>// Ken Kundert
>>>//
>>>// Downloaded from The
                                                Designer's Guide (www.designers-guide.org).
>>>// Post any questions on www.designers-guide.org/Forum.
>>>
>>>`include
                                                "disciplines.vams"
>>>
>>>
>>>
>>>// Conductance Form of
                                                Resistor
>>>// Most efficient on
                                                most simulators.
>>>// Best for large valued
                                                resistors (r > 1); r
                                                must not be 0.
>>>
>>>module res1(p, n);
>>>
>>>inout p, n;
>>>electrical p, n;
>>>parameter real r=1
                                                exclude 0;
>>>
>>>analog begin
>>>    I(p,n) <+
                                                V(p,n)/r;
>>>end
>>>endmodule
>>>
>>>
>>>------------------------------------------------------------------------------