Re: Framework directions for discrete modeling

  On 7/26/2010 8:13 PM, Gordon Vreugdenhil wrote:
>
>
> 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.

I'm not seeing a dependency for doing things correctly in SV on doing any fixes to AMS.

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

I think you are confusing two issues, within a module "w" will have an associated type (e.g. logic) which will be used for the driver (the "1" would be coerced accordingly). Another module may also have a connection to "w" with an assign of a different type (say bit), In order to do the resolution you need to work out that you have two drivers one of type bit and one of type logic, that you can promote bit to logic and that you have a resolution function for logic. Port types on intermediate layers of hierarchy are not relevant, e.g. if you typed a port in the net as (AMS) electrical (without attaching anything) it won't force the resolution into the analog domain.

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

What your asking is given something like -

typedef struct {integer r,g,b;} RGB;

- how do you differentiate between

a) one physical wire with three associated integer values
b) three physical wires with integer values
c) 3x32bits (96 physical wires)

I would say that "wire RGB x" declares x as (a). Since that syntax isn't currently in use there's no reason for it to be ambiguous.

(b) would be more like -

struct {
     wire integer r,g,b;
} RGB;

(c) -

struct {
     wire logic [32] r,g,b; // the "logic" is optional if logic is the default type
} RGB;

Basically if you can work out where there is an implicit "logic" in the current syntax, you should be able to do it explicitly or use a different type - e.g. the current declaration "wire l" is equivalent to "wire logic l".

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

I'd be interested in seeing your list of the concerns. Ken's proposal might not have been fully worked through, but IMO it's the best so far, and I don't think there was ever any suggestion that it required re-expressing anything (it's dealing with things you can't do currently).

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

That might save some effort ;-)

Kev.

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

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