[ibis-macro] Minutes from the 26 sep 2006 ibis-atm meeting
- From: "Mike LaBonte \(milabont\)" <milabont@xxxxxxxxx>
- To: <ibis-macro@xxxxxxxxxxxxx>
- Date: Mon, 2 Oct 2006 13:29:39 -0400
Minutes from the 26 sep 2006 ibis-atm meeting are attached.
AR: Todd and Mike rearrange calendar invitations
Mike
IBIS Macromodel Task Group
Meeting date: 29 sep 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
-------------
Review of ARs:
- Restructure web pages (Mike LaBonte)
- Done.
- Richard see if Xilinx can join us.
Was told 2 people would join us, but they are not here today.
-------------
New Discussion:
We discussed how we would host meetings going forward, with Todd
leaving Cisco to join SiSoft. Mike will continue to provide phone bridge
information. Some cleanup of the MS Outlook meeting invitations may be
in order.
AR: Todd and Mike rearrange calendar invitations
Todd asked if we are gridlocked.
The solution must:
- satisfy multiple EDA vendors
- satisfy multiple IC vendors
- protect IP
- support combined driver/receiver design
Todd pointe dout that we don't know how other vendors do this. We should ask.
A new type of simulation si needed to optimize tap coefficients to get the
best channel performance. Models must have coefficients accessible to simulator.
Ian said that the EDA tool must be able to tell what works for a specific PCB.
Richard disagreed.
Arpad divided drivers into 2 types:
1) tap coefficient (simply compensates for channel)
2) adaptive (also compensates for aging)
The EDA tool adds value by determining coefficients.
The EDA tool can also judge if the adaptive range is suitable for the PCB
design.
Ian would like to be able to turn adaption off to know if the PCB design
is well centered within the range of adaptiion.
Kumar said we need to go in a different direction. This is a general signal
processing problem. IBIS must provide a platform where different vendors
can interact. He chose the C language because everyone has it.
Arpad asked if IBIS should have keywords for tap coefficients, etc.?
Kumar believe that this would be a problem because the meaning of the
paraeters would not be constant.
Walter pointed out that we need to think about receiver models, which can be
broken into 2 parts:
1) reactive load
2) everything after that
he suggested that IBIS break the circuit into 2 pieces, but also that
maybe this group can't do the 2nd part. Drivers are the 3rd part and
must be characterized.
Ian said that Mentor basically likes the Cadence proposal but some
details must be worked out.
Todd said that driver models must have good enough data to generate pulse
responses or do time domain simulations. Therefore we need a full circuit
simulation-capable model. If the model takes tap coefficients as input it
doesn't matter if we analyze all tap settings in 1 simulation or in many.
Instead of inviting more IC vendors in, maybe we should devise a survey.
We agreed that the pieces that IBIS must provide for SerDes analysis are:
- Driver model
- Receiver load model
- Receiver algorithm
Kumar said we don't know what architecture will work, which makes it
difficult to decide on a partitioning now. So far, drivers are less
complicated than receivers. Joe pointed out that we can also have
multi-level signaling, etc.
Walter felt that, at a minimum, IBIS needs to add a generic parameter passing
capability for models.
Ian stated that DLLs are too tough to distribute, although executables are OK.
Communicating through a pipe would be best.
-------------
Next meeting: Tuesday 03 Oct 2006 12:00pm PT
Other related posts:
