Re: Verilog-AMS Committee Call - 16th June 2011 (SV-DC)

There's an on-going failure at SV-DC to work with the right abstractions. The idea that "wire" has a type is not useful. What actually has a type is the driver or receiver attached to the (physical) wire, the only thing the wire has is a discipline. It's the drivers and receivers that have the default/pre-defined type of "logic", not the wire. The confusion arises because there are no other syntactic hooks for the driver/receiver type. Ken's proposal partially fixes that by making driver declarations explicit.

Changing the abstraction to one where drivers and receivers have types and wires are always just interconnect DOES NOT change any existing behavior.

As an interim measure I would suggest that SV-DC adopts disciplines, and any wire with a discipline is viewed as generic interconnect rather than introducing a new keyword, i.e. rather than "interconnect" you can just use "electrical" as in Verilog-AMS. Or just use "electrical" as the keyword instead of "interconnect" until AMS is incorporated (for forward compatibility).

The connect rules in AMS are the way they are so that you can work around odd connections (between vendors) later in the design process. The same approach can be taken with SV by providing resolution/conversion functions separately from driver/receiver types. Defining resolution functions as part of the driver type is a hangover from VHDL and its dysfunctional approach to resolution/type-conversion.

Kev.

On 06/15/2011 11:33 AM, Ian Wilson wrote:
> There was a long discussion about generic interconnect in today's (6/15) SV-DC
> meeting.
>
> Of particular value today, I found one user's complaint (paraphrased):
> - vendor X implemented [a form of] wreal and allowed interconnection
> [of wreal ports] using wire
> - vendor Y's wreal implementation did not support interconnection using
> wire
> In other words, there was no portability between these two implementations
> (and no standard exists for a 'correct' interpretation).
>
> The only candidate in existing {System}Verilog for a typeless interconnect is wire.
> However, this is predfined as being of type logic, so would be incompatible on some
> level with user-defined types (which would be the mechanism for providing portable
> behavior similar to wreal). Hence the proposal to introduce 'interconnect' as a type.
>
> From an AMS viewpoint, interconnect (whether wire or something) doesn't have
> any behavior except possibly to contribute discipline information, so other than
> complicating the elaboration process, and adding syntax, it doesn't seem that
> interconnect as currently proposed will be a major problem for AMS/SV integration.
>
> --ian
>> ----------------------------------
>> Ian M Wilson
>> Architect
>> Berkeley Design Automation
>> Office: 408-496-6600 x238
>> Cell: 714-272-7040
>> ian.wilson@berkeley-da.com
>> http://www.berkeley-da.com
>> ----------------------------------
>> True SPICE accuracy, 5X-20X faster
>> Don't Be Left Behind!
>> ----------------------------------
>>
>>
>

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