Re: Binding Followup

From: John Shields <John_Shields_at_.....>
Date: Thu Apr 19 2007 - 10:05:29 PDT

Hi Kevin,

The vhdl-ams working group is beginning work on a language enhancement for this problem.  The aim is to provide a mechanism to allow signals or terminals to connect a port.  The goal is to allow equivalent component models in either the analog or digital domain to be interchanged in a design hierarchy.  Of course there is no final proposed LRM change yet, but there is paper written for FDL a few years ago that is the expected starting point. The fundamental mechanism is to introduce the "wire" type and allow ports of type wire to accept any kind of connection.  One can reference the wire via access functions gaining the appropriate a2d/d2a type conversion.  The final net will be modeled in the most appropriate domain,i.e., as an analog net.  The analog net being broken into multiple isolated segments does not occur as a result of this connectivity model.  There are some unresolved elaboration issues to work out for a full solution.  There are a lot more details, but this is not the forum for them.

I note that you believe the hierarchical resolution model must change to a flat model for vhdl-ams to work properly.  That is not proposed to solve this problem.  It is something that would potentially cause the same digital models to behave differently if instantiated in an analog context vs. a digital context.  That would not be an acceptable change to the simulation semantics in the vhdl or vhdl-ams community.  I appreciate the issue you raise. The way that vhdl-ams models work with pure vhdl models is through compatible interfaces.  One cannot connect terminals to ports or signals to terminals.  That implies that the interoperability of sv with vhdl and sv with vhdl-ams would be based on the same compatibility rules.  I believe this is consistent with what you've stated

As an aside, where it would become interesting is if verilog-ams and vhdl-ams models were required to interoperate.  My current view is that is not a requirement and we(sv-xc) are not planning to consider it.  As such, I hope we will not even open that can of worms in this forum.

Regards, John

Kevin Cameron wrote:

Geoffrey.Coram wrote:

Hi, Logie -
I'm somewhat puzzled/troubled by the implication in your
message that there is a "SystemVerilog-AMS boundary".

In particular, since Verilog-AMS has modules and parameters
defined by the same rules as Verilog, what boundary is there?
There aren't any special rules necessary for instantiating
AMS modules, and the parameter binding rules of AMS are
those of Verilog.

AMS parameters are Verilog parameters (AMS added strings
to 1364, but did so in the same way 1800 did).

AMS variables are the same as Verilog's.

AMS port connections already support the same named or
positional connections as SV, and AMS could naturally be 
extended to allow implicit .name and *.port connections.

  

6)   Is it OK to connect a VHDL-AMS terminal to a SV digital net?
     Inside VHDL-AMS, a terminal can be connected only to a terminal.
     However, in VERILOG-AMS, language does allow an analog node to be
     connected to a digital net and the language provides a mechanism to
     automatically insert a connect module (D2A or A2D converter) at
     Analog/Digital boundary. Which rule to follow : VERILOG-AMS or VHDL-AMS?
    

I don't understand why there is a question; existing AMS
tools allow connections from an analog node to a 1364-Verilog
digital net, so for backwards compatibility, aren't you
required to follow the Verilog-AMS rule?
  

Agreed, SV/AMS should just follow the Verilog-AMS rules.

VHDL is different in that all the signal types are user-defined and it doesn't have a built-in driver resolution - resolution is performed hierarchically with user-defined functions so that it fits in with port-bound type conversion. Since that approach doesn't fit with mixing analog and digital drivers on a single net it's not possible to connect analog to digital directly in VHDL.

The proper fix is to extend VHDL to do flat signal resolution on physical types the way it is done in Verilog-AMS.

A secondary problem is that you can't have an analog net being solved in two places, it needs to be whole and in a single solver., i.e. if a net starts as analog in a Verilog-AMS context is connected to a VHDL digital net and then connects back into analog then the end points have to be recognizable as belonging to the same net (this is not usually required for digital).

I can think of a couple extensions in AMS that need to be handled:
1) wreal nets
  

A wreal net is a discrete real-valued net. It's actually unnecessary to treat it as a new concept since you can consider it as being a regular net with an appropriate discipline (maybe the default) and a discrete driver of type real (and receivers of type real) and you should get the same results. The fundamental difference is that there is no resolution method for type real (in AMS), so there can only be one driver on the net.

2) parameter aliases (built-in Spice models accept parameters by
more than one name, eg "vt0" (vee-tee-zero) and "vto" (vee-tee-oh))
3) paramsets, which are sort of like Spice .model cards on steroids;
several paramsets can have the same name and the simulator is
responsible for picking the one that fits the instance
(lmin < L_instance < lmax).

(Kevin can probably help me out with any others I missed.)
  

I previously suggested that we could probably handle most of the special AMS parameter/paramset issues with wrapper modules on the AMS side, and it was unlikely that we would want to deal with it cross-language (at this time).

The other feature of Verilog-AMS that is missing from other languages is the "driver access functions" that allow the D2A connect modules to correct the analog timing. and allow users to create (discrete) bidirectional signal flow components. Since the D2As will probably have to work cross-language it probably needs to be considered.

Kev.

-Geoffrey

  

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

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean. Received on Thu Apr 19 10:05:48 2007