Re: Framework directions for discrete modeling

>> Generic interconnect Model

Can't see the point in the "interconnect" keyword.

There's some confusion in the use of types in Verilog(-AMS) because
wires don't really have a type, types belong to drivers and receivers,
unfortunately drivers and receivers are only declared implicitly so
there is nowhere to hang the type other than on the wire or port
declarations the drivers/receivers are attached to (or just using a
default - logic). You should be able to put whatever type you like in a
wire/port declaration and it will have no effect if there are no
attached processes in the module.

Likewise which resolution functions to use for a net should not be based
on the net's declared type but on the types of the drivers attached to
the net.

There are already "driver access" functions in Verilog-AMS which are
used to calculate conversions to analog, they could be reused for
arbitrary types.

I'm not convinced that "primitive" keyword is needed either, the
language seems to be able to discriminate between what is an array of
physical wires and a single (resolved) wire at the moment. If was going
to use it I would say that it binds to the type (of the driver/receiver)
rather than the net - i.e. (wire of (primitive type)) rather than
((primitive wire) of type).
 
>> $indicate_edge(integer_expression)

This seems to be the kind of thing that should be a class member
function, rather than a system call. Likewise resolution functions
should probably be defined within their class definition - as in Ken
Bakalar's proposal
(http://www.eda-stds.org/verilog-ams/htmlpages/public-docs/ResolvedCompositeSignalsInSVv4.pdf).

Anyway, there seems to be a lot of discussion of syntax without having a
clear semantic model or objectives.

Kev.

On 07/14/2010 10:58 AM, Gordon Vreugdenhil wrote:
> The attached is something that I wrote up based on discussions
> that I've had with users and internally within Mentor. This is
> not intended to be complete but contains consideration of some
> issues that haven't yet been discussed. I'll be happy to review
> this with the committee in a future meeting.
>
> Gord.

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