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

  • From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
  • To: <msteinb@xxxxxxxxxx>, <ibis-macro@xxxxxxxxxxxxx>
  • Date: Tue, 7 Dec 2010 11:54:00 -0800

Mike,

 

For your curiosity, my problem was Walter's statement:

"The AMI_Init function usually will allocate memory that contains things
like tap settings and impulse response, and makes them available to the
AMI_GetWave function.  This has always been the methodology for Init
passing information to GetWave, and calls to GetWave passing information
to future calls to AMI GetWave."

which did not mention AMI_memory_handle, and as such

could imply that the Init function can allocate memory

for information exchange between itself and GetWave

without letting anyone know about it.  Of course this

is not prohibited in the spec so at this point there is

nothing that could prevent it from happening.

 

Arpad

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

 

From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mike Steinberger
Sent: Tuesday, December 07, 2010 1:36 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: About the Typos BIRD comments from Fangyi

 

Arpad-

It does appear that I misunderstood you.

All of us model developers absolutely depend on using AMI_memory_handle,
as described in IBIS 5.0, and as used as a publicly visible argument to
the model functions. That's what we need and that's all that we need.

I am left wondering what point you were trying to make.

Mike S.

On 12/07/2010 01:19 PM, Muranyi, Arpad wrote: 

Mike,

 

I think you misunderstood what I meant to say.

 

I was referring to Init allocating some memory that is

seen by GetWave, but not accessible through the arguments.

AMI_memory_handle DOES provide access, and if Init passes

stuff to GetWave using that handle, I think I can live with

that.

 

Arpad

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

 

From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mike Steinberger
Sent: Tuesday, December 07, 2010 12:33 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: About the Typos BIRD comments from Fangyi

 

Arpad-

I couldn't disagree with you more. Right now we have a spec that works,
and you want to turn it into a spec that doesn't work.

AMI_memory_handle gives model developers exactly the flexibility they
need to get their job done, and you want to take that flexibility away.
In point of fact, model developers need a mechanism that you call "under
the table" in order to produce working models without divulging
proprietary design details. A lot of the information that's passed from
AMI_Init() to AMI_GetWave() is truly proprietary and should stay that
way. Now you want to at the very least constrain the form that
proprietary information can take.

What problem are you trying to solve? How would constraining the use of
AMI_memory_handle help you solve that problem?

Mike S.

On 12/07/2010 12:17 PM, Muranyi, Arpad wrote: 

This was one of my earliest complaints about AMI too, that Init

can have hidden conversations with GetWave under the table (sorry,

I meant in memory).  I think these functions should exchange all

information through their interface (i.e. arguments).  Mike's

suggestions of using AMI_memory_handle might be acceptable, but

I would strongly suggest that its use for this purpose should be

spelled out in the spec.

 

Arpad

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

 

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

 

Arpad,

 

The AMI_Init and AMI_GetWave functions are entries in a C routine. The
AMI_Init function usually will allocate memory that contains things like
tap settings and impulse response, and makes them available to the
AMI_GetWave function.  This has always been the methodology for Init
passing information to GetWave, and calles to GetWave passing
information to future calls to AMI GetWave.

 

Walter 

 

From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Tuesday, December 07, 2010 11:56 AM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: About the Typos BIRD comments from Fangyi

 

With regards to the "obvious" on how the parameter types

In, Out, and InOut are passed in and out of the DLL, I

need to restate a question I asked once before:

 

If we establish the rule that In and InOut is passed into

the DLL through the AMI_parameters_in argument, and Out

and InOut are returned by the DLL through the AMI_parameters_out

argument, how are we going to deal with the situation when the

Init function contains an optimizer and returns the optimized

parameters (tap coefficients, for example) though the

AMI_parameters_out argument?  Remember, the GetWave function

does NOT have an AMI_parameters_in argument.  How is the

Init function going to pass the optimized parameters to

GetWave?

 

Initially I thought that the AMI_parameters_in argument is

visible to GetWave also, and it could see the optimized

parameters in that argument.  But this discussions seems to

indicate that the Init function is not returning the optimized

parameters in the AMI_parameters_in argument, on in the

AMI_parameters_out argument which is not visible to GetWave,

as far as I can tell...  Am I missing something "obvious"?

 

Any suggestions?

 

Thanks,

 

Arpad

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

 

 

 

 

From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Monday, December 06, 2010 2:10 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: About the Typos BIRD comments from Fangyi

 

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