[ibis-macro] Minutes from the 03 oct 2006 ibis-atm meeting

From: "Doug White \(dowhite\)" <dowhite@xxxxxxxxx>
To: <ibis-macro@xxxxxxxxxxxxx>
Date: Mon, 9 Oct 2006 10:52:46 -0400

Attached.  It's really hard to keep us with these discussions so forgive
me if I missed or misconstrued something.

 

Doug

IBIS Macromodel Task Group

Meeting date: 03 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

-------------
Review of ARs:

- Redo calendar invitations to this meeting.
  Calendar invitations are redone.  Dropped Todd's Meetme info and added Mike 
Labonte's (Mike LaBonte)

- Richard see if Xilinx can join us.
  Richard invited a couple of people from Xilinx as well as some from STMicro 
(Ottawa).  Expected them to call in.

- Macro Library Documentation
  Hope to finish this by the end of the year.
  Mike L. has some schedule conflicts until November 7th, better after then.

-------------
New Discussion:

Arpad has given Mike Labonte a new VHDL-AMS library (precompiled) to post to 
the website.

AR:  Mike to post this week.

Next discussion concerned the apparent progress we have made in previous 
discussions surrounding the API proposal, among other things.
This discussion began with the general idea that has been discussed regarding 
the fact that we may be able to use a "divide and 
conquer" approach to make progress.  That is, perhaps we could use more typical 
IBIS or AMS driver and receiver models in order to 
generate the pulse response.  The driver model would need to be able to handle 
preemphasis, and the receiver model would simply be an
equivalent load-model.

Walter said that SiSoft is in the process of verifying that this simple 
representation of drivers is sufficient at these very high
frequencies.  He summarized his view of the current state of this simple driver 
modeling, stating that some are describing the
drivers with 
        -Driver impedance
        -Voltage swing(s)
        -Ccomp
        -Macro libraries...

Kumar stated that the basic purpose of the API is based on the view of the 
driver and receiver as "signal processing entities", and
as such the API is proposed as the best way to handle such entities.

Arpad reviewed the previous discussion concerning the divide-and-conquer 
approach, with the two general steps:
        1.  Driver and Receiver analog behavior to produce the pulse response 
could be modeled with existing techniques.
        2.  The sophisticated behavior of circuits could be summed up as:
                - Receiver Equalization algorithms
                - Receiver Clock Recovery systems
                - Possibly adaptive FIR filtering for the Drivers

It was stated that in any implementation, the taps for equalization should be 
made available to the simulator, so that
optimization might be enabled.

Michael Mirmak brought up a very basic question:  Are we trying to keep 
IBIS/AMS as a standard based in the realm of 
describing circuit-based behavior, or are we thinking of making it a signal 
processing standard as well?

Arpad reiterated:  It appears right now that we need to separate the electrical 
aspects of the models from the signal processing 
aspects of the models.  If this is so, then current techniques are capable of 
handling the electrical portion.  Then the question
becomes:  What is the API for the signal processing function?

Some brief discussion about how to get the tap-coefficient information into the 
IBIS structure, and a "parameter selector" statement
was brought up as an example.

Walter said that his sense is that AMS cannot handle the sophisticated receiver 
algorithms.  Ian thinks that AMS is most definitely
up to the task, but perhaps a bit inconvenient.  Do we need to decide whether 
AMS can handle this or not?  Regarding the convenience
issue, there are a couple of existing linear simulator tools out there that do 
not support AMS.

Current pervasive practice is behavioral modeling, mostly in Matlab.  Kumar 
noted that Cadence wanted to allow for this existing
infrastructure, and provide an API to make it easier to provide the 
models/algorithms.

There was a proposal to start a BIRD for the driver model changes necessary to 
handle such things as preemphasis, at least to 
break the gridlock and get started down a path.

AR:  Kumar suggested writing up the API architecture in a more formal way, so 
that the boundaries and partitioning of function could
be discussed more intelligently.

Near the end of the meeting, Joe Abler stated that he was concerned about the 
accuracy of these "circuit-based" models used to
generate the pulse response.  There was some ensuing confusion about what the 
concerns were actually about, and Arpad asked
whether the "divide and conquer" approach mentioned above was actually 
desirable or not.

AR:  Joe Abler to describe in more detail his fundamental concerns with this 
approach.

Arpad asked the group if anyone would step up and start offering concrete 
proposals for the next meetings.


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

Next meeting: Tuesday 10 Oct 2006 12:00pm PT

[ibis-macro] Minutes from the 03 oct 2006 ibis-atm meeting

Other related posts: