[ibis-macro] Minutes from the 28 nov 2006 ibis-atm meeting

Attached.
 
        
Doug White
Technical Leader
RSPTG Design Services and Operations

dowhite@xxxxxxxxx
Phone :919.392.4103
Fax :919.392.3902



RTP8M/4/4
7100-8 Kit Creek Road
PO Box 14987
Research Triangle Park, NC 27709
United States
www.cisco.com <http://www.cisco.com/> 

        
        
This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply e-mail and delete all copies of this message.

GIF image

GIF image

GIF image

 IBIS Macromodel Task Group

Meeting date: 28 nov 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, SiSoft
* Walter Katz, SiSoft
  Vuk Borich, Agilent
  Vikas Gupta, Xilinx

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

- Mirmak: Who has permission to access VHDL spec P1076C?
  Has anyone tried?
  Lance needs access info. Must be an IEEE member.
  May be available under IEEE Explorer
  Requires a paid account.

- Mike update macro library documentation
  Will do it this week

- Ian get specifics on pole/zero approach
  - Nothing yet
  - Multiple ways to represent channel characteristics.
  - Impule response may not be flexible enough, as it has a limited time 
component to it (must be truncated), and as such
    may be less accurate.
  - We are looking for ways to make the current proposal more specific.
  - Will current API proposal work with the pole-zero approach?

- Cadence will start a BIRD
  - In internal review.
  - Will be sent next week.

- Todd dig up material on public domain HSPICE syntax
  - No report.

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

AR: Mirmak send spreadsheet on convolution operators

Pole/zero approach
- Kumar: would only apply in Init()
- Ian: impulse response is truncated in time
- What length of response is needed? Should set criteria.
- Walter: Long impulse response makes convolution take a very long time.
  - Agree with Ian that proposed structure is not sufficient.
  - Could not design current channel project with Cadence API.
  - API needs to handle both time- and frequency-domain approaches.
- Time to do convolution proportional to square of impulse response.
- API can support multiple formats, freq. vs. time domain
- Kumar:  Currently, API wouldn't handle pole-zero approach in that if the TX 
or RX decide to modify the the impulse reponse,
  no way for them to send the modified response back to the EDA tool in the 
correct format.
- Ian: EESof would probably prefer S-param
- Mike L.:  Why can't a parameter be passed to tell EDA tool what TYPE of data 
it will be working with?

- Hemant: API must be extended to allow pole/zero tables
- Hemant:  Also, the data-type parameter may work.

AR: Hemant share details with Ian before proposing BIRD, and modify the BIRD so 
that API could accommodate both types of data.

Arpad: IBIS 4.2 spec is vague about parameter "assignments"
- provides param names only, is optional
- external model must have defaults built-in
- parameter GUI needs to know type and current value
- Arpad: would be better to have this in IBIS
- Could call the same model definition with different params to create 
different model instances.

- Walter: typ, min, max should be typ, slow, fast
- Mirmak: no presets, would rather have "knobs" to turn. Ex. SPICE
- Need to give legal range, which may be a set of values. Also units.
  - Ian proposed this at the DAC summit.
- Arpad: declaration should remain in AMS model
- Lance:  Maybe we don't need a "type" declaration in the IBIS file, perhaps it 
should be in the AMS file, or at least IBIS should
  pass the right type of data to the AMS model, else error.
- Bob:  tool vendors are having a lot of expectations placed upon them, like 
doing type-conversions for specific languages.
- Arpad:  What if the AMS internals need a parameter to be in a different 
format than what is in the IBIS file.  Does the EDA tool
  need to take care of the syntax conversion???
- Walter: Use "IBIS" syntax!
- Arpad:  What about "non-IBIS" types?
- Walter:  Need some extra types for IBIS.

- How to handle units and scaling?
- should be consistent with other parts of IBIS

AR: Walter send units/parameterization ideas to Arpad

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

Next meeting: Tuesday 04 Dec 2006 12:00pm PT

Other related posts: