Re: Framework directions for discrete modeling

On 07/27/2010 07:08 AM, Gordon Vreugdenhil wrote:
>
>
> 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.

SV resolution AFAIK is the same as Verilog because no net types were
added. Drivers/receivers are logic+strength or some degenerate case
(like bit).

Resolution in Verilog is flat, i.e.hierarchy is not considered. VHDL
does not not do flat resolution, and that can give incorrect behavior
for AMS.

As I said before: ports are a convenient syntactic hook, but do not
represent any physical object, as such they should not play a part in
how resolution works.

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

I did the original design work for the AMS connect module methodology
(~1995), "plug-and-play" - swapping digital modules for analog being
handled automatically - was one of the main objectives, and supporting
legacy code was also a priority. We achieved that, so this is mostly a
solved problem. I did work on generalizing the scheme back in the 90s,
but nobody was interested at the time.

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

The user community wants user defined types on wires, SV has classes for
defining types. You can use the class inheritance mechanism to take base
classes and add different resolution schemes, which makes it easier to
work out which types are compatible. It's fairly easy to make the
parsers recognize net assignments and do driver creation/insertion
rather than doing the manual driver stuff in Ken's proposal.

It's pretty similar to what's in VHDL for user defined types, so I'm not
seeing this as a hard problem.

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

Like I said: we did all this stuff for AMS in the '90s. It would have
been incorporated into Verilog prior to its move to the IEEE if some
folks had not decided to play politics. I don't see a lot of point in
reinventing the wheel.

At the time I started on Verilog-AMS I was working on VCS at
Chronologic. My view at the time was that as devices got smaller wiring
was going to dominate (rather than gate cap), and the SDF
back-annotation methodology would fail at some point. Rather than using
SDF I wanted a flow where I could use existing Verilog (digital) models
with analog interconnect models. Unfortunately Cadence broke the
methodology by aligning the semantics with their schematic capture
system rather than doing the right thing, and refusing to deliver on a
promised back-annotation methodology.

Since the original work the only major change to the design flow has
been the addition of power management, which is another reason why you
want to be able to model the real interconnect. I'm assuming that this
issue is a prime motivator for the current interest.

The main AMS issues that need fixed (they're in the AMS Mantiss database
with proposals for fixes), which you could just do correctly in SV:

  Use "process bound" not "port bound" semantics
     - connect modules are instantiated in the instance containing the
driver/receiver process

  Back annotation
     - method for adding more code and redirecting existing connections
into it

  Method for specifying power supply connection in modules.

Generalizing the connect-module methodology to user-defined types is
fairly straight forward - i.e. discrete<->discrete conversions are
easier than discrete<->continuous.

Kev.

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