[ibis-macro] Minutes from the 07 nov 2006 ibis-atm meeting

  • From: "Doug White \(dowhite\)" <dowhite@xxxxxxxxx>
  • To: <ibis-macro@xxxxxxxxxxxxx>
  • Date: Mon, 13 Nov 2006 09:51:06 -0500



Doug White

Tech Lead, Signal Integrity

Service Provider/Routing Technology Group

Cisco Systems, Inc.

(919) 392-4103


IBIS Macromodel Task Group

Meeting date: 31 oct 2006

Members (asterisk for those attending):
* Arpad Muranyi, Intel Corp.
* Barry Katz, SiSoft
* Bob Ross, Teraspeed Consulting Group
* Doug White, Cisco Systems
  Hemant Shah, Cadence Design Systems
* Ian Dodd, Mentor Graphics
* Joe Abler, IBM
* John Angulo
  John Shields, Mentor Graphics
  Ken Willis, Cadence Design Systems
* Kumar, Cadence Design Systems
* Lance Wang, Cadence Design Systems
* Michael Mirmak, Intel Corp.
  Mike LaBonte, Cisco Systems
  Paul Fernando, NCSU
  Randy Wolff, Micron Technology
* Richard Ward, Texas Instruments
  Sanjeev Gupta, Agilent
  Shangli Wu, Cadence
* Todd Westerhoff, Cisco Systems
* Walter Katz, SiSoft
  Vuk Borich, Agilent
  Vikas Gupta, Xilinx

Review of ARs:

- IEEE 1076c:  Michael suggested everyone log into the IEEE website and 
download this document to review.  No one on the call 
  said that this would be a problem.
        -this AR will be closed.

- Macro Library Documentation
  - Mike will get to this in Nov



-  Arpad will be travelling on vacation next week, may not be able to attend.  
Michael Mirmak has tentatively volunteered to host the
   meeting.  If he cannot for some reason, Mike Labonte could host; Walter Katz 
will be Mike's backup.

New Discussion:

-  Kumar began the meeting discussion by presenting "AMI Proposal 
Background-Proposed Changes to IBIS API Specifics"
        -  2 main things done by AMI models:  TX & RX equalization, and clock 
        -  There are all kinds of postprocessing that could be done by the EDA 
tool...these things are NOT covered by the API proposal.
        -  Main goal of API proposal is to be simple and flexible.
        -  An example case, with a 4-tap TX, modeled with traditional IBIS 
capability (VI curves, Spice, AMS, whatever...could be modeled
           from information in the datasheet, typically), and an RX which is 
represented with a simple load model, was covered in the prez.
           In this case the TX had user-defined tap-selections (no 
        -  Kumar showed the waveform corresponding to the impulse response 
resulting from the IBIS simulation, which would be fed to the AMI models
           for subsequent processing.
        -  Arpad/Michael M.:  Do we really only need 1-bit of characterization 
for the impulse response?
        -  Kumar:  Yes, subsequent processing, such as FIR filter application, 
will capture all of the taps for the TX, for example (in an ideal sense).

- Proposed changes to IBIS
        -  Cadence proposes a new section called something like "AMI"
        -  Parameters can be contained here.  This section needs to be flexible 
in that parameters will be very device-specific.
        -  It was noted that if the model doesn't get required information that 
is needed for it's initalization or operation, there must be
           some error mechanism specified.
        -  In this proposed scenario, every model must come with some 
documentation explaining what the parameters are for, what they do.
        -  The number of parameters and their type are not restricted.
        -  We then digressed into more software centric discussions...

-  More detail about Functions/Calls
        -  AMI_Init, AMI_Getwave, AMI_Close, should be in EVERY AMI model.
        -  Barry:  Trying to understand the structure here...these functions 
are in an executable somewhere?
        -  Kumar:  Point is that the function calls are always the same (that 
is, the function ARGUMENTS are the same).  Some arguments may contain a lot
           of parameters in a character string.
        -  What does the AMI_Init do in the case of receiver initialization?
                -  Kumar:  The impulse reponse is passed as a matrix, and the 
RX AMI model may modify it "in place" (reference the pdll_server_param_obj
                   argument).  In other words, it is done in "private" data 
space for the model, and will only be acted upon later by the AMI model 
                   itself.  AMI_Getwave can use this data.  No other function 
needs to know about it anyway.
        -  Based on ONE AMI_Init, AMI_Getwave may be called 100s or 1000s of 
        -  Kumar proposed to put clock edge times in a "clock tics" vector, 
something like [0 200e-12 400e-12 ...]
        -  Waveforms may need to be resampled in order to provide uniform 
timesteps, etc.
        -  EDA tool must know what the function arguments are and what they 
        -  Arpad:  Need to keep defining what is needed in IBIS to enable all 
of this to happen.
        -  Ian:  We should discuss the potential drawbacks of this approach, 
such as the consequences of adaptive time-stepping.

AR:  Lance will send the presentation to Mike Labonte.  Mike will post to the 
website.  We should all make an effort to comment on this.  Don't hesitate
     to use the reflector for this.


Next meeting: Tuesday 14 Nov 2006 12:00pm PT

Other related posts:

  • » [ibis-macro] Minutes from the 07 nov 2006 ibis-atm meeting