[ibis-macro] Re: IBIS-AMI Correlation and BIRD Update - comments

  • From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
  • To: <ibis-macro@xxxxxxxxxxxxx>
  • Date: Wed, 2 Apr 2008 09:12:34 -0700

Vuk,
 
Thank you very much for stepping up on my defense.  What
you say about the .NET jargon is exactly what I had on
mind when I wrote that slide.
 
In fact to me this is such a natural language, that I
am not even sure what is on that slide that bothers
Todd.  Is it that phrase (garbage collection), or the
computer graphics illustrating "shhhh..." meaning keep
this a secret, referring to the comment "The truth will
set you free".  I thought that sentence was humorous,
and I wanted to react to that with a similar, humorous
graphics...
 
Arpad
========================================================

________________________________

From: vuk_borich@xxxxxxxxxxx [mailto:vuk_borich@xxxxxxxxxxx] 
Sent: Wednesday, April 02, 2008 9:05 AM
To: twesterh@xxxxxxxxxx; Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: IBIS-AMI Correlation and BIRD Update -
comments



Hi Todd,

 

We are all aware that "garbage collection" is a well-known software
concept used extensively in managed code frameworks like .NET and Java,
and that Arpad's paper uses it in that context, not as his personal view
of any vendor's coding style. 

 

Is my understanding correct?

 

Vuk

From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Todd Westerhoff
Sent: Wednesday, April 02, 2008 8:54 AM
To: Arpad_Muranyi@xxxxxxxxxx; 'IBIS-ATM'
Subject: [ibis-macro] Re: IBIS-AMI Correlation and BIRD Update -
comments

 

Arpad,

 

If I were to come up with a high level summary of your concerns, it
would include:

 

- use of persistent memory between the AMI_Init and AMI_Getwave calls

- modifying time-domain waveforms in place

 

I know I'm simplifying, but I believe that's a reasonable 10,000 foot
view.

 

Here's what we've all accomplished with IBIS-AMI

 

            - it's defined

            - it's approved

            - it works

            - we have working models in customer's hands

 

Does that mean everything associated with IBIS-AMI models is simple and
intuitive?  Nope.  Are there areas that we might do differently if we
had the chance to do it all over again?  Sure.  Is it worth opening up
an defined spec and asking vendors to change models they've already
developed (again)?  Probably not.

 

I'm not trying to minimize or ignore the impact on the model developer,
and I really do get that these techniques require time to understand.
I'm usually the "marketing guy" in any technical conversation, and
assume that if I can understand this stuff, it's accessible to others.

 

My point is this - as we already have a standard and a infrastructure
that works, so why don't we turn our attention to developing reference
models that isolate the model developer from the details of the
simulator interface?  Isolate the impulse response and waveform
filtering section of the reference models, with a *your specific
filtering code goes here* approach.  I think that's entirely workable
within the existing specification.  We don't need to rework the
standard, we need to take the reference code we've published as part of
the standard and build on it.

 

I'm therefore advocating that we work to upgrade reference models and
toolkits in response to your concerns.  I believe this addresses the
concerns you've raised without requiring anyone to rework their existing
models. 

 

 

Which brings me to the unpleasant part.

 

I have to take exception to phrases like:

 

"Stuff is going in and out of the functions BEHIND the SCENES through
the backdoors"  

 

"yet we are already setting the stage for doing things in a kludge way"

 

"computer science back door trickery in order to achieve the fundamental
goal of this technology"

 

 

and my favorite example from your presentation at DesignCon:

 

 

 

If you're trying to work towards an open standard, these choices of
language and graphics aren't helping your case.  In my personal opinion,
this is consistent with what I'd expect from a vendor interested in
delaying progress.

 

I apologize for having to make what sounds like a personal accusation -
I don't mean it that way ... but I am requesting that we all choose our
words very carefully.

 

This is on the record, after all.

 

Todd.

 

Todd Westerhoff

VP, Software Products

SiSoft

6 Clock Tower Place, Suite 250

Maynard, MA 01754

(978) 461-0449 x24

twesterh@xxxxxxxxxx

www.sisoft.com

 

-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, April 02, 2008 1:00 AM
To: IBIS-ATM
Subject: [ibis-macro] IBIS-AMI Correlation and BIRD Update - comments

 

Hello IBIS-AMI experts,

 

I want to preface this message with a "warning" to eliminate the

possibilities of going off in a tangent of personal remarks, and

ending up hurting each other's feelings.  My intensions are NOT

to end up with a blood bath, but the seriousness of the issues I

want to raise could very easily take us there if we don't handle

the topic in a professional way.

 

First, I would like to comment on the presentation we saw today

in the IBIS-ATM meeting.

 

 

1)  I am fine up to pg. 9., but I have a little problem on

pg. 9.  This is really a small thing, but can be confusing

considering the big picture.  Based on pg. 8, I gather that

the meaning of the arrow pointing to the black box from above

is "this is what's inside the box".  On pg. 9, however, the

same notation seems to mean "this is the input to the black

box".  (I am saying this based on the example Tx model).  As

I said, this is a small detail, but the reason I mention this

is because this leads me to something bigger later.

 

 

2)  On pg. 10 I am missing a statement that would clarify that:

 

   h_teg(t) = h_cr(t) * h_tei(t)

 

(where "_" stands for subscript and "*" stands for convolve),

or, on the right side of the bottom half I would have used the

same expression that is found on the left side of the bottom

half of pg. 11 to better clarity.  Again, I say this based on

what I see in the example Tx model.  (You actually show that

equivalence on pg. 12, but pg. 12 is still misleading somewhat

because it gives me the impression that all of that is inside

GetWave, when in reality that top arrow is an input to GetWave).

 

In terms of the drawing, I am missing an arrow indicating that

the output of the Init box is fed into the GetWave box.  I would

have drawn a similar arrow that you have on pg. 11, except

pointing to the GetWave box instead of the expression on the

left of the bottom half.

 

 

3)  I admit that these are nitpicky comments and I can understand

that Todd's busy schedule may have played a major role for missing

such minor details.

 

 

4)  However, as I am studying the example Tx model's source code,

I feel compelled to bring up a serious concern I have regarding

the coding style which may have an effect on this BIRD (and the

specification).  You may say, who am I to complain about coding

style when I made such a fool of myself (somewhat deliberately)

in my last DesignCon presentation, pretending that I don't know a

thing about C programming...  Please be patient and try to hear

me out despite of that.

 

 

Here is my understanding of the structure of the example Tx model:

 

Init:

=====

- the impulse response is passed to Init via a pointer variable

  along with several other parameters, including the filter tap

  coefficients

- the code convolves the impulse response with the tap coefficients

  and returns the results "in place", i.e. in the same memory 

  location where the impulse response came in

- in preparation for the convolution in GetWave, an integration

  is performed on the equalized impulse response to obtain a step

  response.  One could argue that this code would really belong

  in the GetWave function, but I can see it being here too, since

  it is related to the impulse response in some ways.

- NOTE: this step response is NOT returned in any of the function

  arguments to the caller.  It is just left in memory for GetWave

  assuming that no garbage collection is happening until we are

  done with GetWave.

 

GetWave:

========

- the stimulus waveform is passed to GetWave via a pointer variable

  along with some other parameters

- the output of Init that was left in memory is used AS THE SECOND

  INPUT to the convolution algorithm.  This second input is not

  passed into the function as a function argument "normally" as

  the other inputs are.

- additional code takes care of the block by block execution of this

  function using the same technique of leaving things in memory to

  pass left overs from a previous run as input for the next run.

- the result is returned "in place", i.e. in the same memory 

  location where the stimulus waveform came in.

 

What bothers me the most about this example Tx model is that not all

of the input and output arguments are passed through the function call

interface.  Stuff is going in and out of the functions BEHIND the

SCENES through the backdoors!  Don't take me wrong, I think this is

a wonderful and clever engineering marvel for situations when there

is no other way to achieve things, hats off to whoever developed it.

But we are defining a new specification, we have all the freedom

to do it right, yet we are already setting the stage for doing

things in a kludge way.

 

As far as I am concerned, each function should have all of their

inputs and outputs go through the function arguments (and returns).

I don't think this would have to result in memory penalty (due to

duplication of data when calling or exiting the functions) if

pointers are used appropriately.  Even for the block by block

repetitive execution of GetWave, I could see mechanisms for

passing and returning the "left overs" around the boundaries

between the calls.  Something similar to "carry out" and "borrow"

could be implemented on the function calls for that, but I could

see even better ways of doing that without having to write any

code in the GetWave function itself (to reduce the burden of the

model maker).

 

 

5)  Now, we could argue that this is just a coding style problem,

we could fix it by writing a better example Tx model.  Unfortunately

not so.  The reason being that Section 10 of the BIRD describes

each function with a precise list and description for each argument.

There are no provisions there to pass two inputs to GetWave as it

may be necessary if we use the SiSoft interpretation of how data

flows.  There are no provisions there to do a "carry out" and

"borrow" for running the GetWave multiple times for block by block

execution either.

 

But even more, pg. 18 of today's presentation proposes a new

parameter associated with GetWave: "Use_Init_Output".  How would

the caller of GetWave pass in the output of Init without an

additional function argument for the second input?  This is only

possible through the backdoor technique I described above!

 

 

6)  I think we should have a spec with a function interface which

provides all of the necessary inputs and outputs, so that model

makers would not need to resort to computer science back door

trickery in order to achieve the fundamental goal of this

technology.

 

A properly designed function interface would also make the use of

other languages easier, because the function interfaces are much

more similar between the languages than the backdoor capabilities.

 

I firmly believe that correcting these issues would make the life

of the model maker much easier.  People usually understand function

calls much more readily than back door tricks which rely on memory

management features of a specific language.  These types of things

are invented by experienced programmers, not electronic engineers...

 

 

In summary:

===========

 

I would like to take this opportunity to clean up a little bit as

follows:

 

a)  Each function should have all of its arguments on the function

interface

 

b)  Each function should be an independent function on its own, i.e. one

function should not depend on memory allocations in the other, other

than

using pointer variables in the argument.

 

c)  The functions should not rely on stuff left in memory, i.e. no

back door data exchange should be allowed between functions (unless

someone is a hacker, just kidding).

 

d)  The caller of the functions should take care of passing arguments

around from one function's output to another function's input.

 

e)  The caller of the GetWave function should take care of breaking

up larger data blocks into smaller pieces and executing GetWave

repetitively without relying on any code related to this in the

GetWave function itself.

 

There may be more (or less), but I hope you all get the point.

 

I hope this will not result in a bunch of virtual rotten eggs and

tomatoes thrown at me...

 

Thanks,

 

Arpad

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

---------------------------------------------------------------------

IBIS Macro website  :  http://www.eda.org/pub/ibis/macromodel_wip/

IBIS Macro reflector:  http://www.freelists.org/list/ibis-macro

To unsubscribe send an email:

  To: ibis-macro-request@xxxxxxxxxxxxx

  Subject: unsubscribe

 

JPEG image

Other related posts: