[ibis-macro] Re: Meeting Date Changed
- From: "Doug White \(dowhite\)" <dowhite@xxxxxxxxx>
- To: <ibis-macro@xxxxxxxxxxxxx>
- Date: Tue, 17 Oct 2006 02:49:15 -0400
Had the meeting date wrong in the minutes file. Corrected.
Doug
IBIS Macromodel Task Group
Meeting date: 10 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:
- Richard see if Xilinx can join us.
Vikas Gupta joined us today from Xilinx and spoke about their interest in
this group. -done
- Macro Library Documentation
No discussion on this AR this week.
- VHDL library was posted to website (Mike Labonte). -done
- Kumar to write up API proposal in a more formal way so boundaries and
function partitioning could be discussed more productively.
Kumar discussed API proposal in more detail today, discussion below.
-------------
New Discussion:
Michael Mirmak opened this discussion by briefing us on an announcement for a
ballot in IEEE 1076C. This concerns possible API extensions
to VHDL, although only for "digital" VHDL. This seems to be a decent fit for
what we've been talking about in this group. It was mentioned
that these types of things typically get wrapped into AMS in the next revision
of the reference manual, if voted in. Arpad noted that
there was just recently a revision, and it may be quite a while before the next
one. Some concern that we have missed a deadline in this
sense.
Michael propsed a question to the group: If there is an API rolled into AMS,
could that satisfy our requirements, as we've been talking about
for IBIS?
AR: Michael will try to get access to the IEEE document they are voting on.
He will check into access restrictions first. If we get access to
it, we will need a couple of volunteers to read the document and see if it is
worth our while.
It was mentioned that we need to see if this would work for Verilog as well.
Vikas Gupta of Xilinx was introduced to the group by Richard Ward. Vikas
conveyed Xilinx's interest in the general idea of an API and their
interest in how it could work with their existing Matlab infrastructure. Vikas
plans to attend this meeting on a regular basis going forward.
Joe Abler reiterated his concern about the divide-and-conquer approach.
He stated IBM is not going down the path of modeling all of the nonlinearities
of the I/O in a circuit-level model.
IBM does extract input- and output-parasitics which eventually go into the
channel model.
Arpad restated the original assumptions concerning the divide-and-conquer
approach, namely that this approach is based upon the pulse response,
and that the pulse response could be obtained with various existing techniques;
this pulse response could then be fed into a post-processing
or signal processing block.
Joe asked about the intended use of the models (they could be used for
generating the pulse response alone).
Richard Ward expressed some concern about how crosstalk, and the timing/phasing
of it, could be handled in this divide-and-conquer approach and
that it is extremely important at these high frequencies.
Kumar responded that in pulse-response scenario, crosstalk impulse responses
are taken into account as well. Then the simulator could handle
these responses as desired.
Arpad asked a quesion about the impulse responses and whether they really
should only include the passive portion of the system.
Kumar responded that if the V-I curves are indeed linear, then the I/O could be
included in the impulse response.
Arpad wondered whether the V-T curves where important from a waveshape
perspective.
Kumar thought that they weren't necessarily, since most SerDes should be Linear
and Time-Invariant, then a RAMP statement should suffice to
describe it. This makes it easier to fit into the IBIS framework.
Kumar presented the API proposal (powerpoint presentation):
RX_INIT: Basically this is an initialization call for the Algorithmic Modeling
Unit. The Algorithmic Modeling Unit can modify waveforms, or
impulse responses, and send them back to the existing infrastructure.
RX_GETWAVE: Used to actually pass waveforms to the Algorithmic Modeling Unit.
This cannot happen until after RX_INIT successfully completes.
Essentially, the model talks to the EDA system through the API. It modifies
waveforms, extracts recovered clock information.
The model creator would have the flexibility to either modify waveforms on the
RX_INIT call, or if there are sophisticated equalization
algorithms being modeled, then do the modification on RX_GETWAVE.
The EDA system can, once it gets the clock information and the modified
waveform back from the model, display effective eye patterns, bathtub
curves, etc..
AR: Mike to post this powerpoint presentation to the website.
Arpad would like more concrete ideas about how IBIS could be changed to
accommodate this, if this is indeed what we want t pursue.
Presently, Lance and Kumar are creating a BIRD proposal, and plan to present it
to the group soon.
Arpad would like to see ASAP, even if not polished...just wants the main ideas.
Hemant wondered whether he could present their high-level specification for
this, which would include descriptions of model calls, interactions
between software entities, etc..
Arpad would rather they focus on the BIRD for now, and presenting an early
version to the group as soon as possible.
-------------
Next meeting: Tuesday 17 Oct 2006 12:00pm PT
Other related posts:
- » [ibis-macro] Re: Meeting Date Changed
