[sv-dc] Framework etc, etc

Hi All.

Please post these messages with [sv-dc] in the subject;
my spam filter sequestered them all, and it's just
lucky that I noticed the content.

I would guess that most of the recipients on the sv
dc list have missed this discussion.
.

On 07/27/2010 11:22 AM, Kevin Cameron wrote:
> 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 change has been the addition of power
> management to the design flow, 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), which you could just do correctly in SV:
>
> Use "process bound" not "port bound" semantics
> - connect modules are instantiated in instance containing
> 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.
>

-- 
      John Michael Williams
      Senior Adjunct Faculty
Silicon Valley Technical Institute
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.