Re: Framework directions for discrete modeling

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

But that isn't how SV resolution works right now. The overall type
of the simulation net is determined based on port domination rules
and defines the resolution applied to all driven values on the
simulation net. We cannot change those rules. So anything that
you might want to propose MUST fit into that framework.

Overall, my goals are as stated in section 2 of my write-up. In
addition, SV-DC will not be able to change fundamentals of
digital assumptions and behaviors. That will never fly and I
won't spend any effort on trying to do that. If we want to succeed
at all, we must have *minimal* intrusion into digital syntax and
semantics while allowing for model substitution. The ability to
express models in pure digital while retaining an easy method for
replacement of the model with an AMS model is something that I've
heard from many customers. My intent was to suggest some directions
for meeting those goals. The idea of a "connection" is to allow
for an AMS model to layer its own semantics into a design without
causing problems with digital assumptions; having a connection that
is clearly and cleanly abstract seems to be a necessary step in
meeting that goal. The scheduling of the resolution and design
of primitive nets was done in a manner to not intrude on any
existing assumptions or behaviors and yet fit smoothly into a
design where AMS models substitute into the design.

Now if the AMS community wants to go to a class based approach
as Ken suggests, that is fine. We're done and can close down
DC since that is all pure SV code. Do you really think that
approach will work? I have serious doubts. The wreal (and related)
suggestions haven't found much enthusiasm either from what I can tell.

So, do you have any concrete suggestions that meet the
model substitution needs, are not intrusive on SV and are
efficiently implementable?

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.