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

Hi Kevin,
I don't quite follow what you mean when you say "The idea that "wire" has a
type is not useful".

Because an object declared as a wire can be used within procedural code, for
example within an expression, don't I need the type so I can check validity
etc. at compilation time?

Isn't all we want from these interconnects is:
* a construct that allows us to store range/width (packed/unpacked) information
* contains no type information
* restricted to not be allowed withing behavioral/procedural code (so only port
connections)
* must be able to be resolved/collapsed to an atomic element by the end of
elaboration prior to simulation.

Are you suggesting we could just declare interconnect as a discipline with some
sort of generic domain perhaps?
discipline interconnect
   domain generic;
enddiscipline

Or something like that, depending on syntax etc.

Regards
Dave

On 06/15/2011 02:41 PM, Kevin Cameron wrote:
>
> 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!
>>> ----------------------------------
>>>
>>>
>>
>
>

-- 
==============================================
-- David Miller
-- Design Technology (Austin)
-- Freescale Semiconductor
-- Ph : 512 996-7377 Fax: x7755
==============================================
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.