[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
Attached
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
-------------
Opens:
- 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
recovery.
- 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
optimization).
- 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
times.
- 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
mean.
- 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
