Subject: RE: Bus Clamp vs Dynamic Clamp

From: "Muranyi, Arpad" <[email-masked]>
Date: Mon, 13 Mar 2000 16:13:01 -0800

Chris,

First you call it a bad thing to have more than one way to do the same
thing.
Then, in your last paragraph you say:

"The trick is to offer flexibility WITHOUT over-complicating things."

Being able to do things more than just one way is a flexibility of some
kind.
The real issue here is that the IBIS spec is getting "over-complicated".
However,
I don't think that this is due to the fact that there are multiple ways of
doing
things.  It really is due to the way the syntax is constructed.

Otherwise I agree with you 100%, and I hope that the future IBIS syntax will
not
fall into the same mistake.

The example you brought up with the bus hold and dynamic clamp is a case
when the main features allow for some overlapping "side effects".  Since
these
are not the primary intent of those keywords, this may have been an
unintentional
"feature" or an oversight.  Of course, on the principle of "if something can
be
done, it will be done" we should not have allowed it if it causes problems
or
confusion.

Arpad
============================================================================
=====

-----Original Message-----
From: Chris Rokusek [mailto:[email-masked]]
Sent: Monday, March 13, 2000 2:59 PM
To: Ibis@Eda. Org
Subject: RE: Bus Clamp vs Dynamic Clamp

Arpad,

> Even though I agree that it is not always good to have redundancy,
> I also may argue that some times it will happen.  For example,
> think how many different ways you can write a resistor in HSPICE.
> You can do it as an R-element, and also as either one of the
> four controlled sources.  Is that bad?

Yes, that is extrememly BAD if I am a user that only cares about R/L/C
circuits because my manual is thicker than it needs to be.  And if the
manually gets as big as my car because HSPICE can also beat Big Blue at
chess, then I won't use HSPICE to solve my linear circuit problem if I can
find an alternate easy to use solution that minimizes my time to solution
(and I don't have a garage/hard drive to hold the manual).

If I am a user that needs controlled sources then I answer no.

Of course Avanti will satisfy the majority of its users and better yet will
try to add features without increasing the user learning curve.

The point I was trying to make in the 3/10/2000 reply was that if it's
possible to simplify something that has many rules (e.g. order of
precedence):

1 + 2 * 5 * pi
-----------------
10 * pi + 1/1*1+0

Then do it!

The trick is to offer flexibility WITHOUT over-complicating things.  This is
not a new concept, software development goes through this process all the
time.  Start with a simple solution to a problem.  Then, add, add, and add
features to it.  Eventually you have something that needs to be simplified
because the added features "weigh" more than the original solution.

What are the examples in Hardware?  RISC, FPGA's?

Chris

> -----Original Message-----
> From: Muranyi, Arpad [mailto:[email-masked]]
> Sent: Monday, March 13, 2000 2:12 PM
> To: 'Chris Rokusek'
> Subject: RE: Bus Clamp vs Dynamic Clamp
>
>
> Chris,
>
> This sounds believable, but I have to admit that I would have
> to re-read the spec. to see whether it is correct.  This was not
> the intention, though.
>
> Even though I agree that it is not always good to have redundancy,
> I also may argue that some times it will happen.  For example,
> think how many different ways you can write a resistor in HSPICE.
> You can do it as an R-element, and also as either one of the
> four controlled sources.  Is that bad?
>
> Arpad
> ================================================================
>
> -----Original Message-----
> From: Chris Rokusek [mailto:[email-masked]]
> Sent: Friday, March 10, 2000 4:56 PM
> To: Ibis@Eda. Org
> Subject: RE: Bus Clamp vs Dynamic Clamp
>
>
> Arpad,
>
> The question was in regard to the ***STATIC MODE*** of Dynamic Clamp.  You
> answered a different question.
>
> After ten minutes of reading the spec I conlude that there are two ways to
> specify additional static clamping of a given parent model when in a
> particular state.
>
> One can use a
>
> 	1) "Static Mode" Dynamic Clamp sub-model (means it doesn't have
> pulse
> tables).
>
> 	2) "Bus Hold" with NULL I-V Pullup/Pulldown.
>
> Right?
>
> Chris
>
>
>
>
> > -----Original Message-----
> > From: Muranyi, Arpad [mailto:[email-masked]]
> > Sent: Friday, March 10, 2000 4:01 PM
> > To: 'Chris Rokusek'; Ibis@Eda. Org
> > Subject: RE: Bus Clamp vs Dynamic Clamp
> >
> >
> > Chris,
> >
> > These two were implemented for two completely different circuit
> > behaviors.  The dynamic clamp shifts the knee voltage of the clamp
> > based on some triggering events.  The bus hold circuit's I-V cure
> > goes through the origin, but it switches from a pullup to a pulldown
> > shape when it detects a certain voltage.  I don't see how these two
> > are the same, or how they could be described with only one of these two
> > keywords.
> >
> > Arpad
> > ====================================================================
> >
> > -----Original Message-----
> > From: Chris Rokusek [mailto:[email-masked]]
> > Sent: Friday, March 10, 2000 2:10 PM
> > To: Ibis@Eda. Org
> > Subject: RE: Bus Clamp vs Dynamic Clamp
> >
> >
> > Let me rephrase:
> >
> > If a Static Mode Dynamic Clamp submodel can be described as a Bus Hold
> > model, why do we need a static mode?
> >
> > Think about this:
> >
> > 	There are two submodel types.
> >
> > 	Their are multiple modes for each type.
> >
> > 	The submodel itself is a type (in so much as its not a model).
> >
> > 	The submodel type can only be used under certain conditions of the
> > parent
> > Model.
> >
> > That's a lot of IF's just to effectively add a node to a circuit.
> >
> > Customers keep calling asking me to interpret the IBIS Spec.
> Therefore, I
> > conclude the spec must be difficult to understand.
> >
> > The more TYPE's, RULE's, IF's, and MODE's there are in this
> spec, the more
> > difficult it becomes to comprehend and maintain.  Hey look that makes an
> > acronym:  TRIM!
> >
> > Of course its MY FAULT just as much as anyone else's for
> allowing some of
> > these BIRDS to contain redundancies.  I'm hoping that we become
> > more careful
> > as to what we are adding to the spec and perhaps we can even reduce and
> > simplify at some point.
> >
> > Thanks for reading!
> >
> > Chris Rokusek
> > Viewlogic Systems
> >
> >
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]
> > > Sent: Friday, March 10, 2000 12:44 PM
> > > To: Chris Rokusek
> > > Cc: Ibis@Eda. Org
> > > Subject: Re: Bus Clamp vs Dynamic Clamp
> > >
> > >
> > > Chris:
> > >
> > > Briefly, the Bus Hold submodel always
> > > always operates in the triggered mode
> > > and optionally with an Off_delay.  So
> > > it does not have a Static mode.
> > >
> > > Bob Ross
> > > Mentor Graphics
> > >
> > >
> > > Chris Rokusek wrote:
> > > >
> > > > Hi Ibis-gurus,
> > > >
> > > > I've got a question:
> > > >
> > > > I'm wondering what the differences are between:
> > > >
> > > >   1) "Static Mode" of a Dynamic Clamp Sub-model
> > > >
> > > >         vs.
> > > >
> > > >   2) Bus Hold Sub-Model.
> > > >
> > > > If there are no differences, is there any reason we really need the
> > > > redundancy and extra confusing verbage defining what Static Mode is?
> > > >
> > > > Chris
> > >
> >
> >
> >
>
>
>

---

From: "Chris Rokusek" <[email-masked]>
Date: Mon, 13 Mar 2000 19:27:16 -0800

Arpad,

> Being able to do things more than just one way is a flexibility of some

Yes!  Actually I called it BOTH a BAD thing and a GOOD thing each within a
given context so that I could explain that the "win-win" for both answers is
"The trick".

> things.  It really is due to the way the syntax is constructed.

I agree that "multiple-ways" in itself is not the problem either.

However I disagree that that the reason that the IBIS spec is overly
complicated is because of the way syntax is contructed.

SYNTAX to me is the wording used to describe the data and its relationships
and includes the rules used to contruct the wording.

CONTENT to me is the relationships among the data and the data itself.  I
usually think of that tree view on the IBIS ftp site plus all the rules of
the tree as content.

I think Syntax and Content are intimately intertwined.  Introduction of
"Sub-Model" was one solution to the Bus_Hold/Dynamic_Clamp problem.  Is
"Sub-Model" a syntax or content concept?  Seems like both to me.

To clarify, I am MOST interested in reducing the Content
TYPES/RULES/IFS/MODES in the future.  And of course if we can reduce the
Syntax TYPES/RULES/IFS/MODES as well I'm all for that too.  And since I
claim that they're intertwined, reducing one will probably naturally lead to
reducing the other.

Chris

(BTW: I have no problem with Sub-Model in particular, we could "pick on"
nearly any keyword!)

> Sent: Monday, March 13, 2000 4:13 PM
> To: Ibis@Eda. Org