Re: Binding Followup

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.