[ibis-macro] Minutes from August ibis-atm meetings
- From: Mike LaBonte <mike@xxxxxxxxxxx>
- To: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
- Date: Tue, 28 Aug 2012 16:20:56 -0400
Minutes from August ibis-atm meetings are attached.
Mike
IBIS Macromodel Task Group
Meeting date: 07 Aug 2012
Members (asterisk for those attending):
Agilent: * Fangyi Rao
* Radek Biernacki
Altera: David Banas
Julia Liu
Hazlina Ramly
Andrew Joy Consulting: Andy Joy
Ansys: Samuel Mertens
* Dan Dvorscak
* Curtis Clark
Steve Pytel
Arrow Electronics: Ian Dodd
Cadence Design Systems: Terry Jernberg
* Ambrish Varma
Feras Al-Hawari
Cavium Networks: Johann Nittmann
Celsionix: Kellee Crisafulli
Cisco Systems: Ashwin Vasudevan
Syed Huq
Ericsson: Anders Ekholm
IBM: Greg Edlund
Intel: * Michael Mirmak
Maxim Integrated Products: Mahbubul Bari
Mentor Graphics: * John Angulo
Zhen Mu
* Arpad Muranyi
Vladimir Dmitriev-Zdorov
Micron Technology: * Randy Wolff
* Justin Butterfield
NetLogic Microsystems: Ryan Couts
Nokia-Siemens Networks: * Eckhard Lenski
QLogic Corp. * James Zhou
Sigrity: Brad Brim
Kumar Keshavan
Ken Willis
SiSoft: * Walter Katz
Todd Westerhoff
Doug Burns
* Mike LaBonte
Snowbush IP: Marcus Van Ierssel
ST Micro: Syed Sadeghi
Teraspeed Consulting Group: Scott McMorrow
* Bob Ross
TI: Casey Morrison
Alfred Chong
Vitesse Semiconductor: Eric Sweetman
Xilinx: * Mustansir Fanaswalla
* Ray Anderson
The meeting was led by Arpad Muranyi
------------------------------------------------------------------------
Opens:
- Mike: Having trouble with eda.org email reflector
- Please send email to ibis-macro@xxxxxxxxxxxxx, ibis
--------------------------
Call for patent disclosure:
- None
-------------
Review of ARs:
- Arpad prepare example BIRD 125 IBIS file set
- not done
- Bob to propose a simpler way for addressing the needs of parameter passing
under [External Model] and [External Circuit]
- not done
-------------
New Discussion:
Walter showed a presentation "IBIS-ISS Package Modeling":
- slide 1 to 3 are overview slides
- slide 4:
- Walter: Aggressor channels may be less accurate than victim, but must model
crosstalk well
- slide 5:
- Walter: Drivers are on the same chip for FEXT
- slide 6:
- Walter: Banks imply associations between groups of buffers
- slide 7:
- Walter: The syntax used here is mostly to highlight the required
functionality
- Some materials are from vendors who can not be named, some can
- slide 8:
- Walter: Voltage supplies can have one name but multiple nodes
- May need to support resistors in package
- There is some redistribution of power and ground pin to pin
- [Pin Mapping] may have some overlap, need to investigate
- Alternative is to add Pullup_Signal_Name and Pulldown_Signal_Name
- Arpad: It may be wise to stay away from [Pin Mapping] for new package syntax
- Walter: That may be a rat hole
- slide 9:
- Walter: Cdie and Rdie may not represent the interconnect complexity well
enough
- slide 10:
- Walter: This shows how the syntax might work together
- Slide 11:
- Walter: Die names here could be called "implicit"
- X and Y coordinates are added to support MCP
- Not fully advocating this feature
- Fangyi: What are the units?
- Walter: It is given here as "inch", but it could be microns for silicon
- slide 12:
- Walter: Supply die data are given separately here
- These are explicit die names
- slide 14:
- Walter: Both implicit and explicit die names are used here
- On-die models are assigned by name
- Ports are listed in the order they appear in ISS
- slide 15:
- Walter: The package model example here passes Length in as a parameter
- slide 16:
- Walter: Pin names here are the high pins of diff pairs
- This should cover 99% of package usage
- slide 17:
- Walter: This should handle 90% of package model cases
- slide 18:
- Walter: VDD and VSS are used to denote associated supplies
- slide 19:
- Walter: Not sure if this section about resistors is correct yet
- slide 20:
- Walter: This has 2 DQ aggressors and 1 DQS aggressor
- The model name for the NEXT aggressor is given
- DDR3 models tend to give values from standards, not what the part does
- Fangyi: Is this saying where crosstalk is coming from?
- Walter: The industry requires the aggressor and victim models to be the same
- slide 21:
- Walter: Some vendors want to supply more than 3 corners
- This uses the {squiggly bracket} substitution syntax
- slide 22:
- Walter: It would be convenient to just use a Touchstone file, if that is
all that is needed
- slide 23:
- Walter: Some models will describe a whole interface
- Some terminals may not be correct in this example
- slide 23:
- Walter: Some models will describe a whole package
- NC is used to leave some ports unconnected
- Reduced s-param models can be derived from larger ones
- slide 24:
- Walter: They should be organized by sij instead of frequency to make it
easier
- slide 25:
- Walter: A Perl script can produce the derived parameter syntax
- slide 27:
- Walter: Everything for package models can be used for on-die models
- slide 28:
- Walter: There are a few errors in this example
- Slides 29 & 30:
- Walter: These show an example for banks
- Any number of voltage supplies can be passed in
- slide 31:
- Walter: I have tried to cover everything that others have requested
- Is anything else required?
- Do we need all that is here?
- James: All signals are point to point, that should be a category
- People want to see coordinates because we get power models with just one
node name for all
- Need to regroup into different quadrants
- Walter: A connection could have just one supply name and several bumps
- James: Are the victim features a superset of the aggressor features?
- Walter: Correct
- Arpad: Are the different examples using the same syntax?
- Walter: An interface model is different
- Only the victim channel is valid
- Only that one has all the crosstalk modeled
- Aggressors only generate noise
- The syntax for them is different
- The port order has "Pin" and "Pad" notation, for example
- For interface models have actual pin and bump numbers
- In interface models everyone is both victim and aggressor
- Fangyi: In victim models you need to say which channel is valid
- Walter: The ones with reserved names are the victims
- Fangyi: We should be able to quickly identify which models are aggressor
- Walter: That is a constraint of the person generating the subckt
- Fangyi: Why specify aggressors?
- Walter: They appear at a certain point in the subckt port order
- There may be better ways to give this information
- Arpad: This should be done in a more general way
- Fangyi: You may want to analyze only 1 of 100 channels, and only a few
neighbors matter
- Walter: We need to know the pin and pad of each victim and aggressor
- James: Pad is on the die side?
- Walter: Pin is pin name and pad is bump pad
- We need a consistent naming convention
- Arpad: Using the P side of diff pairs only works if names are sequential
- Walter: The [Diff Pin] section gives the other side
-------------
Next meeting: 14 Aug 2012 12:00pm PT
Next agenda:
1) Task list item discussions
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
IBIS Macromodel Task Group
Meeting date: 14 Aug 2012
Members (asterisk for those attending):
Agilent: Fangyi Rao
* Radek Biernacki
Altera: * David Banas
Julia Liu
Hazlina Ramly
Andrew Joy Consulting: Andy Joy
Ansys: Samuel Mertens
* Dan Dvorscak
* Curtis Clark
Steve Pytel
Arrow Electronics: Ian Dodd
Cadence Design Systems: Terry Jernberg
* Ambrish Varma
Feras Al-Hawari
Cavium Networks: Johann Nittmann
Celsionix: Kellee Crisafulli
Cisco Systems: Ashwin Vasudevan
Syed Huq
Ericsson: Anders Ekholm
IBM: * Greg Edlund
Intel: Michael Mirmak
Maxim Integrated Products: Mahbubul Bari
Mentor Graphics: * John Angulo
Zhen Mu
* Arpad Muranyi
Vladimir Dmitriev-Zdorov
Micron Technology: * Randy Wolff
* Justin Butterfield
NetLogic Microsystems: Ryan Couts
Nokia-Siemens Networks: * Eckhard Lenski
QLogic Corp. * James Zhou
Sigrity: Brad Brim
Kumar Keshavan
Ken Willis
SiSoft: * Walter Katz
Todd Westerhoff
Doug Burns
* Mike LaBonte
Snowbush IP: Marcus Van Ierssel
ST Micro: Syed Sadeghi
Teraspeed Consulting Group: Scott McMorrow
* Bob Ross
TI: Casey Morrison
Alfred Chong
Vitesse Semiconductor: Eric Sweetman
Xilinx: Mustansir Fanaswalla
Ray Anderson
The meeting was led by Arpad Muranyi
------------------------------------------------------------------------
Opens:
- None
--------------------------
Call for patent disclosure:
- None
-------------
Review of ARs:
- Arpad prepare example BIRD 125 IBIS file set
- not done
- Bob to propose a simpler way for addressing the needs of parameter passing
under [External Model] and [External Circuit]
- not done
-------------
New Discussion:
Walter showed a presentation "IBIS-ISS Package Modeling Discussion":
- This is already on the web site
- slide 2:
- Walter: Would like to have open discussion, hoping to answer questions today
- slide 3:
- Walter: Do we need supply voltages?
- Do we need XY coordinates?
- The NEXT/FEXT discussion was confusing, there is a better way to describe
this
- slide 4:
- Walter: What voltage should be applied to the package pin?
- Bob: IBIS already addresses this
- It is specified at the model
- Randy: [Pin Mapping] specifies this
- Walter: Two models could be connected to VDD with different voltages
- slide 5 & 6:
- Walter: XY is more reliable than CAD net name or pin number
- Coordinates help generate package and die models, but are not needed in
them
- Arpad: IC vendors should know what the die and package look like by the
time they have IBIS
- slide 7:
- Walter: Someone said [Pin Mapping] should not be used
- This proposal is to give power and ground signal names in the models
- Arpad: BIRD 145 is similar
- slide 8 & 9:
- Walter: A hierarchical numbered port description scheme is better than
positional port names
- This distinguishes between pins and pads
- slide 10:
- Walter: Here is an example using model names and polarity
- I will post corrections to this slide
- slide 12:
- Walter: Multi-channel coupling can be described with Channel and Victim
parameters
- Supply names like VDD are given here too
- Radek: Does this give the model name like the [Component]?
- Walter: No this is a package model
- slide 13:
- Walter: This format can be use to specify sparse ports to extract from an
s1000p
- Walter: We can have questions here
- James: How do we map pin to die pad?
- Power pins map many to many
- Walter showed a [Pin Die Data] example from his previous presentation
- Walter: This shows how implicit die pad names allow for that mapping
- James: Does this work for power?
- Walter: Many old IBIS files have NA for all power pins
- The [Supply Die Data] slide shows many to many mapping
- Walter showed the Rambus example to explain further
- Ambrish: Could smaller channels make more use of the crosstalk info?
- Walter: Package models are made by interface, quadrant, bank, whole package
etc.
- No one simulates the whole package
- Ambrish: In IBIS we mostly care about channels
- Walter: We must decide what needs this satisfies and which to support
- Randy: Is there a way to handle multi-die?
- This is badly needed
- Walter: That is the next step, we can modify EBD
- I proposed EMD a few years ago, it should be easy to add the new features
to EBD
- Greg: The intention is to support existing and new models?
- Walter: Existing IBIS does not have IBIS-ISS
- Greg: It seems this is about helping to extract from boards
- Walter: This is not about that
- Walter: There may be too much functionality listed here
- Next we must decide how to proceed
- BIRDs 125 and 145 may or may not have all that is needed
- My approach is model based, not pin based
- A model can give data that applies to many pins
- In BIRD 125 the on-die model calls the buffer models
- Here the die is just between the existing models
- James: More details would be needed to compare this to Arpad's proposal
- Walter: Yes, much work is needed once we choose a path
- James: It needs to be organized so models from different companies/divisions
can work
- Walter: The interfaces are all by pin/model/die names
- Arpad: Do we need to decide syntax or functionality
- Walter: Functionality
- The syntax could be keyword or parameter trees
- Parameter trees can be very powerful
- Arpad: BIRD 125 could be extended to cover all of this
- So syntax is the only difference
- The questions are about large s-params, XY coordinates, voltages
- Walter: I have been unable to see how to extend BIRD 125
- Arpad: The question is if we need all this functionality
- Walter: We could vote feature by feature next week
- Arpad: One general purpose syntax might satisfy all of them
- Questions could be whether we want RC circuits, LC circuits, etc.
- We do not need to choose because IBIS-ISS can do all of them
- Ambrish: It would be good to have the voting list emailed in advance
AR: Walter email a list of package modeling features for voting
-------------
Next meeting: 21 Aug 2012 12:00pm PT
Next agenda:
1) Task list item discussions
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
IBIS Macromodel Task Group
Meeting date: 21 Aug 2012
Members (asterisk for those attending):
Agilent: * Fangyi Rao
* Radek Biernacki
Altera: David Banas
Julia Liu
Hazlina Ramly
Andrew Joy Consulting: * Andy Joy
ANSYS: Samuel Mertens
* Dan Dvorscak
Curtis Clark
Steve Pytel
* Luis Armenta
Arrow Electronics: Ian Dodd
Cadence Design Systems: Terry Jernberg
* Ambrish Varma
Feras Al-Hawari
Cavium Networks: Johann Nittmann
Celsionix: Kellee Crisafulli
Cisco Systems: Ashwin Vasudevan
Syed Huq
Ericsson: Anders Ekholm
IBM: * Greg Edlund
Intel: Michael Mirmak
Maxim Integrated Products: * Mahbubul Bari
Mentor Graphics: * John Angulo
Zhen Mu
* Arpad Muranyi
Vladimir Dmitriev-Zdorov
Micron Technology: Randy Wolff
* Justin Butterfield
NetLogic Microsystems: Ryan Couts
Nokia-Siemens Networks: * Eckhard Lenski
QLogic Corp. * James Zhou
Sigrity: * Brad Brim
Kumar Keshavan
Ken Willis
SiSoft: * Walter Katz
Todd Westerhoff
Doug Burns
* Mike LaBonte
Snowbush IP: Marcus Van Ierssel
ST Micro: Syed Sadeghi
Teraspeed Consulting Group: Scott McMorrow
* Bob Ross
TI: Casey Morrison
Alfred Chong
Vitesse Semiconductor: Eric Sweetman
Xilinx: * Mustansir Fanaswalla
Ray Anderson
The meeting was led by Arpad Muranyi
------------------------------------------------------------------------
Opens:
- Bob: Would like to address IBIS parser issues
--------------------------
Call for patent disclosure:
- None
-------------
Review of ARs:
- Walter email a list of package modeling features for voting
- Done
- Arpad prepare example BIRD 125 IBIS file set
- not done
- Bob to propose a simpler way for addressing the needs of parameter passing
under [External Model] and [External Circuit]
- not done
-------------
New Discussion:
Bob discussed AMI changes in the new IBIS parser:
- Bob: Initially there was a warning for parameter name collisions
- It now checks for collisions only within each branch
- The leaf check for Description has been fixed, allowing only one per branch
- Arpad: This Friday might be the big day for IBIS 5.1
Luis Armenta introduced himself:
- He is working on AMI models at ANSYS
Walter showed a presentation:
- Walter: This presentation has been sent out
- It summarizes use of parameter trees and IBIS-ISS for various models
- Some slides are brief summaries
- slide 5:
- Walter: This example explains the proposal for packages
- slide 6:
- Walter: This tree shows a typical on-die model
- There are 4 bump pads for power and ground
- Power and signals could be merged together
- slide 7:
- Walter: This package model tree looks similar to the on-die one
- slide 8:
- Walter: This adds length modeling where that is known
- slide 9:
- Walter: This package tree shows victims and aggressors for crosstalk
- slide 10:
- Walter: Arpad asked for both package and on-die trees here
- This makes the model understandable and easy for EDA tools to use
- slide 11:
- Walter: [Path Description] can be converted programmatically to IBIS-ISS
- slide 12:
- Walter: Here is a legacy EBD file
- It has comments to show what things are
- Arpad: Do the slashes precede comments?
- Mike: They are for continuation, pipe characters for comments
- Walter: I may have modified this
- slide 13:
- Arpad: The red line doesn't say how the IBIS-ISS package is connected
- Walter: Good point but we will not be pursuing that
- slide 15:
- Walter: Gd and RS are critical, but EBD doesn't support them
- slide 16:
- Walter: This replaces a path description
- James: Is U1 a reference designator?
- Walter: Yes, this EBD is for a DIMM board
- Fangyi: Would this work without the pin order?
- Walter: That could work
- slide 17:
- Walter: EMD "module" is less constraining than EBD "board"
- slide 18:
- Walter: This is the legacy EBD converted to EMD
- The only new thing here is Diff_Pins
- slide 19:
- Walter: Nothing is different for a connector
- Defining the A and B sides may not be necessary
- Vendors often give slice models from which all pins are derived
- Fangyi: The unconnected pins are assumed to be open?
- Walter: Or 50 ohms to ground, etc.
- A typical method is to extract a smaller s4p
- Fangyi: It still depends on what is assumed for the other ports
- Walter: They are effectively open
- Radek: That will not work
- Arpad: Some models are not symmetric in each direction
- Walter: The A and B signal names handle that
- slide 20:
- Walter: Some of our existing BIRDs are gobbledygook
- There is confusing baggage
- slide 21:
- Walter: [External IBIS-ISS Model] is a simple way to handle it
- Stimulus and other items are easily defined in tree format
- Arpad: Stimulus is what the DtoA converters handle
- This is a new keyword for something that exists
- Walter: The Model_Ports syntax is very simple
- slide 22:
- Walter: We should reject the listed BIRDs and create a new IBIS 6.0 EMD
section
- I will make this motion Friday at the Open Forum meeting
- slide 21:
- Fangyi clarified how the TX Stimulus parameter works with the model ports
- Walter: IBIS-ISS is invalid for most buffer models because it can't handle
input and enable
- PWLs or macros would have to be added, as in IBIS-BSS
- Model_Ports is similar to Model Connection Protocol
- James: How to tell which ports are connected to stimulus?
- Walter: Drive is a reserved name for that
- We might want to call that Stimulus
- This attempts to not make too many changes
- It will be a lot of work to write this BIRD, it should be a group effort
- Fangyi: Coloring the reserved names may help avoid future questions
- James asked about the format of the Tstonefile parameter
- Walter: It goes into the AMI file to get the value
- Some AMI models have many "knobs", and some change the Tstonefile
- Radek: The right side model is used only with AMI models?
- Walter: Values can be directly specified here
- slide 22:
- Ambrish: This replaces all of the BIRDs proposed for rejection?
- Walter: Yes, for example the package and on-die models replace [Circuit
Call]
- What I'm proposing requires only one new parser
AR: Walter send slides with modifications for posting
Bob: This Friday IBIS 5.1 is the priority
- There may not be much time for other items
-------------
Next meeting: 28 Aug 2012 12:00pm PT
Next agenda:
1) Task list item discussions
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
IBIS Macromodel Task Group
Meeting date: 28 Aug 2012
Members (asterisk for those attending):
Agilent: * Fangyi Rao
* Radek Biernacki
Altera: * David Banas
Julia Liu
Hazlina Ramly
Andrew Joy Consulting: Andy Joy
ANSYS: Samuel Mertens
* Dan Dvorscak
* Curtis Clark
Steve Pytel
Luis Armenta
Arrow Electronics: Ian Dodd
Cadence Design Systems: Terry Jernberg
* Ambrish Varma
Feras Al-Hawari
Cavium Networks: Johann Nittmann
Celsionix: Kellee Crisafulli
Cisco Systems: Ashwin Vasudevan
Syed Huq
Ericsson: Anders Ekholm
IBM: * Greg Edlund
Intel: * Michael Mirmak
Maxim Integrated Products: Mahbubul Bari
Mentor Graphics: * John Angulo
Zhen Mu
* Arpad Muranyi
Vladimir Dmitriev-Zdorov
Micron Technology: Randy Wolff
* Justin Butterfield
NetLogic Microsystems: Ryan Couts
Nokia-Siemens Networks: Eckhard Lenski
QLogic Corp. * James Zhou
Sigrity: * Brad Brim
Kumar Keshavan
Ken Willis
SiSoft: * Walter Katz
Todd Westerhoff
Doug Burns
* Mike LaBonte
Snowbush IP: Marcus Van Ierssel
ST Micro: Syed Sadeghi
Teraspeed Consulting Group: Scott McMorrow
* Bob Ross
TI: Casey Morrison
Alfred Chong
Vitesse Semiconductor: Eric Sweetman
Xilinx: Mustansir Fanaswalla
Ray Anderson
The meeting was led by Arpad Muranyi
------------------------------------------------------------------------
Opens:
- Arpad: Should we meet next week, given the labor day holiday?
- No one said they can not attend
- We will meet next week?
- Arpad: Should we allow TX and RX of different AMI_Version in the same
simulation?
- Walter: This is somewhat academic
- Only one old model has Use_Init_Output
- Our tools will have no problem
- Mike: Models from different vendors might be in the same simulation
- Arpad: The question is whether to allow it in the specification
- Radek: The spec already allows an older model to be in a newer IBIS file
- Arpad: The question is if they should be allowed in the same simulation
- Radek: We can't restrict that, people will mix models
- Walter: Certain combinations require deconvolution
- The math for that is clear, this is not a problem
- It is a rare case anyway
- Radek: We could post guidelines outside of the IBIS spec
- Michael M: Thank you to the group for making IBIS 5.1 a reality
- Greg: We should discuss roadmap, especially packaging
- Arpad: There is an agenda item for that
--------------------------
Call for patent disclosure:
- None
-------------
Review of ARs:
- Walter send slides with modifications for posting
- Done
- Arpad prepare example BIRD 125 IBIS file set
- Not done
- Will do this only if we keep BIRD 125
- Bob to propose a simpler way for addressing the needs of parameter passing
under [External Model] and [External Circuit]
- Not done
- We can drop this
-------------
New Discussion:
Arpad: We need to discuss what is next for our group
- Walter showed a presentation "IBISx"
- slide 2:
- Walter: Legacy IBIS has everything in one file
- Package information should be in a separate EMD file
- slides 3 & 4:
- Walter: Translating an legacy package model to EMD is straightforward
- slide 6:
- Walter: The die model is similar
- slide 7:
- Walter: Models also translate easily
- slide 9:
- Walter: This is the roadmap
- Some BIRDs should be rejected
- Some BIRDs that are AMI related would not be rejected, go into 5.2
- Backchannel BIRDs would be in 5.3
- We have not seen demand for backchannel modeling
- New BIRDs for 6.0 will be needed
- Ambrish: We should make backchannel higher priority
- Walter: That is OK
- Gennum has asked for it, but not many users yet
- Arpad: We should have a new category for analog models
- Radek: This is an overhaul of the general IBIS syntax
- Legacy IBIS has no clear hierarchy
- We need to analyze what we gain and lose
- Greg: Do we maintain backward compatibility?
- Walter: No, this is a new standard
- Bob: I am not in favor of splitting IBIS into different sections
- IBIS will continue for a while
- Walter: It will continue but we do not have to maintain it
- I/V curves and other things would be reused, not reinvented
- Arpad: We explored going to equation based models
- This might be a good time to revisit that
- Walter: Yes, that might be an additional parameter to Legacy and IBIS-BSS
- Kumar proposed parameter trees years ago, and they are easy to work with
- James: This is mostly about syntax
- Are we propose any changes to the functional part?
- Walter: Adding a Tstonefile is a functional improvement, for example
- Ambrish: The other proposal is to use IBIS-ISS
- Arpad: This is starting over
- It might take years to finish this
- Can a well defined analog model wait that long?
- Walter: I think this can be done in six months
- Arpad: IBIS 5.1 took 4 years
- John: AMI was going to be simple too at the beginning
- I don't see a difference
- Arpad: It could take quite a while to do equation based models
- Walter: Yes, but I am proposing stuff we already know how to do
- Originally we made mistakes because we did not understand the problems
- We have better understanding now of the physics
- Arpad: Writing a specification is not just about physics
- Getting vendors to agree on details can be difficult
- James: We need to address the question of what problem we are trying to solve
- Walter: IC vendors need to supply broadband package and on-die models
- For both signals and power delivery
- Arpad: The point is that we don't have to rewrite the syntax for that
- James: We need to analyze how this helps achieve that
- Walter: We still have no example of how to create needed models with the
existing BIRDs
- On-die models are independent of package models
- John: Having just a proposed syntax may not help enough
- Michael M: We should have a drawn example, not in the proposed syntax
- Then see what it takes to create examples
- Walter: Greg said he was willing to supply examples
- Arpad: We could try that
- Walter: IC vendors should report what they can supply and what they want
AR: Greg and Michael M provide examples to show what IC vendors need
Bob: I do not agree with the roadmap slide
- We should not assume that it has been accepted
-------------
Next meeting: 04 Sep 2012 12:00pm PT
Next agenda:
1) Task list item discussions
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives
Other related posts:
