Re: Framework directions for discrete modeling

Kevin Cameron wrote:
>>> 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.

As I indicated in the document, there are some close parallels and
potentially could be fixed in Verilog-AMS. If you're willing to
do that first and then come back to SV, that would be fine with me.

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

Unfortunately implicit conversions in Verilog make that very
difficult. Consider:
    assign w = 1;
That is a driver. But the "1" could be either integer, coerced to
a real, a bit, etc. All of those are fine. If you want to
determine resolution by implicit driver type, I think you're
going to run into problems.

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

So how would you distinguish between:
    struct { logic a, b }
used as two bits with independent resolution versus a single
resolution function? Right now SV already defines this as
two independently resolved values. Can you give a concrete
proposal for what you have in mind and which does not
conflict with existing SV rules?

>>> $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).

I have pretty substantial concerns with Ken's proposal. There
are a bunch of things involved that are not going to be easily
integrated into a full system and it requires a substantial
amount of user work - essentially re-expressing and directly
managing the entire design topology.

If users really want to do that, they don't need any SV support
at all -- just do the class based thing Ken suggests.

Gord.

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

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.