Re: [sv-dc] Re: Verilog-AMS Committee Call - 16th June 2011 (SV-DC)

On 06/15/2011 01:17 PM, Dave Miller wrote:
> 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?

A wire by itself is a passive object, the active objects are the
transistors involved in driving the wire and reading its value
(receivers). The thing being modeled is not the wire but the
interaction of the drivers and receivers. Type compatibility between
drivers and receivers needs to be checked, but not at the point of
connection (port/xmr), at the point of connection only disciplines
need to match.

A port does not represent any physical object in simulation (of real
hardware), it's just a method of saying one piece of conductor is
connected to another, so it's difficult to see how "type" (other than
discipline) plays any part in that.

Considering wires as having a type makes particularly little sense in
modules that have no active components (purely structural).

There are some syntactic shortcuts in Verilog and VHDL, both use
implicit declaration for drivers and receivers. Procedural code does
not write directly to a wire, it writes to the driver, the "type" of
the wire (if anything) is the resolved type of all the drivers on the
wire.

Receivers don't usually come up in Verilog discussions because there
is only one type (strength logic) and you can just take the resolution
result of the drivers. Receivers become a necessary concept when
discussing mixed-signal nets whether its in AMS or discrete modeling,
e.g. if you have a wreal driver representing voltage feeding some
gates with logic inputs then you need to be able to specify how to do
the conversion to 1/0 for each input.

>
> 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 within 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.

[Domains and disciplines are orthogonal concepts, and domain
declaration is usually redundant because you can get it from context.
The "domain" in discipline declarations was a bad/unnecessary idea.]

I'm just saying that because the abstraction being used by SV-DC is
bad, this is getting more complicated than it needs to be, there is no
need for an extra keyword, the desired behavior can be the default
behavior with the existing code. If folks can't agree to that I'm
suggesting using the "electrical" instead of "interconnect" as the
keyword in SV, so that the intention is clear and it will be forward
compatible with AMS.

Kev.

>
> 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!
>>>> ----------------------------------
>>>>
>>>>
>>>
>>
>>
>

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