[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

- Arpad to change IBIS buffer implementation to have two input control
- Everyone - target semiconductor companies for the macro library and
key contacts
Next meeting is Tuesday November 15th.
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 

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 

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 
- Currently supplying encrypted HSpice models for signal integrity work
- 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 

Next meeting: Tuesday 15 nov 2005

Other related posts:

  • » [ibis-macro] November 8th meeting minutes