DATE: 02/11/04
SUBJECT: February 2, 2004 EIA IBIS Summit Meeting Minutes
VOTING MEMBERS AND 2004 PARTICIPANTS
Ansoft Corporation (Eric Bracken)
Apple Computer (To Be Determined)
Applied Simulation Technology Norio Matsui*
Cadence Design Systems C. Kumar*, Lance Wang*
Cisco Systems Syed Huq*
Fairchild Semiconductor (Graham Connolly)
Hitachi ULSI Systems (Kazuyoshi Shoji)
Huawei Technologies (Jiang Xiang Zhong)
Intel Corporation David Keates*, Peter T. Larsen*
Wilson Leung*, Michael Mirmak*
Arpad Muranyi*, Steve Peterson*
LSI Logic Frank Gasparik
Matsushita (Panasonic) Atsuji Ito*
Mentor Graphics John Angulo*, Weston Beal*
Guy de Burgh, Ian Dodd*
Micron Technology Paul Gregory*, Randy Wolff*
Molex Incorporated (Gus Panella)
Motorola (Rick Kingen)
National Semiconductor (Lee Sledjeski)
NEC Electric Corporation (Itsuki Yamada)
North East Systems Associates Edward Sayre*
Philips Semiconductor (D.C. Sessions)
Samtec (Corey Kimble)
Siemens AG Eckhard Lenski
Siemens Medical (Acuson) David Lieby*
Signal Integrity Software Robert Haller*, Barry Katz*
Sigrity Raymond Chen*, Jiayuan Fang*
Sun Microsystems (Tim Coyle)
Synopsys (Hailong Wang)
Texas Instruments Hector Torres*
Teraspeed Consulting Group Tom Dagostino*, Scott McMorrow*, Bob Ross*
Time Domain Analysis Systems Steve Corey*
Zuken (& Incases) (Michael Schaeder)
OTHER PARTICIPANTS IN 2004:
Apache Design Yu Liu*
Bayside Design Daniel Lambalot*, Kevin Roselle*
Conexant Garry Felker*
Cortina Systems Robert Badal*
EFM Ekkehard Miersch*
Extreme Networks Lin Shen*
GEIA (Chris Denham)
Green Streak Programs Lynne Green*
Independent Kim Helliwell*, Jon Powell*
Netlogic Microsystems Eric Hsu*
Samsung Il Seong*
Silverback Systems Gil Gafni*
In the list above, attendees at the meeting are indicated by *.
Principal members or other active members who have not attended are in
parentheses. Participants who no longer are in the organization are in
square brackets.
UPCOMING MEETINGS
The bridge numbers for future IBIS teleconferences are
as follows:
Date Telephone Number Bridge # Passcode
February 20, 2004 European SUMMIT, Paris, France NO TELECONFERENCE
February 20, 2004 1-916-356-2663 3 673-0282
All meetings are 8:00 AM to 9:55 AM US Pacific Time. Meeting agendas
are typically distributed seven days before each Open Forum. Minutes
are typically distributed within seven days of the corresponding meeting.
When calling into the meeting, provide the bridge number and
passcode at the automated prompts. If asked by an operator, please
request to join the IBIS Open Forum hosted by Michael Mirmak.
For international dial-in numbers, please contact Michael Mirmak.
NOTE: "AR" = Action Required.
--------------------------------MINUTES-----------------------------------
INTRODUCTIONS AND MEETING QUORUM
The IBIS Summit Meeting was held in Santa Clara, California at the
Westin Hotel in conjunction with the International Engineering
Consortium's (IEC) DesignCon 2004 Conference. The summit was co-sponsored
by IBIS, DesignCon, and Cisco Systems. 40 people representing 25
organizations attended.
The notes below capture some of the content and discussions. The meeting
presentations and other documents are uploaded at:
http://www.eda.org/pub/ibis/summits/feb04a/
Michael Mirmak opened the meeting. Michael thanked the IEC and
DesignCon for providing a room and other logistics, noting that
IBIS is a co-sponsor of DesignCon. Michael also thanked Syed Huq
and Cisco for providing the summit refreshments. He also singled out Lynne
Green for her assistance with calls for papers and setting the agenda.
Finally, Michael thanked the presenters and participants for attending.
Michael asked everyone in the room to introduce themselves. The group was
well-attended by semiconductor vendors and model providers (eleven),
EDA tool vendors (six) and users of IBIS models (three).
Michael asked if there were any new issues or discussion items to add to
the agenda. No issues were raised.
PRESENTATIONS AND DISCUSSION TOPICS
The rest of the meeting consisted of presentations and discussions. These
notes capture some of the content and discussion. More details are
available in the documents uploaded to the location noted above.
IBIS CHAIR'S REPORT
Michael Mirmak, Intel Corporation
Michael reviewed the recent work of the IBIS Open Forum and IBIS community
at large. The Open Forum has made stunning progress in advancing behavioral
modeling over the past six months. In addition to approving IBIS 4.1,
which introduces links to Verilog-AMS and VHDL-AMS models into IBIS,
a golden parser for IBIS 4.0 has been publicly released. Further,
the IBIS Interconnect Modeling Specification (ICM) 1.0 was issued and
a golden parser released to the public, under an open-source license
agreement. The IBIS Quality Committee continues to provide feedback on
models and modeling issues. Despite a slow economy, Michael observed that
finances continue to be strong, with 28 paid members and ten purchasers of
(IBISCHK4) Golden Parser licenses.
While IBIS Open Forum work has been successful, challenges still remain
ahead for IBIS as a whole. In order to better support IBIS tool
vendors, model makers, and users, Michael reiterated his call for cookbooks
for both ICM and IBIS 4.0. Michael also suggested that more corporate and
industry-publication guidance be provided on the new languages linked
to IBIS under version 4.1. Further, the Open Forum should continue to
expand and enhance a global IBIS community; support of the European DATE
summit must continue, but the Open Forum should also consider holding
"Electronic Roadshow" presentations, which Michael detailed in his
"IBIS Futures Roadmap" presentation (see below). Finally, Michael thanked
the IBIS Open Forum participants and community members for their continued
support.
IBIS QUALITY
Robert Haller, Signal Integrity Software (SiSoft)
Robert reviewed the purpose of the Quality Committee and summarized the
backgrounds of the various participants. He then provided an overview
of the current, untitled IBIS Quality document and its chapters. Robert
noted that the first draft is complete and has some material
cross-referenced with the earlier IBIS Accuracy Handbook.
The key idea behind the IBIS Quality document is its description of quality
levels. A Level 0 model has passed the simple IBISCHK parser checks without
errors. At Level 1, the model has additionally passed basic simulation
testing with transmission lines and the like. A Level 2a model has been
correlated in simulation with a transistor-level model.
Robert observed that comments within the model are used to document the
various levels and the outcome of testing. A separate document is not
intended to be created for distribution with the model. Some participants
expressed concern that these checks, even if completed automatically, might
result in changed model text. Robert acknowledged these concerns, but
noted that the core IBIS data would not be changed by the IBIS Quality
procedure.
Robert concluded his presentation by noting and thanking the committee
participants.
For additional information on the quality committee and to be included on
the mailing list send mail to ibis-quality@freelist.org. The IBIS quality
committee web site is available on the IBIS web page or at
http://www.sisoft.com/ibis-quality
IBIS DIE V-T TABLES FROM PART OR BOARD MEASUREMENTS
Bob Ross, Teraspeed Consulting Group
Bob summarized his presentation material by observing that IBIS at-die
V-T tables can be generated from at-pin or at-board measurement data
through a mathematical process. Specifically, the process consists
of a linear transformation of the time-domain information taken at the
non-die-pad location. If package and board loading information is
available, this can be added in simulation to an IBIS model containing
at-pin or at-board V-T curves and the differences noted; these same
differences can then be adjusted out of the original at-pin data.
To demonstrate the process, Bob provided an example data set with
a package modeled with LC components. Using Bob's method, a model
V-T curve set could be created with from 0.8% to 7.2% mismatch against
the I-V curves.
Michael Mirmak noted that this process still required rather accurate
die capacitance (C_comp) information. Scott McMorrow observed that
this could be derived from TDR measurements fairly accurately, with
minor losses in the package for edges up to 100 ps. He further observed,
however, that the LC modeling technique for the package parasitics
is likely to cause errors for edges faster than 1 ns. Steve Peterson
suggested that the method did not account for losses or any DC shifting
in the V-T curves between the die pads and the measurement points.
Jon Powell inquired as to how division of the data into typical, minimum
and maximum corners could be justified, as parts which reflect full
manufacturing tolerances may not be available. Bob agreed and stated
that temperature and voltage variations were used to approximate the entire
range of manufacturing variations.
CREATING IBIS MODELS FOR STACKED-DIE PACKAGES
Steve Peterson, Intel Corporation
Steve began by describing his group's applications for IBIS. Typically,
designs call for several dice to be combined within a single package;
as the dice are from separate vendors, schematics and detailed transistor-
level models are not available. Instead, to perform simulations,
Steve described a process by which I-V and V-T curves are generated for
use under the [Model Selector] keyword, as combinations of the driving
die effects and the loading of the non-driving dice. A single package
model is used per pad. At present, EBD is used to model package
parasitics, but other formats are being investigated, particularly for
"Y" structures. The EBD includes a worst-case inductance as a sum of
the inductances of all paths.
Lance Wang and Lynne Green raised questions regarding die capacitance.
Should the C_comp values of each of the combined dice be summed or
should some other adjustment method be used to account for die
capacitance and loading? Steve mentioned that correlation data was
so far indicating a good match to silicon behavior, but that other
methods of C_comp adjustment were under investigation.
IBIS FUTURES ROADMAP
Michael Mirmak, Intel Corp
Michael summarized the history of IBIS parsers and IBIS specification
releases since version 1.0. On average, a new parser version has been
released 28 months after the final release of the corresponding IBIS
specification. In addition, Michael noted that a new major IBIS
release is approved every 24 months, on average. To ensure that
IBIS remains useful to the industry, Michael suggested tightening these
time delays, observing that, as the PC, transportation, and consumer
electronics industries converge, product cycles are also converging on
an 18 month pace. The Open Forum should be more proactive in seeking out
and including support for new technologies, rather than waiting for
industry adoption before including support in IBIS. To address this,
he suggested a revived Futures Subcommittee, which would be chartered
to develop IBIS and ICM improvements. A few have already been proposed:
explicit digital states for 4.1 input ports, user-definable measurement
and input threshold parameters, and formal links between ICM and IBIS.
In addition, to better support the IBIS community in adopting new
technologies and modeling approaches, Michael proposed a formal Cookbook
Subcommittee to revise the 1997 IBIS 2.1 cookbook. This would clarify the
meaning and use of the 3.2 and 4.0 keywords introduced since that time, and
provide appropriate examples plus data extraction guidance. Further,
Michael elaborated on his "E-Roadshow" proposal. As the global economic
situation still does not permit extensive travel, but globalization is
still spreading in the industry, a new method is needed to assist and train
IBIS users and model makers worldwide. The Open Forum should provide short
training sessions, called "E-Roadshows," in time zones convenient to the
US, Europe and Asia, featuring one or two summit-quality presentation and
question periods. This would help bring state-of-the-art training to other
parts of the globe while not incurring the costs associated with
international travel. Michael showed a graphical timeline illustrating the
most desirable milestones for these deliverables, and noted that both of
the new committees would begin forming in the coming weeks.
Several participants commented that EDA tool product cycles are also
approximately 18 months, so a compression of the specification-to-parser
time may be very difficult to accomplish. In addition, Bob Ross noted that
more than just one or two early adopter organizations would be necessary to
ensure full acceptance of new modeling features, even with cookbooks and
training. Lance Wang also raised the issue that, even with awareness of
time zones, language barriers might still make such training sessions
difficult.
ADDING ON-CHIP CAPACITANCE IN IBIS FORMAT FOR SSO SIMULATION
Raymond Chen, Sigrity
Raymond described the method used to add loading to approximate power
delivery and SSO effects in system simulations. IBIS in general is useful
for these analyses, as it is faster than a transistor-level simulation and
is often the only kind of data available from external vendors. Package
models, either IBIS RLC or using matrices, include the coupling and mutual
effects needed to analyze aggressor/victim behavior.
Sigrity's tool approach for IBIS power delivery is to add package and power
delivery networks automatically between the power/ground pins and the die
pads using the [Pin Mapping] keyword. In general, the Sigrity approach to
IBIS instantiation resembles the Synopsys HSPICE* B-element. Several kinds
of analysis -- active signals, plus "stuck high" and "stuck low" for
victims -- can be included to note power delivery network impact on system
simulation results. An additional Cdie, to represent die capacitance not
specifically associated with buffers but between power and ground supplies,
is added to make simulation results more realistic (SSO sims with IBIS can
be too pessimistic without an additional Cdie). More accuracy can be added
with an Rdie in series with the Cdie.
Arpad Muranyi noted that a non-IBIS Cdie may not be required, as a
[Series Element] capacitance could be used between [Pin Mapping] ground and
power pins, with Rdie included. Raymond agreed and observed that the
industry should be including Cdie information with their models, regardless
of series element support. In general, the value of Cdie is typically
10 nF to 100 nF for dice with advanced interfaces, with the value
representing the entire die. Bob Ross suggested consulting the 2001 summit
presentation archive, as some data there suggested Cdie values in the
femtofarad range.
Jon Powell and Ian Dodd inquired about crowbar current during switching,
which IBIS may or may not be explicitly including. Raymond responded that
IBIS data can be represented using two non-linear switches for the pullup
and pulldown circuit behaviors. This would account for crowbar currents
and is already included in Sigrity's tools.
Further, Raymond observed that the current EBD format for package data does
not adequately represent on-die power delivery networks, as coupling
information is excluded and a one-to-one pad-to-pin mapping is assumed.
Jon Powell suggested that a nodal representation is required, which
Sigrity's tool assumes when reading IBIS data. Arpad Muranyi noted that
ICM permits more detailed network modeling, but that more explicit IBIS
descriptions of die pads vs. die pins may be required, perhaps with a
pad-level keyword or the 4.1 [Node Declarations] keyword. John Angulo
responded that, as 4.1 was currently defined, this approach would be limited
to use with VHDL-AMS, Verilog-AMS or Berkeley SPICE buffer representations.
A VHDL-AMS TRUE DIFFERENTIAL BUFFER MODEL USING IBIS V3.2 DATA
Arpad Muranyi, Intel Corp.
Arpad began his presentation by referring to earlier summit discussions on
VHDL-AMS representations of IBIS buffer data, in 2002 and 2003. Using his
earlier VHDL-AMS single-ended buffer code, he developed a differential
representation which uses totem-pole IBIS data for the common mode
components and a specially-fitted curve for the differential relationship
between the die pads. He then presented the actual code changes from his
original single-ended model. The code now includes differential capacitance
estimates and the adjustments required to the V-T curves for this new
capacitance. The new code also adds the necessary coefficients for V-T and
I-V curve matching. Finally, a second-order equation is used to create
an I-V surface to represent the differential currents.
Arpad then demonstrated how the VHDL-AMS model compares to transistor-level
model performance and also against Synopsys HSPICE*, using the B-element
[Series MOSFET] keyword to represent the differential currents. Overall,
the matching was best for differential loads matching the cases used to
generate the V-T data for the model. Load values lower than those used in
the original V-T curves also showed good correlation. Values higher,
especially for open circuits, showed increasingly poor correlation against
the circuit model, though the [Series MOSFET] model behavior was comparable.
Michael Mirmak suggested that perhaps more accurate models for manufacturing
tolerances and corners should be generated with V-T curve fixtures
deliberately higher than the PCB targets anticipated. Bob Ross observed
that the poor behavior of the unloaded circuit may be due to current
starvation, which IBIS models do not predict well without additional data.
TRUE DIFFERENTIAL BUFFER MODELS (CASE STUDY)
Arpad Muranyi, Intel Corp.
Arpad Muranyi summarized the history of differential model analysis at
previous summits. In 2002 and 2003, he presented a new way of using surface
plots and other methods to determine the common mode and differential mode
currents in circuit designs. Now that a VHDL-AMS model of a differential
buffer is available (see above), what process should be used, if any, to
automate the differential data collection process? Arpad noted that several
types of buffers, such as LVDS, contain on-die terminations between die
pads, implying a differential current flow. However, the differential
current response of other types (PCIe, S-ATA, etc.) is not clear.
Arpad analyzed several types of buffer designs, including LVDS with and
without on-die termination and a S-ATA buffer. In all cases without on-die
termination, the differential impedance seen in surface plots of the
operating region was in excess of 100 Mohms. Only the on-die termination
LVDS design showed a lower differential impedance, specifically 600 ohms.
Even with pre-emphasis, a 100 Mohm differential impedance was still seen
when on-die termination was not present.
From this, Arpad concluded that the current method of representing
differential IBIS models using two single-ended models with complementary
switching is adequate for even high-speed applications. Michael Mirmak
noted that die capacitance may still be a problem for pre-emphasis designs,
but that overall Arpad's findings agreed with his experience.
OTHER DISCUSSIONS AND AD HOC PRESENTATIONS
Michael Mirmak raised four issues for discussion: non-monotonicity in curves
as detected by the parser; package modeling and connectivity, as described
by Raymond Chen in his presentation; IBSI 4.1 issues; and [Driver Schedule]
interpretations.
Paul Gregory posed his question on parsing of non-monotonic waveforms to the
group: does the current IBIS parser report I-V monotonicity issues before or
after the clamp curves are summed with the drive curves? Bob Ross explained
that, in version 4.0.1 of the parser, IBIS 3.2 models would continue to be
interpreted without summation, while IBIS 4.0 models would be checked after
summation. Bob explained that this was consciously decided by the IBIS Open
Forum, in order to preserve the states of existing IBIS models. Michael
Mirmak raised the issue that a parser specification, which would be publicly
accessible, would help to inform the community as to the interpretations and
assumptions of the various parser versions.
On package modeling and connectivity, Bob Ross pointed out that a new [Pad]
or [Pad Mapping] keyword may not be needed, as the [Node Declarations]
keyword allows splitting of package or routing paths to multiple pads.
Weston Beal noted that, outside of the IBIS 4.1 syntax, a [Pad] keyword
might make tracking of the pin or pad of interest difficult to do
automatically at the tool level (IBIS 4.1 has subparameters to address this
with the *-AMS languages). At present, Bob observed that pads are
implicitly named through the [Pin] keyword for traditional IBIS models.
Weston also noted that separating pads and pins may make buffer behavior
evaluation difficult, especially with subparameters such as SI_location
and Timing_location.
Regarding IBIS 4.1, John Angulo raised the question of traditional or native
IBIS (I-V and V-T curve data) with the new [External Circuit] keyword. At
present, IBIS 4.1 permits detailed on-die connectivity or package models
using [External Circuit], but the language of IBIS 4.1 does not allow these
to be used with traditional IBIS, but only with *-AMS or Berkeley SPICE
buffer models. Michael Mirmak deferred this discussion to the Futures
Subcommittee. Jon Powell raised the question of co-simulation, where two
different model types or languages had to be synchronized in the same tool.
Ian Dodd commented that most tools had several engines to deal with
different languages, but that a major problem still existed in synchronizing
events and simulation steps between the digital and analog domains for mixed
signal simulations.
Kim Helliwell inquired about the IBIS Quality committee. He noted that a
Level 0 model is tested by the golden parser, but that, to his knowledge,
receiver thresholds, Vmeas and driver loads and overshoots are not checked
in any way and might be good requirements to add to a future IBIS
specification or parser. Lynne Green confirmed that missing input
thresholds would generate a warning, but agreed that the specification
language could be clarified on whether the parameters Kim mentioned were
absolutely required.
INTERPRETING THE [DRIVER SCHEDULE] KEYWORD (AD HOC TOPIC)
Arpad Muranyi, Intel Corp.
Arpad Muranyi reviewed a short presentation on interpreting the
[Driver Schedule] keyword. Arpad noted that some controversy still existed
regarding special cases of [Driver Schedule] and that some tool vendors may
be adopting incorrect interpretations. He summarized the parts of
[Driver Schedule] and commented that he assumed the "NA" characters to be
different in meaning than "0." His recent BIRD, 84.1, clarifies how the
polarity subparameter is to be used and also defines the term "event" in the
specification. He noted, though, that initial conditions are still
undefined and that two interpretations of initial conditions exist: one
based on the input stimulus (Arpad's approach) and another based on
"reverse engineering" from a known state. Arpad also addressed
over-clocking of buffers and noted that the BIRD84.1 interpretation does not
assume that scheduled buffers have any type of "memory" when delays are
calculated. Arpad's presentation is uploaded to the eda.org website as
muranyi3.pdf.
[DRIVER SCHEDULE] MODEL INITIALIZATION (AD HOC TOPIC)
Bob Ross, Teraspeed Consulting Group
Bob responded to Arpad Muranyi's presentation with his own presentation
from 2001, which outlined the original intent of [Driver Schedule]. A
"full cycle" method was assumed for interpreting the scheduled driver
turn-on and turn-off times, with a table of known initialization states
provided. The table is not present in the current IBIS specification, but
can be re-derived if needed. Over-clocking is not comprehended nor is it
supported. Bob suggested that tools not implementing [Driver Schedule]
using the "full cycle" interpretation and initialization states may cause
significant errors in fairly simple simulation situations. Bob's
presentation is uploaded to the eda.org website as both ross2.zip and
ross2.pdf.
The "Driver Schedule Modeling" presentation by Chris Reid and Bob Ross
given June 2001 is archived under:
http://www.eda.org/pub/ibis/summits/jun01/
Both Bob and Arpad accepted an AR to write a BIRD to finally clarify how
[Driver Schedule] is to be interpreted. They also accepted an AR to develop
a simple test suite of models which could be used by tool vendors to
validate their interpretations of the keyword.
CONCLUDING ITEMS
Michael Mirmak again thanked the presenters and IEC sponsors for their
help and support in making the Summit a success. After reminding the
participants regarding the next Open Forum teleconference, Michael closed
the IBIS Summit Meeting.
NEXT MEETING
The next Open Forum teleconference has been scheduled for February 20,
2004 from 8:00 AM to 10:00 AM US Pacific Standard Time. A vote
regarding the approval of BIRD87 is scheduled.
The next IBIS Summit will take place at DATE 2004 on February 20,
2004 in Paris, France.
========================================================================
NOTES
IBIS CHAIR: Michael Mirmak (916) 356-4261, Fax: (916) 377-1046
michael.mirmak@intel.com
Senior Analog Engineer, Intel Corporation
M/S FM6-45
1900 Prairie City Rd.
Folsom, CA 95630
VICE CHAIR: Lynne Green (425) 788-0412, Fax (425) 788-4289
lgreen22@mindspring.com
Green Streak Programs
20130 181st PL NE
Woodinville, WA 89077
SECRETARY: Randy Wolff (208) 363-1764, Fax: (208) 368-3475
rrwolff@micron.com
Simulation Engineer, Micron Technology, Inc.
8000 S. Federal Way
Mail Stop: 1-711
Boise, ID 83707-0006
LIBRARIAN: Roy Leventhal (847) 590-9398
roy.leventhal@ieee.org
Consultant, Leventhal Design and Communications
1924 North Burke Drive
Arlington Heights, Illinois 60004
WEBMASTER: Syed Huq (408) 525-3399, Fax: (408) 526-5504
shuq@cisco.com
Manager, Hardware Engineering, Cisco Systems
170 West Tasman Drive
San Jose, CA 95134-1706
POSTMASTER: John Angulo (425) 497-5077, Fax: (425) 881-1008
John_angulo@mentor.com
Development Engineer, Mentor Graphics
14715 N.E. 95th Street, Suite 200
Redmond, WA 98052
This meeting was conducted in accordance with the EIA Legal Guides and
EIA Manual of Organization and Procedure.
The following e-mail addresses are used:
majordomo@eda.org
In the body, for the IBIS Open Forum Reflector:
subscribe ibis <your e-mail address>
In the body, for the IBIS Users' Group Reflector:
subscribe ibis-users <your e-mail address>
Help and other commands:
help
ibis-request@eda.org
To join, change, or drop from either the IBIS Open Forum Reflector
(ibis@eda.org), the IBIS Users' Group Reflector
(ibis-users@eda.org) or both. State your request.
ibis-info@eda.org
To obtain general information about IBIS, to ask specific
questions for individual response, and to inquire about joining
the EIA-IBIS Open Forum as a full Member.
ibis@eda.org
To send a message to the general IBIS Open Forum Reflector. This
is used mostly for IBIS Standardization business and future IBIS
technical enhancements. Job posting information is not permitted.
ibis-users@eda.org
To send a message to the IBIS Users' Group Reflector. This is
used mostly for IBIS clarification, current modeling issues, and
general user concerns. Job posting information is not permitted.
ibis-bug@eda.org
To report ibischk3 parser bugs. The Bug Report Form Resides on
eda.org in /pub/ibis/bugs/ibis_bugs/bugform.txt along with
reported bugs.
icm-bug@eda.org
To report icmchk1 parser bugs. The Bug Report Form Resides on
eda.org in /pub/ibis/bugs/icm_bugs/icm_bugform.txt along with
reported bugs.
To report s2ibis, s2ibis2 and s2iplt bugs, use the Bug Report
Forms which reside under eda.org in
/pub/ibis/bugs/s2ibis/bugs2i.txt,
/pub/ibis/bugs/s2ibis2/bugs2i2.txt and
/pub/ibis/bugs/s2iplt/bugsplt.txt respectively.
Information on IBIS technical contents, IBIS participants and actual
IBIS models are available on the IBIS Home page:
http://www.eigroup.org/ibis/ibis.htm
Check the IBIS file directory on eda.org for more information on
previous discussions and results:
http://www.eda.org/pub/ibis/directory.html
* Other trademarks, brands and names are the property of
their respective owners.
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.org
|with just the appropriate command message(s) in the body:
|
| help
| subscribe ibis <optional e-mail address, if different>
| subscribe ibis-users <optional e-mail address, if different>
| unsubscribe ibis <optional e-mail address, if different>
| unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a written request to ibis-request@eda.org.
|
|IBIS reflector archives exist under:
|
| http://www.eda.org/pub/ibis/email_archive/ Recent
| http://www.eda.org/pub/ibis/users_archive/ Recent
| http://www.eda.org/pub/ibis/email/ E-mail since 1993