[ibis-macro] November 8th meeting minutes
- From: "Todd Westerhoff (twesterh)" <twesterh@xxxxxxxxx>
- To: <ibis-macro@xxxxxxxxxxxxx>
- Date: Tue, 8 Nov 2005 17:07:08 -0500
AR's:
- Arpad to change IBIS buffer implementation to have two input control
thresholds
- Everyone - target semiconductor companies for the macro library and
key contacts
Next meeting is Tuesday November 15th.
Todd.
Todd Westerhoff
High Speed Design Group Manager
Cisco Systems
1414 Massachusetts Ave - Boxboro, MA - 01719 email:twesterh@xxxxxxxxx
ph: 978-936-2149
============================================
"Always do right.
This will gratify some people and astonish the rest."
- Mark Twain
meeting date: 08 nov 2005
attending: Arpad Muranyi, Todd Westerhoff, Barry Katz, Walter Katz, Bob Ross,
Ian Dodd
-------------
Review of ARs:
AR: Mike fix EQ amp rcvr template
No report at this meeting
AR: Ian will draft a BIRD for analog-only AMS support in IBIS
Arpad and Ian are working on this
AR: Mike add extrapolation warning to module documentation
No report at this meeting
-------------
PWL triggered sources: current version of library uses two tables: a rising
edge triggered and falling edge
triggered table. Rising and Falling edges have their own triggering thresholds
(vthr, vthf, respectively).
Initial conditions are set based on the value of the input at t=0. If the
value is above vthr, the output
is set to the first point in the falling edge, and vice versa.
Non-triggered PWL with time as independent axis changed to use horizontal
extrapolation.
How should IBIS buffers behave with respect to their control input? Current
library starts the output
sweep whenever the input voltage passes thru 0.5V. We agreed we should change
the IBIS buffer to have
two input control thresholds, both of which will default to a trigger of 0.5V.
AR: Arpad to change IBIS buffer implementation to have two input control
thresholds
We also need to revisit default values for each element, both to make sure they
are consistent and to
ensure anything simulated with default values (nothing passed in) - it doesn't
get mistaken for being
a real model.
We're still stuck with our ability to pass parameters into arrays. The LRM
allows parameters to be passed
into arrays, but multiple tools have not implemented this. We expect the
language definition to be
amended to allow file names to be passed as parameters, but this looks to be
somewhat farther out,
as the language needs to be amended, the tools changed, etc.
Currently the library only can implement parameter arrays by explicit
definition; all of the elements
of the array must be explicitly defined within the definition of the building
block. This means
building blocks with tables have to be cut and pasted into the models that use
them, and the tables
defined within each building block definition.
VHDL-AMS does not currently have this problem with populating arrays.
Driving usage for the current library - we spent some time discussing which
semiconductor companies
we could approach about testing the current macro library. We identified the
following attributes
of a company that would be likely to participate:
- Has output buffers with complex behavior
- Demonstrated expertise and resources devoted to IO modeling for signal
integrity
- Currently supplying encrypted HSpice models for signal integrity work
OR
- Needs to supply HSpice-level models but is unable to
- Demonstrated history of innovation in supplying signal integrity models
Companies that come immediately to mind are Intel, Micron and Xilinx. Todd
asked everyone to spend
some time before the next meeting thinking about which companies we should
approach and whether we
have good contacts at those companies
AR: Everyone - target semiconductor companies for the macro library and key
contacts
-------------
Next meeting: Tuesday 15 nov 2005
Other related posts:
- » [ibis-macro] November 8th meeting minutes
