Re: Deprecating wreal

The boolean value (0,1,X) is not really an attribute of  the wire, it's
an attribute of the digital driver, "Z" indicates the absence of a driver.

Capacitance in digital verilog is really just about hold-up time, i.e.
given a transition to Z how long do you keep a 1/0 or X, it is an
attribute of the wire but is (IMO) an orthogonal issue. Note: given the
driver access functions you can actually write a digital behavioral
model for a hold-up cap, i.e. you can view wire capacitance as another
(digital) process with a driver and receiver attached to the wire, and
the capacitance is an attribute of that process (not the wire itself).
As separate issue: the wire declaration should probably be extended to
include real capacitance values so they can be summed properly.
 
Likewise, resolution functions are a function of drivers not wires.
Essentially the A/D insertion mechanism of Verilog-AMS is a driver
resolution scheme: analog and digital drivers/contributions are resolved
by converting digital drivers into analog drivers (contributions) and
resolving (KCL), with down conversion (A2D) for digital receivers. Note:
if more types are added (with SV) then this scheme can be generalized.

Assigning to a wreal works much the same as  assigning to a voltage
branch: no resolution is possible, so only a single driver is allowed.
So (IMO) you treat a real number assignment to a wire "w = r" as being
the same as "V(w) <+ r", and reading the wreal "r = w" the same as "r =
V(w)". This also enables the use of syntax like "I(w) <+ 0" which
essential disconnects the driver. As far as I can remember you can't
assign a real directly to a wire in Verilog, so I don't think there is
any backward compatibility problem allowing it going forward with the
"V(w) <+ r" semantic.

So I still say: mark wreal for deprecation, and just say what the
equivalent behavior is in the LRM. Like defparam it probably never go
away, but at least the underlying semantics will be sensible.

Kev.

Bresticker, Shalom wrote:
> I don't know about that. 
> In digital Verilog, wires have capacitance and resolution functions.
> And their values are discrete Boolean values (though 4-state). 
>
> Shalom
>
>   
>> -----Original Message-----
>> From: owner-verilog-ams@server.eda.org 
>> [mailto:owner-verilog-ams@server.eda.org] On Behalf Of Kevin Cameron
>> Sent: Thursday, November 26, 2009 6:18 AM
>> To: Verilog-AMS LRM Committee
>> Cc: David Miller
>> Subject: Re: Minutes of Verilog-AMS committee meeting - 18th Nov 2009
>>
>> David Miller wrote:
>>     
>>> Date: 18th Nov 2009
>>>
>>> Objective of this meeting was to go through the "AMS Enhancement"
>>> items to identify the ones we want to do / close / group into common
>>> items etc.
>>> ....
>>>
>>> Item 2378: Deprecate wreal. Moving to closed. We won't be deprecating wreal.
>>>
>>>       
>> The point in deprecating it is that it is an unnecessary construct in
>> the language. You can keep the declaration "wreal" if you 
>> want, but the
>> functionality is really just a degenerate case of a regular 
>> wire: with a
>> single driver/contribution and some number of receivers.  If you make
>> wreal  different from a normal wire you create an artificial 
>> distinction
>> that just causes problems.
>>
>> The "real" part of wreal is the type of the driver or receiver: wires
>> (and ports) are just connectivity and have no type, only drivers and
>> receivers have a type. Types are only associated with ports and wires
>> because receivers and drivers are implicit constructs and cannot be
>> directly annotated.
>>
>> There is no particular reason that you can't just assign voltages and
>> read them in digital processes the same way you do in analog 
>> processes.
>> In which case wreal can just be a synonym for a default 
>> discipline wire.
>>
>> Kev.
>>
>>
>> -- 
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>>
>>
>>     
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
>
>
>   


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