[ibis-macro] Re: About the Typos BIRD comments from Fangyi

  • From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
  • To: <ibis-macro@xxxxxxxxxxxxx>
  • Date: Mon, 6 Dec 2010 12:09:49 -0800

Walter, Mike,

 

This is a classic example for why we have so much trouble

understanding the specification.

 

The paragraph you quoted below contains the following

answers ONLY:

 

-    who allocates memory for AMI_parameters_in

-    who allocates memory for AMI_parameters_out

-    these arguments are pointers to a string

-    the string is formatted as a parameter tree

-    the input from the .ami file is passed to the

model using a string

 

Note that the above list does NOT state the following:

 

-    through which string (argument) are the parameters

of type In go into the model

-    through which string (argument) do the parameters

of type Out come out from the model

-    through which string (argument) do the parameters

of type InOut go into the model

-    through which string (argument) do the parameters

of type InOut come out from the model

 

Whether these answers are obvious or not, I think a well

written specification does have to state them.   Following

the analogy of an I/O buffer in hardware, I can very easily

imagine that our InOut parameter may be modified "in place"

the same way as we process the impulse_matrix.  This thinking

is just as "obvious" and logical as the thinking that an

InOut is passed to the AMI model in the AMI_parameters_in

string, and the model passes a modified COPY of it back in

the AMI_parameters_out string.  No one can tell (let it be

model maker or EDA vendor) what to do based on the way the

spec is worded.  What if the model maker does it one way

and the EDA vendor the other way?

 

Specs (and law documents) usually state every single thing,

even those that are obvious, otherwise it can't be used as

a spec or law.  Let me give you an every-day illustration:

 

Is it obvious that you have to stop at a stop sign?  Most 

obviously yes!  Yet I would bet that there is no traffic text

book that doesn't include at least one sentence about the stop

sign to explain that you must bring your vehicle to a complete

halt when you get there.  Some might even give you a little more

detail on where exactly you have to stop.  You don't stop when

you first see the sign.  If there is a line then you need to

stop at the line.  But in case you can't see the entire

intersection from that location, you must move forward (after

you stopped at the lie), and stop again at the position from

where you can see the intersection well enough.  In addition

to these details they may explain what the 3-way and 4-way

extension signs mean, etc...

 

Interesting.  So much detail about such an obvious traffic sign!

And guess what, all this is written down in the traffic law books

also, so when you get a ticket they can give you exact references

on which section(s) of the law you violated.

 

As opposed to this, think about what goes into the User's Manual

of your car.  They may say that you need to step on the second

pedal (counting right to left) if you want to slow your car down

or bring it to a halt, but they will most likely not explain any

of the rules about the stop sign.

 

This is how I see our specification too.  The rules have to be

spelled out in the specification.  How you generate the data or

how you write your AMI models or EDA software which obey those

rules may go into the HOWTO document.  According to this,

spelling out how the content of the .ami file is split into

the In, Out and InOut strings, and how the model and EDA tool

is expected to read and write them belongs to the specification,

as far as I can tell.  Whether you type the .ami file with one

finger or generate it automatically with software could be part

of a HOWTO document...

 

On the other hand, I don't think any of us would be interested

in reading the specification in a BNF form...

 

Arpad

===================================================================

 

From: Walter Katz [mailto:wkatz@xxxxxxxxxx] 
Sent: Monday, December 06, 2010 10:36 AM
To: Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: About the Typos BIRD comments from Fangyi

 

Arpad,

 

The following describes both the content of AMI_parameters_in and
AMI_parameters_out. I think it was always obvious that In and InOut went
into AMI_parameters_in and InOut and Out went into AMI_parameters_out. 

 

| 3.1.2.6 AMI_parameters (_in and _out) 

| 

| Memory for AMI_parameters_in is allocated and de-allocated by the EDA 

| platform. The memory pointed to by AMI_parameters_out is allocated and


| de-allocated by the model. This is a pointer to a string. All the
input 

| from the IBIS AMI parameter file are passed using a string that been 

| formatted as a parameter tree. 

| 

| Examples of the tree parameter passing is: ...

 

Walter

 

 

 

 

 

 

From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mike Steinberger
Sent: Monday, December 06, 2010 11:09 AM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: About the Typos BIRD comments from Fangyi

 

Mike-

I'm going to take this opportunity to remind us all why we have a BNF
syntax description in the first place. Back when we were preparing BIRD
104, I needed to provide this explanation at one point, so perhaps now
is as good a time as any for a refresher.

Obviously BNF is a software technology thing. It describes a syntax in a
way which is completely rigorous and precise. It leaves no room for
misinterpretation. For example, the developer of the latest version of
IBISCHECK knew exactly what we meant, didn't have to ask any questions
about the syntax itself, and produced a completely correct parser. From
what I could see of other aspects of their work, this person is a
thorough professional, so the fact that they got it right came as no
surprise to me.

As is so often the case, a rigorous and precise statement doesn't
exactly make great reading. For example, I don't suppose there are many
people who read mathematicians' proofs for the fun of it.

At the time, Ambrish requested a "plain English" version of the
specification, and I provided it. Note, however, that "plain English" is
an oxymoron, and that as carefully as I tried to write that description,
there's still room for misinterpretation.

I still claim that we're mixing "specification" with "tutorial" in an
undisciplined way that will produce a document which does neither job
well. If we really want "plain English" text that introduces the
specification in a way that's easy to read and learn from, I think
that's a fine idea; however, that material should go into a separate
tutorial document.

My 2c.
Mike Steinberger

Other related posts:

  1. Home
  2. ibis-macro
  3. Archive
  4. 12-2010