Subject: Forwarded: Re: Bird 48 comments from HyperLynx

From: [email-masked] (Bob Ross)
Date: Thu, 4 Jun 98 16:02:18 PDT

Forgot to copy send to the reflector.

Bob

Date: Thu, 4 Jun 98 16:00:35 PDT
Message-Id: <9806042300.AA07603@bob>
To: [email-masked]
Subject: Re:  Bird 48 comments from HyperLynx

Kelly and All:

Thank you for your comments.  As an author trying to deal
with the functionality as it has been evolving, I am somewhat
blind to the clarity of the presentation.  You have some very
good points.  A [Sub Model] keyword has some similarities
with a subroutine or a .SUBCKT that is called or invoked
from the mainline program.  That is the primary concept.

So I tend to agree with your comments.  I had been thinking
similar thoughts.  We can discuss this further at the meeting
along with other comments and concerns.

I welcome comments from others as well.

Bob Ross
Interconnectix/Mentor Graphics

> Date: Thu, 04 Jun 1998 14:42:59 -0700
> To: [email-masked]
> From: Kellee Crisafulli <[email-masked]>
> Subject: Bird 48 comments from HyperLynx

> Hi IBIS,

>   We had a meeting and discussed bird 48 with our
> engineering team with the following feedback:

> 1) The re-use of the MODEL keyword confuses usage of this
>    bird to the point that we will vote NO unless a new keyword
>    like SUB_MODEL is used.  We found no one in the office
>    could understand how to use the add model concept without
>    a group discussion of what it meant.  The biggest confusion
>    is that sometimes a MODEL is a real model and sometimes
>    it is a sub-model that isn't a real model.  I understand
>    it was easier to write this way but it is very confusing.

>    To fix it just use a new keyword SUB_MODEL.  
>    The add model then is ADD SUB_MODEL which is much clearer about
>    what is happening.

> 2) If the above keyword change is made then we should re-use
>    "model spec" and not add the new "sub-model spec" syntax.
>    This is consistent with the re-use of VI tables etc.

> 3) It is essential that the SUB_MODEL keyword explicitly define
>    which keywords can be used.  The present documentation requires
>    considerable reading to determine what is allowed.  This should
>    be in more bullet like form that is easy to speed read.

> We feel this is a minor change and will fully support this bird with
> the above changes.  We will oppose this bird without this change on
> the basis that it is too difficult to understand.

> Kellee
> Matt
> Steve

> -------------------------------------------------------------------------
> Have a great day...
> Kellee Crisafulli at HyperLynx
> [email-masked]	http://www.hyperlynx.com
> -------------------------------------------------------------------------

-------- End of Forwarded Message