From Itzik_Baruch@mail.stil.scitex.com Thu Feb 1 04:01:25 1996 Return-Path: Received: from stil.scitex.com (nsird.scitex.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04903; Thu, 1 Feb 96 04:01:25 PST Received: from cc:mail_smtp.stil.scitex.com by stil.scitex.com (AIX 3.2/UCB 5.64/4.03) id AA54995; Thu, 1 Feb 1996 12:42:38 +0200 Received: from ccMail by mail.stil.scitex.com (SMTPLINK V2.11 PreRelease 4) id AA823211555; Thu, 01 Feb 96 13:51:04 EST Date: Thu, 01 Feb 96 13:51:04 EST From: "Itzik Baruch" Message-Id: <9601018232.AA823211555@mail.stil.scitex.com> To: ibis@vhdl.org Return-Receipt-To: Itzik_Baruch@mail.stil.scitex.com Subject: new member Dear IBISnians 2/1/96 I would like to participate in the IBIS discussion group. Thanks YITZHAK BARUCH E-MAIL : itzik_baruch@mail.stil.scitex.com SCITEX CORP. Ltd. P.O.Box 330 Herzlia B, 46103 ISRAEL Phone: 972-9-597-210 Fax: 972-9-502922 From owner-ibis Mon Feb 5 11:33:11 1996 Received: from icx.com (icx.rain.com [204.119.8.12]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id LAA14692 for ; Mon, 5 Feb 1996 11:32:42 -0800 (PST) Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 5 Feb 96 11:24 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 5 Feb 96 11:27 PST Message-Id: Date: Mon, 5 Feb 96 11:27 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS SUMMIT MINUTES 1/29/96 DATE: February 5, 1996 SUBJECT: 1/29/96 EIA IBIS Summit Minutes VOTING MEMBERS AND 1996 PARTICIPANTS LIST: Cadence Design C. Kumar* Contec CAE, Ltd. Dileep Divekar*, Norio Matsui* Hewlett Packard, EEsof Karl Kachigan*, Henry Wu* HyperLynx Kellee Crisafulli* IBM (Jay Diepenbrock) INCASES (Werner Rissiek), Olaf Rethmeier Intel Corporation Stephen Peters*, Will Hobbs*, Arpad Muranyi*, John Keifer*, Aaron Tang*, Duane Quiet*, Donald Telian*, Tim Kruchowski* Interconnectix, Inc. Bob Ross* Meta-Software (Les Spruiell) Motorola (Ron Werner) National Semiconductor Syed Huq*, Donald Snyder*, Chune-Sin Yeh* NCR (formerly ATT-GIS) Dave Moxley*, Richard Mellitz* NEC (Hiroshi Matsumoto), Quad Design Jon Powell*, Chris Rokusek* Quantic Labs (Mike Ventham) Tanner Research, Inc. (Scott Wedge) Texas Instruments Roger Cline*, Ben Andresen, Sri Jandhyala*, Tareq Shahwan*, Dan Phipps* Thomson-CSF/SCTF (Jean LeBrun) UniCAD Canada Ltd. Celso Faia* VLSI Technology Dick Ulmer*, Sung Oh*, Swami Gangadharan*, Daniel Kim*, Tom Dockery* Zuken-Redac (John Berrie) OTHER PARTICIPANTS IN 1996: Altera Vadim von Brzeski* AMP Hank Herrmann Apteq Design System Dan FitzPatrick* Compaq Mark Leonard* Cypress Bruce Wenniger* Digital Equipment Corp. (Jeff Chu), (Steve Thierauf) EIA Patti Rusher IC Works Eric Chen* Intergraph/Veribest Ian Dodd* Micron Technology Brian Johnson* MicroSim Ralph Perez Mitsubishi Tam Cao* North Carolina State U. (Michael Steer) S3, Inc. Sarathy Sribhashyam*, Phap Duong* Seimans Nixdorf Arnaud Lacariere* Tektronix, Inc. Brock Hannibal* TRW & Free Model Foundation Robert Harrison* In the list above, attendees at the meeting are indicated by *. Principle members or other active members who have not attended are in parantheses. Upcoming Meetings: The bridge numbers for future IBIS teleconferences are as follows: Date Bridge Number Reservation # Passcode 2/16/96 (916) 356-9200 2-48992 5519538 All meetings are 8:00 AM to 9:55 AM Pacific Time. We try to have agendas out 7 days before each open forum and meeting minutes out within 7 days after. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the reservation number and passcode. NOTE: "AR" = Action Required. -------------------------------- MINUTES ------------------------------------- INTRODUCTIONS Will Hobbs opened the meeting and welcomed the participants. A total of 45 people representing 24 organizations attended. A big thank you to National Semiconductor and Syed Huq for providing the excellent local arrangements and hosting the meeting. MINUTES REPORT, MISC. Patti Rusher requested that the EIA legal disclaimer note, "This meeting was conducted in accordance with the EIA Legal Guides and EIA Manual of Organization and Procedures." be attached to all Minutes. The January 12, 1996 minutes have been ammended to include this note at the end. Hank Herrman submitted a clarification of the last sentence in the BIRD31 discussion. It has now been rewritten to read: "Hank Herrmann indicated that AMP Spice models do not have any assumed ground references. The model is designed so that any of the pins can be used as ground or power references. You simply connect the pins to the references, just as you would do with the actual connector." MISCELLANY/ANNOUNCEMENTS The reflector went down again, and Bob Ross will deal with this when he returns. You can check email96 for missed, archived e-mail. PRESS AND WEB PAGE UPDATES No report. (Several papers at Design SuperCon96 the following day mention IBIS) OPENS FOR NEW ISSUES Roster Update - Bob Ross ROSTER UPDATE Bob Ross will request roster update information. The current roster has not tracked all of the people/organization changes and will be saved. The new roster will contain only the 1996 supplied information. The distribution lists at the top of the minutes will reflect only 1996 participation. EIA /IBIS WEB PAGE Syed Huq requested suggestions for more material and improvements of the EIA Web page. It contains the diagrams for the EDN article and also links to other home pages. EIA/IBIS 1996 MEMBERSHIP Patti Rusher sent again membership invoices upon discovering that the first ones stated incorrect amounts. Members have 45 days upon receipt to pay. DAC STANDARDS BOOTH Will Hobbs led the discussion on IBIS participation in the Standards booth at the Design Automation Conference (DAC) in June, 1996. Jon Powell recommended that the booth have handouts and order forms and be informally staffed since most participants will be busy with company activities. Pointers to other booths may be considered. IBISCHK2 PARSER Jon Powell will be in charge of tracking ibischk parser bugs. A created a bug report form which will be available on vhdl.org/pub/ibis/bugs. He new mail address ibischk-bug@vhdl.org can be used to submit bugs. Paul Munsey and Ron Neville have completed the previously reported problems and are awaiting instructions for the next release. This should serve as the new baseline. Jon Powell should sent out the form. PRESENTATIONS: The remaining portion consists of brief notes on the presentations. Presenters are requested to submit electronic versions of their talks in any format to Bob Ross to be put on vhdl.org. BRIEF OVERVIEW WITH HISTORY OF IBIS - Will Hobbs Will Hobbs gave a brief overview and history of IBIS starting with Arpad Muranyi's behavioral modeling, Intel's original Excel Spreadsheet approach, and Don Telian's consolidation of formats with initial EDA industry involvement leading to Version 1.0 in 1993 in ASCII format. Advances continued leading to ANSI/EIA-656 (Version 2.1) plus the Overview, Cookbook, EDN Article, s2ibis utilities (from NCSU), ibischk utilities, reflector lists and repository of models from Intel and National Semiconductor and other information on vhdl.org, and formal affilation with EIA. Will listed some proposed Version 3.0 enhancements. (More on this at the end.) There is still need for updating the Cookbook and providing articles on Version 2.1 features. Stephen Peters is doing an internal update, but keeping it sanitized so it can be used externally. Steven Peters is also working with Don Contrell of CFI on the DCL (Delay Calculation Language Standard) Will Hobbs reported that IBIS has an unanticipated use of conveying buffer specification requirements internally and to customers in the early stages of design. IBIS can serve as an electronic databook. NATIONAL AND THE IBIS EXPERIENCE - Syed Huq National Semiconductor Corporation (NSC) joined just after the V1.1 ratification, and pushed differential I/O, multiple rails, etc. Some of NSC's models are generated from bench measurement. They modified s2ibis to ns2ibis converter. It changes their NsSPICE models to IBIS, and they've used it to convert a large library to IBIS. NSC has a library management system for archival and controlling revisions. They have an internal IBIS home page, and library. They've also generated training materials available on the internal Web and publicized IBIS throughout the corporation. Several NSC groups are generating models. The EDA industry was employed to evaluate their models and Syed received excellent support. All of the models National has produced are available on their Web site: www.national.com. All of data for these components are available in the same area, not just the models. Syed Huq spearheaded putting an IBIS web page on eia.org, with an FAQ section, the EDN article on IBIS, hypertext links to vhdl.org for versions of the specication, many models, minutes archives, etc., are there, and a "virtual poster" of member companies with potential links to members' home pages. EIA IBIS members can have their logo on the virtual poster (a good reason to join the committee). Syed would like a good How-to guide to support measurement, such as measuring package-less dV/dt, use BTL IEEE 1194.1 for C_comp measurement. He'd also would like a way of tracking model usage on the Internet. Syed proposes taking steps to sync up IBIS with other related standards, including JEDEC JC-15 (package parameters) and CFI/Pinnacles/OMF/DIE/DIET efforts. Kellee Crisafulli suggested adding a Web counter to the IBIS home pages of NSC and eia.org. This may not give full information on who is accessing what, but it would give a rough idea of the interest in the web sites. Jon Powell suggested we form some subcommittees to focus on some of the inter-specification relationships. Syed's wish list: Create a dummy model or two that can be simulated and has all of the IBS defined keywords and parameters with data tables. Also, a glossary/clarification of IBIS keywords and parameters as defined in the IBIS standard. Bob Ross reported that there does not exist a set of models for testing the IBIS Golden Parser. IBIS AT INTEL: BUFFER ARCHITECTURE TO CUSTOMER MODELS - Stephen Peters Stephen Peters gave an overview of the "Intel IBIS Experience" from the technical side. Groups within Intel define the essential characteristics of the interconnect between chipsets and CPUs, to bound the problem, balance the tradeoffs between what the buffer designer can create and what the system designer can tolerate. This results in "specification wars" until common ground is found. To handle the communication between the system architect and the buffer designer, IBIS is being used. This is tongue-in-cheek referred to as "GUMBIE," or Grand Unified Model Buffer Information Exchange. The ultimate result of the dialog between architects and designers is an IBIS model that can be validated against silicon and shipped to customers. Stephen gave a real example of a recent buffer definition project, where the designers began with a simple on resistance "Ron" (linear V/I) approach. The Ron model didn't allow a system to be designed. By switching to V/I, they were able to meet the design challenges. This is because Ron wasn't able to handle saturated outputs. Stephen enumerated the issues he perceives that affect customer models: How do you generate a "worst case" model? Are the models truly a specification of the device? How do we guarantee a model (and do we have to?): What do you guarantee? How do you test and characterize the model's parameters? Obtaining skewed silicon doesn't necessarily demonstrate worst case buffers, since the process slow skew may not be the skew that produces the slowest I/O buffer characteristics - it may be slow for some other characteristic of the IC. Jon Powell: Do you really want a worst case model? The system designer may be willing to trade off a lower yield against higher performance. Jon also raised the issue of how to tell the customers what parameters of a model are independent. Kellee Crisafulli suggested a corner table setup map. MODEL PROVIDER EXPERIENCES, THE TI EXPERIENCE - Sri Jandhyala Sri Jandhyala of Texas Instruments (TI) discussed the work going on at TI with IBIS. Many groups within TI have developed I/O buffer models because of strong customer demand. They are concerned by the large effort required to generate standard SPICE models, and are concerned about the IP protection. IBIS is attractive, too, because of the vendor independence, reduced cycle time. Customers are asking for IBIS models by name. Sri listed many companies that have explicitly asked for IBIS models, such as Apple, Bay Networks, HP, IBM, Intel, LG Semiconductor, Unisys and others. TI has allocated resources to steer their IBIS efforts and support IBIS. They are developing internal tools to automate model creation process. TI is committed to the support and development of IBIS. IBIS model generation is to be integrated into the product development flows. Current issues: standardizing the process, characterizing the models, validating the models, establishing common procedures and improving the coordination between work groups. Question: Whom does a customer contact to get model information? Answer: The TI Web page will have links into TI IBIS information. Sri's e-mail is srij@ti.com. Company policy is not to release IBIS models publicly on the Internet. This appears to be because management isn't yet comfortable with the models. TI has around 30 models available so far. Dave Moxley indicated he'd like more ready access to the models, as he might use the models as a method to decide whether he wants to buy the TI components. USING IBIS MODELS IN SYSTEM DESIGN - Dave Moxley Dave Moxley of NCR (formerly AT&T-GIS) reported that NCR develops their models through simulation and validates them via measurement. NCR is in the massively parallel and SMP server business. They stress reliability and quality. They routinely develop with sub-nanosecond timing margins, with bus speeds up to 100 MHz today, and higher in the future. Critical analysis goes into board design and ASIC design. Both noise margin and timing margins have shrunk dramatically over the years that NCR has been doing these designs. Signal Integrity questions: How many power and ground pins are required? What layout constraints apply, how many bypass capacitors and of what type? What layout topologies will be required? How fast can a design operate reliably? What buffer strengths are required to insure reliable operation? How will normal manufacturing variation affect performance? Regarding manufacturing, IBIS is used here to play what-if games, which is why he is interested in obtaining IBIS models over the spread of process variations. They use both 2D and 3D solvers. Dave showed the general flow they go through in doing the design from concept through what-if to layout and verification. They've seen good correlation between SPICE, IBIS and silicon in test silicon, test vehicles and components from ASICs to clock distribution devices, buffers, memory and processors. Question: How do chip specications relate to IBIS Models: setup, hold, clock to data, access time, clock skew, buffer delay? During their design analysis, they look at every circuit, examining for corner case variations, timing, crosstalk, threshold violations and other anomalies. They would like industry wide support for IBIS, with vendor contacts at each company and public library maintenance. They are considering making IBIS model availability a requirement in contracts with the vendors they are dealing with. Other issues included silicon corner verification, slow-n/slow-p may be fastest edges. Also included are drivers with feedback. Sometimes there are application specific work-arounds. They would like to be able to obtain IBIS models from customer supplied parameters of Voltage, temperature and load. And, they'd like to know the relation between the IBIS models and the board level related timing specifications. MODELING LOSSY TRANSMISSION LINES - C. Kumar C. Kumar of Cadence presented modeling issues related to modeling lossy transmission lines. The industry trends that concern him are increasing speeds, 200 MHz and beyond, which drives higher and higher slew rates; shrinking sizes; and High DC and Skin Resistance. At higher frequencies, the resistance of a conductor can increase by an order of magnitude. The classic transmission line model begins with a segmented RLC representation, with the number of segments going to infinity. A lossy transmission line adds frequency dependent losses. The incident and reflected waves encounter different resistances due to the differences in high frequency components of the two waves. Fundamental challenges are in how to approximate these effects. They use a "rational approximation." Stability is one potential pitfall. He gave an example of an ECL transmission line running at 400 MHz. He compared a lossy transmission line simulation with segment and lossless models, demonstrating that noise margin losses are shown by the lossy transmissions and not by the other two. The lost noise margin of 20 mV is significant in ECL designs. He also showed an example of a CMOS circuit running at 200 MHz showing that at 200 MHz the effects are not nearly as pronounced as at 400 MHz. Kumar showed that modeling bonding wires with inductors versus skin resistors produces a less-damped waveform than the skin effect resistor, which correlates better with actual components. He concluded that at higher speeds, frequency dependent effects become significant, particularly with respect to noise margins. Jon Powell noted that if and when we ever get to modeling large networks, such as MCM, lossy transmission lines will be a significant contributor to accuracy. EGG8: MODELING PACKAGES WITH PHYSICAL DESCRIPTIONS - Kellee Crisafulli At Syed Huq's request, Kellee Crisafulli also discussed the Visual IBIS Editor The Visual IBIS Editor is a Windows based standard text editor including special features for source code editing, with the syntax checker built in. At any point, you can check the syntax, like a spell checker. There is also a graphical viewer for VI tables, and rising and falling waveforms. Finally there is an IBIS file creation wizard, a skeleton file for either V1.1 or V2.1 that can be used as a foundation model to begin developing the model. It can be used on Windows 3.1, Windows 95 or Windows NT, but not UNIX. It is available at http://www.hyperlynx.com for download for free, but HyperLynx asks that models that are created on it are made publicly available. Kellee then discussed Egg 8: Physical Package format for IBIS. There is presently no standard way to create or deliver signal integrity models for integrated modules, such as SIMMs and MCMs. SIMMs from different vendors for the same target socket are laid out differently and therefore behave differently. Kellee proposes a SIMM module physical package file at the top, linked to individual IBIS files below. After looking at the state of the art, Kellee concluded there are no standard PCB formats that PCB tools read and write today without purchasing special translators. Existing standards, such as EDIF, are too complex. Instead, Kellee proposes a simple ASCII PCB description. He gave an example of a 4 layer package. Starting with the stackup (signal and power, etc., layers can be defined), pad stack, layer to IBIS model association, and an interconnectivity portion that defines specific nets with bias, pad stacks, segments, pins. The segments are defined by their endpoints. The ordering is "unimportant." One issue discussed was the problem of line segments that connect, but whose x,y endpoint coordinates don't always coincide due to trace length, trace overlap, via width, etc. Kellee contends that the IBIS committee needs to endorse a standard for physical descriptions. Kellee used curly braces instead of square brackets to make it simpler for parsing, but he is open to alternatives. Cutouts in the ground plane can be modeled. There is no support for cross- hatched planes, however. Several wondered if it would be possible to specify min and max for such things as dielectric constants and trace width. Don Telian expressed concern that unless there were netlisters to generate these files for a given format, the SIMM suppliers will not use it. Jon Powell and Kellee said that there are lots of people that create writers for new formats for as little as $10K. Jon would like to make sure there is something in the specication that ensures that non-simulated conditions will not meet the specification. E.g., a net that is two completely discrete segments would be illegal. Ian Dodd added zero length nets should be checked. Kellee hesitates to add these checks because all layout packages today put out certain amounts of garbage. There is general agreement that this is a problem, but not on where to put the burden of guaranteeing that such bad data doesn't torpedo the simulation. BIRDs 28.3, 32: MODELING PACKAGES WITH ELECTRICAL DESCRIPTION - Stephen Peters and C. Kumar Stephen Peters discussed BIRD 28.3, wherein an electrical approach is taken to describing packages. He showed drawbacks with the current IBIS methodology that are addressed by the BIRD. He also identified a problem in modeling BGA packages because of a plating stub that can't be represented in a standard section by section description. C. Kumar said that two values to an electrical description are: it can't be reverse-engineered as a physical description can, and the data can be very compactly represented. Kumar filed BIRD 32 as an extension to BIRD 28.3 to add arbitrary coupling and handle an arbitrary number of sections compactly. The coupling information is represented in a named matrix and multiple models can be referenced by any number of models. Question: Is a pure physical description sufficient so we don't need the electrical version, or do they each have a place? The consensus seems to be that each has value. There may be cases where one would be preferred over another. For example, there are cases in packages where the signal path may not be planar, causing the physical description to be inadequate. If they both are supported, Ian Dodd would like to see the same syntax be used for each type of representation. The discussion highlighted a number of issues the forum will have to resolve before incorporation into the specication. BIRD 31: CONNECTOR MODELING - Bob Ross Bob Ross of Interconnectix discussed BIRD 31, extending IBIS into connector utility. Bob has already decided BIRD 31 has to be replaced by a new one that Bob will write soon. Connectors are usually described by lumped sections, transmission lines, sections and edge rates, their symmetry, pad capacitance and the ground reference. It usually is supplied in SPICE subcircuit format and also for single line connectors, in a data sheet. Karl Kachigan of HP asked how to deal with connectors that have mated pairs when they're not mated, such as backplanes. This could be handled in a manner similar that decribed by BIRD30 which has been approved. Normally unmated models are not provided. Bob showed an actual right angle connector with multiple rows and columns and different path delays. He then showed what would be in a SPICE model format with coupled pins. The pins are grouped, the descriptions are in sections and edge rates, with symmetry (e.g., 3 inductor, 2 capacitor sections), making it not directly convertable to transmission line format needing an equal number of L's and C's. Other Details such as explicit or implicit ground references, pad capacitance, fins (connected metal planes dividng groups of pins), etc. need to be considered. Exact pin mapping to actual connector circuit pins are details critical to the EDA industry for correct path simulation. So the set of subcircuits must accurately present pin descriptions that can be used for any pin. Spice subcircuit connector models are derived from field solver extractions and converted into equivalent L and C transmission line sections. Exact pin mapping of the circuit board contact of all pins to the connection path is critical to the EDA industry for correct path simulation. Details on certain pins (or treatment of missing pins at ends and other places due to construction by modules) may be missing. Thus connectors are suitable for IBIS syntax because of the exact pin mapping and because IBIS would use the field solver matrices directly. The alternative is to reverse engineer models from Spice Models. Bob will revise BIRD31 to have one or two pin columns for numbering, cross-connection, and symmetry variations, will embed cable within connector model groupings, and offer pad capacitance options. Larger models would have to be auto-generated by expanding from a known set of comprehensive field solver extractions. STORED CHARGE MODELING, DIODE DELAY DISCUSSION - Jon Powell, Bob Ross Jon Powell of Quad Design opened the discussion on diode transit time. Charge storage results from excess minority carriers injected across the junction in forward bias. Transit time (TT) represents the minimum time required to store or remove charge from the junction. For moderate or more forward bias, the stored charge dominates. Jon recommends the reference "Semiconductor Device Modeling with SPICE," by Antongnetti and Massobrio. This book has a good model of this effect by relating a capacitance in parallel to a current sinking diode, with the parallel net in series with a resistor Rs. The TT effect can create heavy but delayed ringing, an effect missed without the diode TT being modeled. Jon proposes we add TT support to IBIS. Stephen asked if there was a measurement technique that could derive TT. Jon says that this is being done today, so there is a way. He also noted that the diode that has the intrinsic capacitor is the static protection diode, which swamps the effects of input and output capacitances of the buffer structure. Bob Ross continued the presentation. He showed that Ct can be derived from the standard diode equation to be a proportional to TT * Id * (q / KT). Id is the diode current, q is charge, K is Boltzmann's constant, and T is absolute temperature. The theoretical dependence on temperature is motivation to have typ, min and max specifications. Kellee Crisafulli asked whether we should specify TT or Ct? He feels that Ct can be measured by forward biasing the diode at a specified current and measuring the capacitance. Bob and Jon provide a BIRD to bring this issue to closure. EGG 6: DETECTING CMOS VERSUS TTL - Jon Powell Jon Powell has concluded that just knowing the technology is not necessary or sufficient. Rather, the standard 50 ohm measurements do not adequately demonstrate TTL characteristics. He recommends instead 500 ohms to ground and 7 ohms to power. He bases this on where the load lines intersect the pullup and pulldown tables to best isolate the pullup from the pullup characteristics for the rising and falling transitions. This doesn't violate the IBIS specication, but implies a needed change to the cookbook. Even more loads allow greater accuracy, but these two are sufficient to produce a good model. For CMOS, the 50 ohms to power and 50 ohms to ground is still sufficient. Jon will help contribute to the cookbook. DOUBLE COUNTING AND OTHER MODEL GENERATION ISSUES - Arpad Muranyi Arpad Muranyi of Intel discussed double counting that can happen easily with internal pull-up resistors. The pull-up shows up in both the power and the ground clamp portions of the model in extractions. This results in double counting the effect. Arpad proposed an algorithm which eliminates this effect. The double counting effect is minor but might affect the DC float voltage of a net. Arpad will write this up and submit it to Kellee Crisafulli for inclusion in the cookbook. Another issue Arpad addressed was the way pull-up and pull-down IV curves are defined, which is the difference between floating and on values. These curves add correctly only if the same reference values are used at the time of measurement. He used a 5-volt safe 3.3 V input device to illustrate the problem, as there may be two different reference voltages at different times. A third issue is the derivation of the value of the R_load sub-parameter. For backward compatibility, the ramp keyword is still required in V2.1. The ramp could be derived from IBIS 2.1 without this keyword. R_load is required if not equal to 50 ohms. Deriving the ramp number is problematic if all R_fixtures are not the same. Both of these cases are worth noting in the cookbook. Kellee says they've already run into this problem with some V2.1 models, and since it is superseded by the ramp tables, they ignore it. One possible solution for V3.0 is to add an R_fixture to the ramp. RAIL, RULES AUGMENTED INTERCONNECT LAYOUT SPECIFICATION - Donald Telian Don Telian of Intel introduced the RAIL specification aimed at automating the PCB layout and simulation process. It is an industry-wide initiative. Circuit simulation has become critical as speeds increase, with flight times being a significant percentage of the clock period, and crosstalk increasingly problematic due to ever finer pitches. RAIL addresses the gap between good simulation and manufacturable boards. The three elements of system design are physical, logical and electrical. RAIL complements IBIS to complete the electrical piece of the pie. Rail is a "container" for electrical constraints. RAIL has been developed to an initial specification level by Intel and five simulation vendors. Most tool vendors already have elements that can accept RAIL data, which is an electronic (ASCII) version of layout guidelines, providing clear communication of electrical constraints, such as maximum trace length, acceptable flight time skew, etc. Don described the RAIL syntax, which looks like IBIS syntax. Don obtained permission from EIA to make the two look this similar. Typical keywords include [Stackup], [Group Nets], [Topology], [Budgets] (flight times, max overshoot, crosstalk limits), [Clock Skew]. He provided a typical example. RAIL can be used as a post-processing tool, where the route is done, then checked out and the PCB is modified and the post-processing is done again, re-iterating until everything comes out clean. It can also be used interactively, where nets are hand routed while the simulator is running in the background to tell the user if there is a problem with the net in real time. The third approach takes a netlist, IBIS and RAIL and feeds an autorouter with integrated simulation, resulting in a nearly effort-free and fast layout. VHDL has volunteered to make resources available for RAIL on vhdl.org, including rail@vhdl.org, rail-info@vhdl.org and rail-request@vhdl.org reflectors. There are slides, minutes, the V1.0 version of the specification, etc. are available on vhdl.org under /pub/rail. [Note, the rail reflectors have been experiencing similar difficulties as the ibis reflectors.] The five EDA vendors that put the specication together with Intel are Cadence, Mentor, Quad Design, HyperLynx and Interconnectix. Don would like the simulators to extract RAIL files from successful designs for later use. He pointed out the value of the RAIL data for sustaining engineers, who can go back to the original design database and see if it met constraints, without having to track down the original engineer on the project. The RAIL committee will meet on a monthly basis, and hopes to have demonstrations at DAC. RAIL files will be released from PCD at Intel, along with the IBIS models. A RAIL golden parser will probably be needed for RAIL. USEFUL NON-SIMULATON DATA INCLUSION - Jon Powell Jon Powell asks: Is there a place in IBIS for information that doesn't affect simulation? Threshold is already included, so Jon explored additional ones. Timing related information could include additional thresholds, other timing information, such as pin-to-pin information. Several others are already addressing this, including DIET, DCL. Another idea is to correlate between IC timings and the IBIS models. E.g., an annotation could be made in the IBIS file that a particular specification, such as Tco, was made with a particular corner of the IBIS model. Perhaps we should expand the threshold to include a rising and a falling threshold, which could handle hysteresis. The 54/74LS132 defines a Schmitt trigger with a vlow and vhigh for the rising edge, and a vlow and vhigh for the falling edge. Component reliability could be addressed by adding information on low and high voltage requirements - overshoot limits and time in threshold limit. Other factors include: monotonic requirements, pulse size requirements, illegality of leaving the input floating. John will submit a BIRD. BUS HOLD CIRCUITS AND EIA JEDEC JC40 - Bruce Wenniger Bruce Wenniger of Cypress Semiconductor is involved with the JEDEC JC40 committee which is working to make sure components from different manufacturers are interchangeable. He discussed bus hold, in response to the discussions on the reflector. Bus hold is the ability of an input or output pin to retain the last valid logic state after the source driving it enters the high impedance state. Such circuits reduce noise in a system, and improve hold times. The bus hold circuit is particularly important with CMOS devices which can float to their linear region and draw excessive current and possibly self-destruct. Bus hold circuits also eliminate the need for pull-up and pull-down devices, reducing power consumption. This is a real benefit for lap top computers. The circuit is simply a weak output connected to the pin with positive feedback. There is no JEDEC standard for 5V logic. The de facto standard was established by the TI ABT Series. The LVTTL standard is currently being debated by the JC40 committee, which consists of a number of IC vendors. OPEN DISCUSSION: IBIS 3.0 POSSIBILITIES, WISH LISTS - Will Hobbs Will Hobbs of Intel led the closing discussion on what people want in Version 3.0 of IBIS and other areas. The results of the discussion are summarized: Will listed the top technical enhancements for Version 3.0 that the group proposed: Packages and connectors: Physical description Electrical description MCM support Diode modeling (transit time, charge storage) Multiple drive level buffer-dynamically switched or staggered turn-on Feedback support (e.g., dynamic pre-driver effects such as gate modulation) Multiple drive level-selectable (done) Balanced drive outputs (already can be handled) Scaling of parameters (possibility) Other ideas: Refine SSO (simutaneous switching outputs) Power modeling Support for static timing New challanges for higher speeds The informational and technical clarification and model availablity wishes were: Model validation guidelines New Modeling Cookbook More models Clarification of worst case/best case? Presentations, overviews, intros to IBIS Press Release after summit Other ideas: Enhance s2ibis, golden parser Create awareness of library Move IBIS into new uses & arenas In addition to Intel and National, the attendees indicated that the following companies also have developed IBIS models: S3, Micron, Cypress, TI, and VLSI. The attendees felt that the most important issue to address was model validation. That is an obstacle to many companies releasing models widely. Kellee Crisafulli reiterated his offer to provide a HyperLynx simulator to companies willing to develop and make public IBIS models. CELEBRATION DINNER: Thirteen people celebrated the Adoption of ANSI/EIA-656 at dinner. NEXT MEETING: The next telephone meeting is set for Friday, February 16, 1996. ============================================================================== NOTES IBIS CHAIR: Will Hobbs (503) 264-4369, Fax (503) 264-4210 will_hobbs@ccm.jf.intel.com Server Chipset System Validation Manager, Intel Corp. 2111 NE 28th M/S JF1-57, Hillsboro, OR 97124 USA VICE CHAIR: Jon Powell (805) 988-8250, Fax: (805) 988-8259 jonp@qdt.com Transmission-Line Products Manager, Quad Design 1385 Del Norte Rd., Camarillo, CA 93010 SECRETARY: Bob Ross (503) 603-2523, fax (503) 639-3469 bob@icx.com Modeling Engineer, Interconnectix, Inc. 10220 SW Nimbus Ave, K4, Portland, OR 97223 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: ibis-request@vhdl.org To join, change, or drop from either the IBIS Open Forum Reflector (ibis@vhdl.org), the IBIS Users' Group Reflector (ibis-users@vhdl.org) or both. State your request. ibis-info@vhdl.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@vhdl.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. ibis-users@vhdl.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. ibischk-bug@vhdl.org To report ibischk2 parser bugs. The Bug Report Form Resides on vhdl.org in /pub/ibis/bugs/bugform.txt along with reported bugs. Information on IBIS technical contents, IBIS participants, and actual IBIS models are available on the IBIS Home page: http://www.eia.org/eig/ibis/ibis.htm Check the pub/ibis directory on vhdl.org for more information on previous discussions and results. You can get on via ftp anonymous, "guest" login from telnet or dial-in (415-335-0110), or send an e-mail request to the automatic archive server, archive@vhdl.org. "IBIS Spoken Here" placards are available from Jon Powell (jonp@qdt.com) for use at trade shows. ============================================================================== From owner-ibis Mon Feb 5 20:02:23 1996 Received: from mars.reprise.com (mars.reprise.com [204.157.65.34]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id UAA18550 for ; Mon, 5 Feb 1996 20:02:21 -0800 (PST) Received: from pluto (pluto.reprise.com [204.157.65.44]) by mars.reprise.com (8.6.10/8.6.10) with SMTP id TAA28288 for ; Mon, 5 Feb 1996 19:54:00 -0800 Date: Mon, 5 Feb 1996 19:54:00 -0800 Message-Id: <199602060354.TAA28288@mars.reprise.com> X-Sender: billd@mail.reprise.com X-Mailer: Windows Eudora Version 1.4.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis@vhdl.org From: billd@reprise.com (Bill DenBeste) Subject: unsubscribe From owner-ibis Tue Feb 6 08:14:19 1996 Received: from archimedes.inoc.sj.nec.com (archimedes.inoc.sj.nec.com [131.241.31.4]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id IAA29847 for ; Tue, 6 Feb 1996 08:14:19 -0800 (PST) Received: by inoc.sj.nec.com (8.6.12/YDL1.7-930126.17) id IAA03530(archimedes.inoc.sj.nec.com ); Tue, 6 Feb 1996 08:06:04 -0800 Received: by sj.nec.com (8.6.12/YDL1.7-940623.1) id IAA21389(netkeeper.sj.nec.com ); Tue, 6 Feb 1996 08:04:25 -0800 Received: by asic.mtv.nec.com (4.1/) id AA12108(elmailer.asic.mtv.nec.com); Tue, 6 Feb 96 08:11:57 PST Received: from stuart.caddev by mtv208.asic.mtv.nec.com (4.1/SMI-4.1) id AA21057; Tue, 6 Feb 96 08:03:21 PST Date: Tue, 6 Feb 96 08:03:21 PST Message-Id: <9602061603.AA21057@mtv208.asic.mtv.nec.com> Received: by stuart.caddev (4.1/SMI-4.1) id AA16164; Tue, 6 Feb 96 08:03:20 PST To: ibis@vhdl.org Subject: Unsubscribe From: stuart@asic.mtv.nec.com (Stuart Hamilton -- x6194) X-Mailer: mnews [version 1.17] 1994-01/27(Thu) From owner-ibis Tue Feb 6 17:23:12 1996 Received: from mis01.micron.net (mis01.micron.net [198.60.253.51]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id RAA04206 for ; Tue, 6 Feb 1996 17:23:10 -0800 (PST) Received: from brianjohnson.micron.com by mis01.micron.net with smtp (Smail3.1.29.1 #5) id m0tjyTB-000QlFC; Tue, 6 Feb 96 18:14 MST Message-Id: Date: Tue, 6 Feb 96 18:14 MST X-Sender: brianjoh@micron.net X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis@vhdl.org From: Brian Johnson Subject: Presentation of IBIS data Ibisians, I am trying to determine the best way to present IBIS data in our qualification documents so that it is not just a boring ASCII file. I was looking at the old IBIS information sheet that was presented in the Overview document and was wondering if it is worthwhile to present the Voh vs. Ioh data with Voh relative to ground instead of relative to Vcc. I noticed that that was the way it was presented in the Overview document. Any comments on using this method of presenting the data? Thanks, Brian Johnson Micron Technology From owner-ibis Tue Feb 6 18:16:24 1996 Received: from icx.com (icx.rain.com [204.119.8.12]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id SAA04613 for ; Tue, 6 Feb 1996 18:16:21 -0800 (PST) Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 6 Feb 96 18:07 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 6 Feb 96 18:10 PST Message-Id: Date: Tue, 6 Feb 96 18:10 PST From: bob@icx.com ( Bob Ross) To: brianjoh@micron.net, ibis@vhdl.org Subject: Re: Presentation of IBIS data Brian While the data could be graphed exactly as presented in the IBIS file for one-to-one correspondence, I would favor a more familar format that you suggest which appears in most data books. Present the Voh vs. Ioh data with respect to ground and with the voltage polarities that you would measure externally. In that way 3.3V and 5V technology differences are visually distinguishable. This approach would also apply to IBIS formats of ECL technologies. Bob Ross, Interconnectix, Inc. > To: ibis@vhdl.org > From: Brian Johnson > Subject: Presentation of IBIS data > Status: R > Ibisians, > I am trying to determine the best way to present IBIS data > in our qualification documents so that it is not just a > boring ASCII file. I was looking at the old IBIS information > sheet that was presented in the Overview document and was > wondering if it is worthwhile to present the Voh vs. Ioh data > with Voh relative to ground instead of relative to Vcc. I noticed > that that was the way it was presented in the Overview document. Any > comments on using this method of presenting the data? > Thanks, > Brian Johnson > Micron Technology From owner-ibis Tue Feb 6 18:53:04 1996 Received: from icx.com (icx.rain.com [204.119.8.12]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id SAA04806 for ; Tue, 6 Feb 1996 18:53:02 -0800 (PST) Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 6 Feb 96 18:44 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 6 Feb 96 18:47 PST Message-Id: Date: Tue, 6 Feb 96 18:47 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: ROSTER UPDATE REQUEST To IBIS Participants: I am updating the roster of participating companies. Please review your entry on vhdl.org under /pub/ibis/roster. You can also display the roster by accessing the EIA/IBIS web site: http://www.eia.org/eig/ibis/ibis.htm Contact me if you need more information or a copy of the existing roster. Since there have been several people/company changes that we have not tracked, I will be deleting all of the companies that do not respond or are not official EIA/IBIS members. Thus the roster will reflect 1996 level participation. The old roster will be saved for reference. The format is the same: Contact: Email: Phone: Address:
Support: Tag-line: Refer to the roster for examples. Anyone on the ibis@vhdl.org list is free to submit roster information. We look forward to a number of new entries to the roster. Please respond to bob@icx.com with your information or update. Thanks, Bob Ross, Interconnectix, Inc. From owner-ibis Thu Feb 8 03:50:32 1996 Received: from ds9.dortmund.venture.net (bin@ds9.Dortmund.venture.net [194.39.202.133]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id DAA25898 for ; Thu, 8 Feb 1996 03:50:28 -0800 (PST) From: fuhong@pad.incases.com Received: (from bin@localhost) by ds9.dortmund.venture.net (8.6.12/8.6.12) id MAA12548 for ; Thu, 8 Feb 1996 12:42:01 +0100 Received: from isdn.pad.incases.com(194.64.13.226) by ds9.dortmund.venture.net via smap (V1.3) id sma012546; Thu Feb 8 12:41:34 1996 Received: from alnair.incases.com by mail.pad.incases.com with smtp (Smail3.1.28.1 #3) id m0tkUlS-00044iC; Thu, 8 Feb 96 12:43 MET Received: by alnair.incases.com (4.1) id AA15992; Thu, 8 Feb 96 12:43:12 +0100 Message-Id: <9602081143.AA15992@alnair.incases.com> Subject: Unsubscribe To: ibis@vhdl.org Date: Thu, 8 Feb 1996 12:43:11 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Unsubscribe From owner-ibis Thu Feb 8 07:50:31 1996 Received: from milpitas.adaptec.com (milpitas.adaptec.com [162.62.21.1]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id HAA03357 for ; Thu, 8 Feb 1996 07:50:30 -0800 (PST) Received: from eng.adaptec.com ([162.62.20.6]) by milpitas.adaptec.com (4.1/SMI-4.1) id AA04189; Thu, 8 Feb 96 07:39:52 PST Received: from climax by eng.adaptec.com (4.1/SMI-4.1) id AA23672; Thu, 8 Feb 96 07:41:24 PST Date: Thu, 8 Feb 96 07:41:24 PST From: thomaswu@eng.adaptec.com (I-Ping Wu x2432) Message-Id: <9602081541.AA23672@eng.adaptec.com> To: ibis@vhdl.org Subject: Unsubscribe Unsubscribe From owner-ibis Thu Feb 8 07:52:28 1996 Received: from c11142-343dan.ece.ncsu.edu (c11142-343dan.ece.ncsu.edu [152.1.59.231]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id HAA03368 for ; Thu, 8 Feb 1996 07:52:27 -0800 (PST) From: mbs@eos.ncsu.edu Received: by c11142-343dan.ece.ncsu.edu (8.6.9/EC06jan95) id KAA09066; Thu, 8 Feb 1996 10:44:07 -0500 Message-Id: <199602081544.KAA09066@c11142-343dan.ece.ncsu.edu> To: ibis@vhdl.org Subject: Library Updates Date: Thu, 08 Feb 96 10:44:07 EST Below are updates to the IBIS model and software library. Michael Steer IBIS Librarian S2IPLT has been updated. The current version is v1.2. It can be found as vhdl.org:/pub/ibiss2ibis/s2iplt.v12 It is a PERL script which plots the contents of a *.ibs file. New models from National: Part/File vhdl.org rev. rev. IBIS name Directory date level ver. Notes ----------------------------------------------------------------------------- ds89c387.ibs interface Jan 96 1 2.1 12 Channel Differential Driver ds34c87n.ibs interface Jan 96 1 2.1 QUAD CMOS Tri-state Line Driver ds34c87m.ibs interface Jan 96 1 2.1 QUAD CMOS Tri-state Line Driver Updated models from Intel: Intel has updated the packaging models for the Pentium Pro. The files that have changed are readme.txt and ppromin.txt Pentium Pro processor package stub modeling information (short package stubs, see text below) ppromax.txt Pentium Pro processor package stub modeling information (long package stubs, see text below) _______________________________________________________________________________ The IBIS model library is as follows: Intel Corporation IBIS Files on vhdl.org as of Feb 8, 1996 Part/File vhdl.org alpha rev. rev. IBIS name Directory name date level ver. Notes -------------------------------------------------------------------------------- 82371fb.ibs chipset PIIX 08-09-95 R1.21 V1.1 Triton (NDA only)** 82371mb.ibs chipset MPIIX 08-09-95 R1.01 V1.1 Mobile Triton (NDA only)** 82374eb.ibs chipset ESC 08-09-95 R2.13 V1.1 PCI-EISA Bridge** 82374sb.ibs chipset ESC 08-09-95 R1.03 V1.1 PCI-EISA Bridge** 82375eb.ibs chipset PCEB 08-09-95 R2.13 V1.1 PCI-EISA Bridge** 82375sb.ibs chipset PCEB 08-09-95 R1.01 V1.1 PCI-EISA Bridge** 82378ib.ibs chipset SIO 08-09-95 R2.13 V1.1 PCI-EISA Bridge** 82378zb.ibs chipset SIO 08-09-95 R0.96 V1.1 PCI-EISA Bridge** 82379ab.ibs chipset SIO.A 08-09-95 R0.96 V1.1 PCI-EISA Bridge** 82423tx.ibs chipset DPU 08-09-95 R2.13 V1.1 Saturn** 82424zx.ibs chipset CDC 08-09-95 R2.13 V1.1 Saturn** 82425ex.ibs chipset PSC 08-09-95 R0.94 V1.1 Aries** 82426ex.ibs chipset IB 08-09-95 R0.94 V1.1 Aries** 82433lx.ibs chipset LBX 08-09-95 R2.13 V1.1 Mercury** 82433nx.ibs chipset LBX 08-09-95 R2.01 V1.1 Neptune** 82434lx.ibs chipset PCMC 08-09-95 R2.13 V1.1 Mercury** 82434nx.ibs chipset PCMC 08-09-95 R2.01 V1.1 Neptune** 82437fx.ibs chipset TSC 08-09-95 R1.21 V1.1 Triton (NDA only)** 82437mx.ibs chipset MTSC 08-09-95 R1.01 V1.1 Mobile Triton (NDA only)** 82437vx.ibs chipset TVX 08-09-95 R1.00 V1.1 Triton VX (NDA only)** 82438fx.ibs chipset TDP 08-09-95 R1.21 V1.1 Triton (NDA only)** 82438mx.ibs chipset MTDP 08-09-95 R1.01 V1.1 Mobile Triton (NDA only)** 82438vx.ibs chipset TDX 08-09-95 R1.00 V1.1 Triton (NDA only)** dx4pga.ibs cpu DX4 05-04-94 R2.0 V1.1 IntelDX4(TM) uP pp66sem.ibs pentium PP66 10-16-94 R3.0 V1.1 66MHz Pentium* pp100sem.ibs pentium PP100 10-15-94 R3.0 V1.1 100MHz Pentium* pentpro.ibs pentpro 12-5-95 R2.1 V2.1 Pentium Pro Processor ppromax.txt pentpro 11-30-95 R0.1 package data for pentpro.ibs formerly ppromax.pkg ppromin.txt pentpro 11-30-95 R0.1 package data for pentpro.ibs formerly ppromin.pkg 82437fx.ibs TSC 08-09-95 R1.21 V1.1 Triton with NDA only** 82437mx.ibs MTSC 08-09-95 R1.01 V1.1 Mobile Triton with NDA only** 82437vx.ibs TVX 12-13-95 R1.50 V1.1 Triton VX with NDA only** 82438fx.ibs TDP 08-09-95 R1.21 V1.1 Triton with NDA only** 82438mx.ibs MTDP 08-09-95 R1.01 V1.1 Mobile Triton with NDA only** 82438vx.ibs TDX 12-13-95 R1.50 V1.1 Triton VX with NDA only** 82439hx.ibs TXC 12-13-95 R1.01 V1.1 Triton HX with NDA only** * Translated from an Intel Simplified Electrical Model. ** submitted by Name of Person Submitting: Arpad Muranyi Address: 1900 Prairie City Road Folsom, CA 95630 Affiliation: Intel Corporation E-Mail: arpad_muranyi@ccm.fm.intel.com Telephone Number: (916) 356-2558 Fax Number: (916) 356-3162 (NDA only) Non disclosure agreement required to obtain model. Contact submitter. National Semiconductor Corporation - Advanced Systems & Interface Product Group IBIS Files on vhdl.org as of Feb 8, 1996 Part/File vhdl.org rev. rev. IBIS name Directory date level ver. Notes -------------------------------------------------------------------------------- 90c031tm.ibs interface 9/20/95 2.0 2.1 LVDS Quad Diff Line Drvr 90c032tm.ibs interface 9/20/95 1.1 2.1 LVDS Quad Diff Line Rcvr ds26c31.ibs interface 2/09/95 1.0 2.1 RS-422 Quad Diff Line Drvr ds26c32.ibs interface 2/09/95 1.0 2.1 RS-422 Quad Diff Line Recvr ds89c387.ibs interface 1/96 1 2.1 12 Channel Differential Driver ds34c87n.ibs interface 1/96 1 2.1 QUAD CMOS Tri-state Line Driver ds34c87m.ibs interface 1/96 1 2.1 QUAD CMOS Tri-state Line Driver 38c86av.ibs cbtl 9-18-95 1.0 1.1 CMOS BTL 9-Bit Latching Data Transceiver lct2524m.ibs cgs 04-05-95 1.0 1.1 1to4 Min. Skew 3V Clk Drvr ct2524m.ibs cgs 04-05-95 1.0 1.1 1to4 Min. Skew 3V Clk Drvr ct2524n.ibs cgs 04-05-95 1.0 1.1 1to4 Min. Skew 3V Clk Drvr c2525m.ibs cgs 04-05-85 1.0 1.1 1to8 Min. Skew Clk Drvr (CMOS) c2525n.ibs cgs 04-05-95 1.0 1.1 1to8 Min. Skew Clk Drvr (CMOS) ct2525m.ibs cgs 03-10-95 2.0 1.1 1to8 Min. Skew Clk Drvr (TTL Compa) ct2525n.ibs cgs 03-10-95 2.0 1.1 1to8 Min. Skew Clk Drvr (TTL Compa) b2525m.ibs cgs 04-05-95 1.0 1.1 1to8 Min. Skew Clk Drvr (Bipolar) b2525n.ibs cgs 04-05-95 1.0 1.1 1to8 Min. Skew Clk Drvr (Bipolar) c2526m.ibs cgs 04-05-95 1.0 1.1 1to8 Min. Skew Clk Drvr (CMOS) c2526n.ibs cgs 04-05-95 1.0 1.1 1to8 Min. Skew Clk Drvr (CMOS) ct2526m.ibs cgs 04-05-95 1.0 1.1 1to8 Min. Skew Clk Drvr (TTL Compa) ct2526n.ibs cgs 04-05-95 1.0 1.1 1to8 Min. Skew Clk Drvr (TTL Compa) ct2527v.ibs cgs 03-23-95 2.0 1.1 1to8 Min. Skew Clk Drvr (TTL Compa) b2528m.ibs cgs 04-05-95 1.0 1.1 1to10 Min. Skew Clk Drvr (Bipolar) b2528n.ibs cgs 04-05-95 1.0 1.1 1to10 Min. Skew Clk Drvr (Bipolar) b2528v.ibs cgs 04-05-95 1.0 1.1 1to10 Min. Skew Clk Drvr (Bipolar) b2529v.ibs cgs 04-05-95 1.0 1.1 1to10 Min. Skew Clk Drvr (Bipolar) 2534v.ibs cgs 04-05-95 1.0 1.1 Quad Mem Array Clk Drvr (Commercial) 2535v.ibs cgs 04-05-95 1.0 1.1 Quad Mem Array Clk Drvr (Industrial) 2536v.ibs cgs 04-05-95 1.0 1.1 Quad Mem Array Clk Drvr (Industrial) b303m.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Drvr b303n.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Drvr b303v.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Drvr b304m.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Drvr b304n.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Drvr b304v.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Drvr b305m.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Drvr b305n.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Drvr b305v.ibs cgs 04-05-95 1.0 1.1 Octal Div-by-2 Skew Clk Drvr 701v.ibs cgs 04-05-95 1.0 1.1 Low Skew PLL 1to8 CMOS Clk Drvr 2537v.ibs cgs 04-17-95 1.0 1.1 Quad Mem Array Clk Drvr (Industrial) pc87306.ibs superI_O 9-5-95 1.1 1.1 pc87306vul(SuperI/O) FDC,KBC,RTC,UARTs,IR,PP and IDE int -------------------------------------------------------------------------------- g612mea.ibs gtl 6/30/95 1.1 1.1 18-Bit CMOS GTL SSOP 56 Lead g612mtd.ibs gtl 6/30/95 1.1 1.1 18-Bit CMOS GTL TSSOP 56 Lead gp612mea.ibs gtl 6/30/95 1.1 1.1 18-Bit CMOS GTL SSOP 56 Lead gp612mtd.ibs gtl 6/30/95 1.1 1.1 18-Bit CMOS GTL TSSOP 56 Lead dp8440vj dram_ctl 6/28/95 1.0 1.1 Prog. DRAM Controller/Driver dp8441vj dram_ctl 6/28/95 1.0 1.1 Prog. DRAM Controller/Driver From owner-ibis Fri Feb 9 10:12:41 1996 Received: from icx.com (icx.rain.com [204.119.8.12]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id KAA20489 for ; Fri, 9 Feb 1996 10:12:36 -0800 (PST) Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 9 Feb 96 10:03 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 9 Feb 96 10:06 PST Message-Id: Date: Fri, 9 Feb 96 10:06 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS MEETING AGENDA 2/16/96 IBIS Open Forum Meeting Agenda for 2/16/96 Bridge Number Reservation # Passcode (916) 356-9200 2-48992 5519538 All meetings are 8:00 AM to 9:55 AM Pacific Time. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the Reservation Number and Passcode. 8:00 Check-In, Intros, Announcements Hobbs - Intros of New IBIS Participants, Meeting Quorum Hobbs - Membership Update and Treasurers Report Rusher/Hobbs - Review of Previous Meeting's Minutes (and ARs) Ross - Miscellany/Announcements All - Press & Web Page Updates All - New Models Available, Library Update All - Opens for New Issues All 8:15 EIA/IBIS Activities - 1996 Membership Rusher/Hobbs - DAC EDA Standards Booth Rusher/Hobbs - Progress on International Ratification Rusher - Progress on ANSI/EIA-656 Publication Rusher 8:25 Administrative and Project Discussions Web Project Update Huq Golden Parser 2.1 Status Powell/Ross S2IBIS 2.1 Status Ross/Steer S2IBIS Plot New Administrative Issues All 8:50 Review of Priorities for 1996 Hobbs, All 9:00 Technical Discussion BIRD33 - Physical Package Description Discussion Crisafulli (EGG8) BIRD31 - Connector Models Ross BIRD32 - Matrix Name Enhancement Proposal Kumar/Peters EGG9 - Stored Charge Proposal Progress Ross/Powell Other Possible BIRDS All New Technical Issues All 9:50 Wrap Up and Next Meetings Plans Hobbs 9:55 Sign Off From owner-ibis Thu Feb 15 11:23:39 1996 Received: from ormail.intel.com (ormail.intel.com [134.134.192.3]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id LAA01045 for ; Thu, 15 Feb 1996 11:23:37 -0800 (PST) Received: from relay.jf.intel.com (relay.jf.intel.com [134.134.131.6]) by ormail.intel.com (8.6.12/8.6.12) with SMTP id LAA00279 for ; Thu, 15 Feb 1996 11:15:13 -0800 Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.29.1 #4) id m0tn996-000Hz6C; Thu, 15 Feb 96 11:15 PST Received: by ccm.hf.intel.com (ccmgate 3.2 #6) Thu, 15 Feb 96 11:15:12 PST Date: Thu, 15 Feb 96 11:06:00 PST From: Arpad Muranyi Message-ID: To: ibis@vhdl.org Subject: Reference voltage clarification needed Hello IBIS folks, As I am working along on our IBIS model maker tool, I discovered another item that I believe needs clarification in the IBIS specification. We have four keywords in the IBIS spec which define the reference voltages of the pulldown, pullup, GNDclamp and POWERclamp. At the time these were conceived they might have been obvious, but reading the IBIS spec now I am confused as to how these must be interpreted. After talking to Bob Ross, I understand how we intended them to be used, but this is not clear from the spec alone. Examples: Connect a 5 volt CMOS device to a FLOATING supply with 5 volts between its (-) and (+) terminals. If I measure the pulldown I-V curves so that the GND connection of the curve tracer is connected to the (-) terminal of the floating supply, my Pulldown Reference is 0V. Similarly, if I connect the GND terminal of the curve tracer to the (+) terminal of the FLOATING(!) supply and measure the I-V curves of the pullup structure, my Pullup Reference is 5V. In other words, in this manner the refence voltages are derived with respect to the (-) terminal of the floating power supply. In another situation I am measuring an RS232 driver. The device is connected to three floating supplies so that it gets the necessary voltages of -10, 0, +5 and +10 volts. Since I know that the pulldown is associated with the -10 volt terminal, and the pullup is associated with the +10 volt terminal, I will connect the GND terminal of the curve tracer to -10V and +10 to obtain the pulldown and pullup I-V curves, respectively. The Pulldown Reference is -10V and the Pullup Reference is +10V in this case. Not that these numbers are all with respect to the internal ground, 0V. If I did not know what that was, I would end up using a different set of reference numbers (such as 0V and +20V), but the difference between Pullup and Pulldown References will still give me the Voltage Range (=Power Supply) voltage of the output stage of this driver. (This is why the Voltage Range keyword is somewhat redundant and is not required if all four Reference keywords are present). However, the reference keywords could be interpreted another way. Let's say someone wants to curve trace a pullup structure in a ground-relative (and not Vcc relative) way. In that case we have a device in high state, connected to a 5 volt supply and the GND terminal of the curve tracer is connected to 0V. So the Pullup Reference = 0V in this case. At the same time, the Pulldown Reference is also 0V, because the pulldown structure of the device was also done in a ground-relative manner. Even though the device was powered up with 5V, the difference between the two Reference voltages is 0, and value for the Voltage Range is lost if it is not explicitly defined. From this, I conclude that 1) the probing device must always be connected to the same voltage to which the measured structure is connected to (this might not always be known, though), or 2) we cannot get rid of the Voltage Range keyword even if all four Reference keywords are defined. There are many fine details and implications associated with this subject which I cannot explain here. The main thing is that the spec is not clear on which interpretation is the correct one regarding the Reference keywords. Or did I miss out on something? Arpad From owner-ibis Thu Feb 15 17:11:53 1996 Received: from icx.com (icx.rain.com [204.119.8.12]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id RAA00976 for ; Thu, 15 Feb 1996 17:11:41 -0800 (PST) Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 15 Feb 96 17:00 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 15 Feb 96 17:03 PST Message-Id: Date: Thu, 15 Feb 96 17:03 PST From: bob@icx.com ( Bob Ross) To: Arpad_Muranyi@ccm.fm.intel.com, ibis@vhdl.org Subject: Re: Reference voltage clarification needed Arpad and IBIS folks: I agree with you that this needs to be clarified. I support the notion that the [Voltage Range] or any of the Reference voltage values should be set to the actual supply voltages that the part is to be operated at. While it is possible to generate correct curves by using other values, the model itself should contain values that are the operating point values. As IBIS grows, more and more data will be related. Already, the [Rising Waveform] and [Falling Waveform] tables are related to [Pullup] and [Pulldown] data and are not totally independent. So, in the last example, while the [Pullup] table could be correctly presented with respect to a 0 V reference as might occur during an actual extraction, the safer IBIS model should be build using the expected operating supplies as the references So the [Pullup Reference] or [Voltage Range] should be set at 5 V and the [Pullup] voltage data shifted by 5 V if it were captured using a 0 V reference. Bob Ross, Interconnectix, Inc. > Date: Thu, 15 Feb 96 11:06:00 PST > From: Arpad Muranyi > Message-ID: > To: ibis@vhdl.org > Subject: Reference voltage clarification needed > Status: RO > Hello IBIS folks, > As I am working along on our IBIS model maker tool, I discovered another item > that I believe needs clarification in the IBIS specification. > We have four keywords in the IBIS spec which define the reference voltages of > the pulldown, pullup, GNDclamp and POWERclamp. At the time these were conceived > they might have been obvious, but reading the IBIS spec now I am confused as to > how these must be interpreted. After talking to Bob Ross, I understand how we > intended them to be used, but this is not clear from the spec alone. > Examples: > Connect a 5 volt CMOS device to a FLOATING supply with 5 volts between its (-) > and (+) terminals. > If I measure the pulldown I-V curves so that the GND connection of the curve > tracer is connected to the (-) terminal of the floating supply, my Pulldown > Reference is 0V. Similarly, if I connect the GND terminal of the curve tracer > to the (+) terminal of the FLOATING(!) supply and measure the I-V curves of the > pullup structure, my Pullup Reference is 5V. In other words, in this manner the > refence voltages are derived with respect to the (-) terminal of the floating > power supply. > In another situation I am measuring an RS232 driver. The device is connected to > three floating supplies so that it gets the necessary voltages of -10, 0, +5 and > +10 volts. > Since I know that the pulldown is associated with the -10 volt terminal, and the > pullup is associated with the +10 volt terminal, I will connect the GND terminal > of the curve tracer to -10V and +10 to obtain the pulldown and pullup I-V > curves, respectively. The Pulldown Reference is -10V and the Pullup Reference > is +10V in this case. Not that these numbers are all with respect to the > internal ground, 0V. If I did not know what that was, I would end up using a > different set of reference numbers (such as 0V and +20V), but the difference > between Pullup and Pulldown References will still give me the Voltage Range > (=Power Supply) voltage of the output stage of this driver. (This is why the > Voltage Range keyword is somewhat redundant and is not required if all four > Reference keywords are present). > However, the reference keywords could be interpreted another way. Let's say > someone wants to curve trace a pullup structure in a ground-relative (and not > Vcc relative) way. In that case we have a device in high state, connected to a > 5 volt supply and the GND terminal of the curve tracer is connected to 0V. So > the Pullup Reference = 0V in this case. At the same time, the Pulldown > Reference is also 0V, because the pulldown structure of the device was also done > in a ground-relative manner. Even though the device was powered up with 5V, the > difference between the two Reference voltages is 0, and value for the Voltage > Range is lost if it is not explicitly defined. > >From this, I conclude that 1) the probing device must always be connected to the > same voltage to which the measured structure is connected to (this might not > always be known, though), or 2) we cannot get rid of the Voltage Range keyword > even if all four Reference keywords are defined. > There are many fine details and implications associated with this subject which > I cannot explain here. The main thing is that the spec is not clear on which > interpretation is the correct one regarding the Reference keywords. Or did I > miss out on something? > Arpad From owner-ibis Fri Feb 16 06:02:55 1996 Received: from c11142-343dan.ece.ncsu.edu (c11142-343dan.ece.ncsu.edu [152.1.59.231]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id GAA11454 for ; Fri, 16 Feb 1996 06:02:54 -0800 (PST) From: mbs@eos.ncsu.edu Received: by c11142-343dan.ece.ncsu.edu (8.6.9/EC06jan95) id IAA12582; Fri, 16 Feb 1996 08:54:26 -0500 Message-Id: <199602161354.IAA12582@c11142-343dan.ece.ncsu.edu> To: ibis@vhdl.org Subject: LEX / YACC parser for ibisv2.1 Date: Fri, 16 Feb 96 08:54:26 EST Folks, There has been some mail regarding a formal definition for the ibis v2.1 grammar. At North Carolina State University we developed the spice-to-ibis converter using a parser using flex and bison. flex and bison are the gnu (public domain) versions of lex and yacc and are available for all know systems. (dos, all unix, macintosh etc etc.) The only problem is that it uses the first generation golden parser header files. The final version of the header files were so radically changed from the first version that we were not able to make the necessary changes in time to do a timely release of s2ibis v2. Anyway ... this could be the best place to start. Parsing an input file to s2ibis is very similar to parsing a *.ibs file. I wrote the parser originally to parse ibis v2.1 *.ibs files but when the golden parser project was funded I ceased development. It was resurrected as the s2ibis v2 parser. The procedure that could be followed is 1. Convert s2ibis to use the new golden parser header files 2. Update the s2ibis parser to become an ibis parser. So, how will this be done. A volunteer prepared to devote 1-2 months of his life? Student labor (I may be able to arange this with a few $k's)? Pay someone per the golden parser model? Michael Steer IBIS Librarian From owner-ibis Wed Feb 21 12:14:43 1996 Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id MAA06818 for ; Wed, 21 Feb 1996 12:14:42 -0800 (PST) Received: from uucp5.UU.NET by relay5.UU.NET with SMTP id QQadxo28704; Wed, 21 Feb 1996 15:06:16 -0500 (EST) Received: from qdt.UUCP by uucp5.UU.NET with UUCP/RMAIL ; Wed, 21 Feb 1996 15:06:16 -0500 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00863; Wed, 21 Feb 96 11:57:34 PST Received: from awacs.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA23082; Wed, 21 Feb 96 11:57:35 PST Date: Wed, 21 Feb 96 11:57:34 PST From: crokusek@qdt.com (Chris Rokusek) Message-Id: <9602211957.AA23082@hal.qdt.com> Received: by awacs.qdt.com (4.1/SMI-4.1) id AA21079; Wed, 21 Feb 96 11:57:26 PST To: ibis@vhdl.org Cc: crokusek@qdt.com Subject: EGG10 - Proposed Automatic Validation Checks Fellow IBISians, Here is EGG10 proposing 4 "automatic" checks that could be built into the ibis checker to prevent some common model building pitfalls at build time rather than at simulation time after the model has been distributed. Any feedback is greatly appreciated! -Chris Rokusek Quad Design ------------------------------------------------------------------- EGG10 - PROPOSED AUTOMATIC VALIDATION CHECKS FOR IBIS_CHK. ------------------------------------------------------------------- Items #1 and #2 are aimed toward checking that an IBIS file was built correctly and prevent common mistakes like getting spice output files overwritten, names mangled, and current/voltage polarity reversed. Items #3 and #4 attempt to verify that the data contained within the IBIS file is generally useful for SI simulation. 1) CURRENT DIRECTION REVERSED OVER 50% OF POINTS IN TABLE. REASON: ------- Simple protection against wrong current polarity. RULE: ----- (increase = more positive or less negative): For [Pulldown] and [GND Clamp] tables: As Voltage increases, Current should increase. For [Pullup] and [POWER Clamp] tables: As Voltage increases, Current should decrease. 2) WAVEFORM "DC" POINTS DO NOT MATCH VI CURVE FOR SPECIFIED LOAD. REASON: ------- To insure that the Voltage/Time waveforms match the specified test load. To insure that the min/typ/max VT table corresponds to the min/typ/max VI table RULE: ----- This check would look at the beginning and ending voltages of a VT Waveform which indicate DC settling points and compare each of these voltages to the given DC VI curves using the load specified for the waveform data. For example, given... [Rising Waveform] R_fixture = 50 V_fixture = 2.5 C_fixture = 50.0pF /* not important for this test */ ...and a waveform like... +V | | | 4.2V | ******** | **** | | * | | first point * | | | * | 2.5V | | * | | | * last point | V * | * 0.5V | ********** | | ------------------------------------- +Time Can use the first point (see above) at 0.5V to check against the low VI curve (see below)... +I | Low State VI Curve | | | V | x LLLLLLLLLLLLLLLLLLLL | x LLLLLLL | x LLL | xLL | LLvx | L v x | L v x | L v x | L v x |L v x <--- slope = -50.0 = R_fixture |L v x L v x _------ Voltage = V_fixture L v x / ----L-------v---------x---------------------- +V L| | | | L 0.0V ?=? 2.5V 5.0V 0.5V? The load line "xxxx" should intersect the low state VI curve "LLLL" at ~= 0.5V indicated by the first point of the [Rising Waveform]. Similarly, the High VI curve can be correlated to the last point of the Rising Waveform. This should be repeated for all waveforms. ** Note that this check requires LOW curve = [PullDown] + [GND_Clamp]. 3) EXTREME CURRENTS IN VI CURVE...(Generally found shunt curves) REASON: ------- Many SPICE models are tested against data-book performance parameters designed to be used within the normal operating range of the device and are and not meant for simulation outside of that operating range into the protection range. However, for accurate SI simulation, it becomes important to have a well-defined protection range. Even if a model would fail this test, it still may be usable for SI simulation implying that failing this test should flag a WARNING but not an ERROR. The model developer will become aware that the SPICE model could be improved. RULE: ----- Any VI point current should not exceed XX.X Amps when the voltage is within +-2.5V of operating range. 4) VERY FEW TRANSITION POINTS IN VI CURVE... REASON: ------- Perhaps a more important check (then #3) would test for a significant number of transition points at the elbow of a shunt curve or bend(s) within VI curves. This test could be applied to all VI curves (not just shunt) as a test to determine if the voltage step was small enough. RULE: ----- I believe this can be implemented as a comparison of some absolute maximum "delta ohms" to the second derivative at each point of each VI curve. Example Shunt Curve that FAILS test #4... +I | ----------*---*---*--*---*---*-- +V | | | * | | | * | | | Example Shunt Curve that PASSES test #4... +I | ----------********************* +V **** | ** | * | ** | * | ** | * | ** | * | --------------------------------------------------------------------------- From owner-ibis Wed Feb 21 13:55:17 1996 Received: from icx.com (icx.rain.com [204.119.8.12]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id NAA07619 for ; Wed, 21 Feb 1996 13:54:56 -0800 (PST) Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 21 Feb 96 13:46 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 21 Feb 96 13:49 PST Message-Id: Date: Wed, 21 Feb 96 13:49 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS MINUTES 2/16/96 DATE: February 21, 1996 SUBJECT: 2/16/96 EIA IBIS Open Forum Minutes VOTING MEMBERS AND 1996 PARTICIPANTS LIST: Cadence Design C. Kumar* Contec CAE, Ltd. Dileep Divekar, Norio Matsui Hewlett Packard, EEsof Karl Kachigan, Henry Wu HyperLynx Kellee Crisafulli IBM (Jay Diepenbrock) INCASES Olaf Rethmeier* Intel Corporation Stephen Peters*, Will Hobbs*, Arpad Muranyi*, John Keifer, Aaron Tang, Duane Quiet*, Donald Telian, Tim Kruchowski Interconnectix, Inc. Bob Ross* Meta-Software (Les Spruiell) Mitsubushi Tam Cao Motorola (Ron Werner) National Semiconductor Syed Huq*, Donald Snyder, Chune-Sin Yeh NCR (formerly ATT-GIS) Dave Moxley*, Richard Mellitz NEC (Hiroshi Matsumoto), Quad Design Jon Powell, Chris Rokusek* Quantic Labs (Mike Ventham) Tanner Research, Inc. (Scott Wedge) Texas Instruments Roger Cline, Ben Andresen, Sri Jandhyala, Tareq Shahwan, Dan Phipps Thomson-CSF/SCTF (Jean LeBrun) UniCAD Canada Ltd. Celso Faia VLSI Technology Dick Ulmer, Sung Oh*, Swami Gangadharan, Daniel Kim, Tom Dockery Zuken-Redac (John Berrie) OTHER PARTICIPANTS IN 1996: Alcatel John Fitzpatrick* Altera Vadim von Brzeski AMP Hank Herrmann* Apteq Design System Dan FitzPatrick Compaq Mark Leonard Cypress Bruce Wenniger Digital Equipment Corp. Jeff Chu* EIA Patti Rusher IC Works Eric Chen Intergraph/Veribest Ian Dodd Micron Technology Brian Johnson MicroSim Ralph Perez North Carolina State U. (Michael Steer) S3, Inc. Sarathy Sribhashyam, Phap Duong Seimans Nixdorf Arnaud Lacariere Tektronix, Inc. Brock Hannibal TRW & Free Model Foundation Robert Harrison Zeelan Technology George Opsahl* In the list above, attendees at the meeting are indicated by *. Principle members or other active members who have not attended are in parentheses. Upcoming Meetings: The bridge numbers for future IBIS teleconferences are as follows: Date Bridge Number Reservation # Passcode 3/8/96 (916) 356-9200 1-55736 5232597 3/29/96 (916) 356-9200 1-55737 1119667 All meetings are 8:00 AM to 9:55 AM Pacific Time. We try to have agendas out 7 days before each open forum and meeting minutes out within 7 days after. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the reservation number and passcode. NOTE: "AR" = Action Required. -------------------------------- MINUTES ------------------------------------- INTRODUCTIONS Jeff Chu of Digital Equipment Corporation indicated that Digital has an interest in making including those for the Alpha Chip and using IBIS models. John Fitzpatrick of Alcatel called from France and gave a description of his role in the general technology lab of a hardware design group. Alcatel uses IBIS models for general rule checking and also for some analog analysis. EIA MEMBERSHIP AND TREASURER'S REPORT Patti Rusher reports that Mitusbishi Electric in Durham, North Carolina has become a full member the EIA IBIS Committee. MINUTES REPORT, MISC. No corrections. Will Hobbs will give Bob Ross some minor text corrections. MISCELLANY/ANNOUNCEMENTS Bob Ross would like electronic copies of the Face to Face meeting slides sent to him for putting on vhdl.org. PRESS AND WEB PAGE UPDATES Richard Goering column "EDA caught in Web" in Electronic Engineering Times, February 12, 1996, pg. 76 mentions winibis and HyperLynx home page and IBIS. Zen Mu and Paul Wang wrote "Developing Simulation Models for High-Speed Applications" in Printed Circuit Design, February, 1996, pp. 30-34 mentions IBIS. A Netscape search using [IBIS Models] yields several sites including the Motorola Power PC IBIS models and a downloadable application note on IBIS models from Micron Technology. NEW MODELS Syed Huq reported National Semiconductor has released three new models. Arpad Muranyi reported that Intel will post one new model. OPENS FOR NEW ISSUES vhdl.org update Roster update EIA/IBIS 1996 MEMBERSHIP NCR, Intel, and Interconnectix reported that revised invoices have not been received. AR - Bob Ross call EIA and find out what has happened [Done - Copies of the latest invoice will be FAXed to companies since reissuing invoices causes accounting problems.] DAC STANDARDS BOOTH The Design Automation Conference (DAC) in June, 1996 will have a Standards booth. We will have literature, and the booth will serve as a place where IBIS people can meet and convey IBIS information. ANSI/EIA-656 INTERNATIONAL RATIFICATION Patti Rusher has reported that the US TAG (Technical Advisory Group) has approved a New Work Item Proposal for IBIS to go to IEC TC93. ANSI/EIA-656 PUBLICATION The document is currently in the EIA publications department being prepared to be forwarded to Global Engineering Documents for distribution. EIA WEB UPDATE Syed Huq reported that EIA has added a direct link to the IBIS Web page under the Design Automation Division subgroup by accessing http://www.eia.org Syed is investigating Web counting programs with Steve Malone of EIA that work with a PC server. While we are an organization, we still may decide to pay for usage of a shareware program. Syed's plan is to publicize the Web site once the counter is installed. Olaf Rethmeier indicated INCASES may want to supply an updated logo. He should send it directly to Jon Powell since the permission letter is already on file. VHDL.ORG The reflector has been fixed by Randy Harr and is working. So individuals reported that messages come from "owner-ibis". Bob Ross will investigate. ROSTER UPDATE Bob Ross has received responses for Roster update information from about half of the people. Bob will seek responses and post the new roster soon. Non-member companies who do not respond will be dropped. GOLDEN PARSER UPDATE Bob Ross will formally issue the three bugs through the newly established parser reporting system before we issue a parser correction. A bug directory exists, and a BUG form will be available there. SPICE TO IBIS VERSION 2.1 Bob Ross reported no further information, but will ask Michael Steer for a report on its status regarding reported problems. SPICE TO IBIS PLOT VERSION 1.2 A corrected version has been put on vhdl.org. It requires perl and gnuplot, but works very nicely to display the IBIS V/I and V/T tables. PRIORITIES FOR 1996 Will Hobbs discussed priorities for 1996. He suggested validation, extended package models, diode transit time, and connectors. Hank Herrmann pointed out that connectors are different than extended package models. Bob Ross added staggered turn-on time buffers. Will added feedback. Arpad Muranyi asked if scaling was also an important item. Stephen Peters mention SSO. Chris Rokusek wants clarification on worse case and best case parameters in IBIS. Other specification additions for hysteresis, undershoot, overshoot, were suggested by Bob. The tabulated list is shown: validation (post 4 or 5 reality checks and add to parser) extended package models (electrical and physical) diodes connectors staggered turn-on buffers feedback scaling better handling of SSO clarification of worst case and best case corners specification parameters (hysteresis, overshoot, etc.) cookbook (may contain validation and corners) new overview more models ... Will proposed we have IBIS Version 3.0 by the end of the year. Bob would like to see a good start by DAC, but would be comfortable with late summer. It was suggested that priority voting be done on the reflector. BIRD33 (EGG8) - PHYSICAL PACKAGE DISCUSSION Olaf Rethmeier referred to the physical description that Kellee Crisafulli had offered. He said that a European group (JESSI) has defined a physical multiboard PCB description sponsored by EC. He is waiting to make an appropriate overview available. Olaf says it is similar to what Kellee has proposed. It describes a neutral format, is a context free grammar, is simple to parse and is human-readable. It has been under development for two years. It is not yet a standard. Olaf will post SULTAN (Standard Universal Layout Information Transport Language) information the reflector. BIRD31 - CONNECTOR MODELS Bob Ross still plans to issue a revised BIRD31.1 within a few weeks to reflect the changes that were discussed at previous meetings and from older comments. BIRD32 PACKAGE MODEL ENHANCEMENT C. Kumar is still interested in a more general electrical description including some Spice-like capability. Stephen Peters is concerned about the Ball Grid Array model which includes and extra stub. EGG9 - HANDLING STORED CHARGE Bob Ross has sent code to Jon Powell for further investigation and plans to issue a BIRD. BIRD34 was assigned by Will Hobbs. VALIDATION In the remaining time, Will Hobbs opened a discussion on validation, one of the items on the priority list. He noted that some vendors are reluctant to release IBIS models because they are not sure how they should be checked. Regarding the disclaimer, Stephen Peters indicates that the typical disclaimer is that the model is used for ".. modeling purposes only, and the results are not guaranteed." This is a fairly typical legal statement. He feels that the model provider can only guarantee that the model data is correct. How well it performs in simulation depends on the simulator. Duane Quite wants more information on equipment and techniques used to develop models such as the test fixtures and process. Arpad Muranyi indicates he has a specification on his tool which gives data derivation methodologies. Duane feels that the level of communication between the model creator and the consumer needs to be increased. Syed Huq suggests a contact name. Hank Herrmann would like some procedure to indicate that the model is validated and perhaps how. The intent is to define the range over which the model can be trusted and to increase the comfort level of the customers. The [File Rev] in the IBIS specification is not mandatory, but can be used to state the level of validation. Dave Moxley described the NCR test board validation process where simulations with Spice and IBIS are correlated. Will mentioned the IBIS model can contain a "golden waveform" within it for reference. Syed Huq described the National process where models are extracted from bench measurements and validated using a tool. A test circuit is simulated, and the results are correlated with measurements. Bob Ross questioned the verification of some Spice models and wondered what process is used to validate them. Arpad described further his work which develops Version 2.1 models for CMOS. He started his work prior to the North Carolina State University work, and therefore it is not based on the s2ibis2 utility. He cannot share the tool itself due to a licensing restriction. In closing, Will would like the IBIS forum to develop an application note on validation. Perhaps a technical writer could be hired. NEXT MEETING: The next telephone meeting is set for Friday, March 8, 1996. ============================================================================== NOTES IBIS CHAIR: Will Hobbs (503) 264-4369, Fax (503) 264-4210 will_hobbs@ccm.jf.intel.com Server Chipset System Validation Manager, Intel Corp. 2111 NE 28th M/S JF1-57, Hillsboro, OR 97124 USA VICE CHAIR: Jon Powell (805) 988-8250, Fax: (805) 988-8259 jonp@qdt.com Transmission-Line Products Manager, Quad Design 1385 Del Norte Rd., Camarillo, CA 93010 SECRETARY: Bob Ross (503) 603-2523, fax (503) 639-3469 bob@icx.com Modeling Engineer, Interconnectix, Inc. 10220 SW Nimbus Ave, K4, Portland, OR 97223 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: ibis-request@vhdl.org To join, change, or drop from either the IBIS Open Forum Reflector (ibis@vhdl.org), the IBIS Users' Group Reflector (ibis-users@vhdl.org) or both. State your request. ibis-info@vhdl.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@vhdl.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. ibis-users@vhdl.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. ibischk-bug@vhdl.org To report ibischk2 parser bugs. The Bug Report Form Resides on vhdl.org in /pub/ibis/bugs/bugform.txt along with reported bugs. Information on IBIS technical contents, IBIS participants, and actual IBIS models are available on the IBIS Home page: http://www.eia.org/eig/ibis/ibis.htm Check the pub/ibis directory on vhdl.org for more information on previous discussions and results. You can get on via ftp anonymous, "guest" login from telnet or dial-in (415-335-0110), or send an e-mail request to the automatic archive server, archive@vhdl.org. "IBIS Spoken Here" placards are available from Jon Powell (jonp@qdt.com) for use at trade shows. ============================================================================== From owner-ibis Wed Feb 21 19:18:19 1996 Received: from icx.com (icx.rain.com [204.119.8.12]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id TAA09857 for ; Wed, 21 Feb 1996 19:17:54 -0800 (PST) Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 21 Feb 96 19:08 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 21 Feb 96 19:11 PST Message-Id: Date: Wed, 21 Feb 96 19:11 PST From: bob@icx.com ( Bob Ross) To: crokusek@qdt.com, ibis@vhdl.org Subject: Re: EGG10 - Proposed Automatic Validation Checks Chris and IBISians; Here are a few comments on EGG10. (1) Could you expand on what additional testing is needed? The Version 2.1 Specification already gives WARNING messages for non-monotonic data in tables, and already gives and ERROR message for wrong polarity data based on the starting and final point values. So I think your first test is already covered. It works correctly for ECL devices as well. If the [IBIS Ver] of a Version 1.1 file is changed to 2.1, then Version 1.1 files will also go through these tests. (2) I think testing Waveform End-points against V/I data is a good idea. The test will also reveal problems such as providing a min V/T table, but having only NA data for the corresponding V/I table. I would expand on the comment to have Both the [Power Clamp] and [Gnd Clamp] tables added for all tests. If these clamps do not have data in the regions of interest, then linear extrapolation of the data needs to be done. (3) The extreme current test to provide a warning looks useful. There might be more discussion about the delta V and what max I to use. If the values are too low, then two many incorrect WARNINGS may be produced, and a real problem still may be discovered. (4) This also looks like a useful test. It would also detect incorrect discontinuities in data that may have gone unnoticied. However, I am not sure what defines an abrupt slope change in V/I data. In some simulations, this may not be critical. Anyway, you have provided some very good ideas for a parser enhansement project. The main issues relate to what values to use. Bob Ross Interconnectix, Inc. > Date: Wed, 21 Feb 96 11:57:34 PST > From: crokusek@qdt.com (Chris Rokusek) > To: ibis@vhdl.org > Cc: crokusek@qdt.com > Subject: EGG10 - Proposed Automatic Validation Checks > Status: RO > Fellow IBISians, > Here is EGG10 proposing 4 "automatic" checks that could be built into > the ibis checker to prevent some common model building pitfalls at > build time rather than at simulation time after the model has been > distributed. > Any feedback is greatly appreciated! > -Chris Rokusek > Quad Design > ------------------------------------------------------------------- > EGG10 - PROPOSED AUTOMATIC VALIDATION CHECKS FOR IBIS_CHK. > ------------------------------------------------------------------- > Items #1 and #2 are aimed toward checking that an IBIS file was built > correctly and prevent common mistakes like getting spice output files > overwritten, names mangled, and current/voltage polarity reversed. > Items #3 and #4 attempt to verify that the data contained within the > IBIS file is generally useful for SI simulation. > 1) CURRENT DIRECTION REVERSED OVER 50% OF POINTS IN TABLE. > REASON: > ------- > Simple protection against wrong current polarity. > RULE: > ----- > (increase = more positive or less negative): > For [Pulldown] and [GND Clamp] tables: > As Voltage increases, Current should increase. > For [Pullup] and [POWER Clamp] tables: > As Voltage increases, Current should decrease. > 2) WAVEFORM "DC" POINTS DO NOT MATCH VI CURVE FOR SPECIFIED LOAD. > REASON: > ------- > To insure that the Voltage/Time waveforms match the specified test > load. > To insure that the min/typ/max VT table corresponds to the > min/typ/max VI table > RULE: > ----- > This check would look at the beginning and ending voltages of a VT > Waveform which indicate DC settling points and compare each of these > voltages to the given DC VI curves using the load specified for the > waveform data. > For example, given... > [Rising Waveform] > R_fixture = 50 > V_fixture = 2.5 > C_fixture = 50.0pF /* not important for this test */ > ...and a waveform like... > +V > | > | > | > 4.2V | ******** > | **** | > | * | > | first point * | > | | * | > 2.5V | | * | > | | * last point > | V * > | * > 0.5V | ********** > | > | > ------------------------------------- +Time > Can use the first point (see above) at 0.5V to check against the > low VI curve (see below)... > +I > | Low State VI Curve > | | > | V > | x LLLLLLLLLLLLLLLLLLLL > | x LLLLLLL > | x LLL > | xLL > | LLvx > | L v x > | L v x > | L v x > | L v x > |L v x <--- slope = -50.0 = R_fixture > |L v x > L v x _------ Voltage = V_fixture > L v x / > ----L-------v---------x---------------------- +V > L| | | | > L > 0.0V ?=? 2.5V 5.0V > 0.5V? > The load line "xxxx" should intersect the low state VI curve "LLLL" > at ~= 0.5V indicated by the first point of the [Rising Waveform]. > Similarly, the High VI curve can be correlated to the last point > of the Rising Waveform. This should be repeated for all waveforms. > ** Note that this check requires LOW curve = [PullDown] + [GND_Clamp]. > 3) EXTREME CURRENTS IN VI CURVE...(Generally found shunt curves) > REASON: > ------- > Many SPICE models are tested against data-book performance parameters > designed to be used within the normal operating range of the device > and are and not meant for simulation outside of that operating range > into the protection range. However, for accurate SI simulation, it > becomes important to have a well-defined protection range. > Even if a model would fail this test, it still may be usable for SI > simulation implying that failing this test should flag a WARNING > but not an ERROR. The model developer will become aware that the > SPICE model could be improved. > RULE: > ----- > Any VI point current should not exceed XX.X Amps when the voltage > is within +-2.5V of operating range. > 4) VERY FEW TRANSITION POINTS IN VI CURVE... > REASON: > ------- > > Perhaps a more important check (then #3) would test for a > significant number of transition points at the elbow of a shunt > curve or bend(s) within VI curves. > This test could be applied to all VI curves (not just shunt) > as a test to determine if the voltage step was small enough. > RULE: > ----- > I believe this can be implemented as a comparison of some absolute > maximum "delta ohms" to the second derivative at each point of > each VI curve. > Example Shunt Curve that FAILS test #4... > +I > | > ----------*---*---*--*---*---*-- +V > | > | > | > * | > | > | > * | > | > | > Example Shunt Curve that PASSES test #4... > +I > | > ----------********************* +V > **** | > ** | > * | > ** | > * | > ** | > * | > ** | > * | > --------------------------------------------------------------------------- From owner-ibis Thu Feb 22 06:59:02 1996 Received: from eagle.ColumbiaSC.NCR.COM ([153.78.178.8]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id GAA20566 for ; Thu, 22 Feb 1996 06:59:00 -0800 (PST) From: mellitz@eagle.ColumbiaSC.NCR.COM >From: mellitz@eagle (Richard.Mellitz) Content-Type: text Message-Id: <9602220950.ZM1641@eagle> Date: Thu, 22 Feb 1996 09:50:08 -0500 In-Reply-To: icx.com!bob ( Bob Ross) "Re: EGG10 - Proposed Automatic Validation Checks" (Feb 21, 7:11pm) References: X-Mailer: Z-Mail (2.1.4 02apr93) To: ibis@vhdl.org Subject: Re: EGG10 - Proposed Automatic Validation Checks On Feb 21, 7:11pm, Bob Ross wrote: > Subject: Re: EGG10 - Proposed Automatic Validation Checks > Chris and IBISians; > > Here are a few comments on EGG10. > > (1) Could you expand on what additional testing is needed? The Version 2.1 > Specification already gives WARNING messages for non-monotonic data in > tables, and already gives and ERROR message for wrong polarity data based > on the starting and final point values. So I think your first test is already > covered. It works correctly for ECL devices as well. If the [IBIS Ver] of > a Version 1.1 file is changed to 2.1, then Version 1.1 files will also > go through these tests. > [Rich M.] For what its worth (FWIW): This is the most common problem I've encountered with having "other" people do V-I curves for me. > (2) I think testing Waveform End-points against V/I data is a good idea. > The test will also reveal problems such as providing a min V/T table, but > having only NA data for the corresponding V/I table. I would expand on > the comment to have Both the [Power Clamp] and [Gnd Clamp] tables added > for all tests. If these clamps do not have data in the regions of > interest, then linear extrapolation of the data needs to be done. > > (3) The extreme current test to provide a warning looks useful. There > might be more discussion about the delta V and what max I to use. If > the values are too low, then two many incorrect WARNINGS may be produced, > and a real problem still may be discovered. > > (4) This also looks like a useful test. It would also detect incorrect > discontinuities in data that may have gone unnoticied. However, I am not > sure what defines an abrupt slope change in V/I data. In some simulations, > this may not be critical. [Rich M. ] Large second derivatives around the current axis can cause incorrect buffer delay predictions. I think the test is useful. Its sort of like asking are we "poping the clutch" or just "punching the peddle". :-) > > Anyway, you have provided some very good ideas for a parser enhansement project. > The main issues relate to what values to use. > > Bob Ross > Interconnectix, Inc. > > > Date: Wed, 21 Feb 96 11:57:34 PST > > From: crokusek@qdt.com (Chris Rokusek) > > To: ibis@vhdl.org > > Cc: crokusek@qdt.com > > Subject: EGG10 - Proposed Automatic Validation Checks > > Status: RO > > > Fellow IBISians, > > > Here is EGG10 proposing 4 "automatic" checks that could be built into > > the ibis checker to prevent some common model building pitfalls at > > build time rather than at simulation time after the model has been > > distributed. > > > Any feedback is greatly appreciated! > > > -Chris Rokusek > > Quad Design > > > > ------------------------------------------------------------------- > > EGG10 - PROPOSED AUTOMATIC VALIDATION CHECKS FOR IBIS_CHK. > > ------------------------------------------------------------------- > > > Items #1 and #2 are aimed toward checking that an IBIS file was built > > correctly and prevent common mistakes like getting spice output files > > overwritten, names mangled, and current/voltage polarity reversed. > > > Items #3 and #4 attempt to verify that the data contained within the > > IBIS file is generally useful for SI simulation. > > > > > 1) CURRENT DIRECTION REVERSED OVER 50% OF POINTS IN TABLE. > > > REASON: > > ------- > > > Simple protection against wrong current polarity. > > > > RULE: > > ----- > > > (increase = more positive or less negative): > > > > For [Pulldown] and [GND Clamp] tables: > > > As Voltage increases, Current should increase. > > > > For [Pullup] and [POWER Clamp] tables: > > > As Voltage increases, Current should decrease. > > > > > > 2) WAVEFORM "DC" POINTS DO NOT MATCH VI CURVE FOR SPECIFIED LOAD. > > > REASON: > > ------- > > > To insure that the Voltage/Time waveforms match the specified test > > load. > > > To insure that the min/typ/max VT table corresponds to the > > min/typ/max VI table > > > > RULE: > > ----- > > > This check would look at the beginning and ending voltages of a VT > > Waveform which indicate DC settling points and compare each of these > > voltages to the given DC VI curves using the load specified for the > > waveform data. > > > For example, given... > > > [Rising Waveform] > > R_fixture = 50 > > V_fixture = 2.5 > > C_fixture = 50.0pF /* not important for this test */ > > > > ...and a waveform like... > > > +V > > > | > > | > > | > > 4.2V | ******** > > | **** | > > | * | > > | first point * | > > | | * | > > 2.5V | | * | > > | | * last point > > | V * > > | * > > 0.5V | ********** > > | > > | > > ------------------------------------- +Time > > > > > Can use the first point (see above) at 0.5V to check against the > > low VI curve (see below)... > > > > > +I > > > | Low State VI Curve > > | | > > | V > > | x LLLLLLLLLLLLLLLLLLLL > > | x LLLLLLL > > | x LLL > > | xLL > > | LLvx > > | L v x > > | L v x > > | L v x > > | L v x > > |L v x <--- slope = -50.0 = R_fixture > > |L v x > > L v x _------ Voltage = V_fixture > > L v x / > > ----L-------v---------x---------------------- +V > > L| | | | > > L > > 0.0V ?=? 2.5V 5.0V > > 0.5V? > > > > > The load line "xxxx" should intersect the low state VI curve "LLLL" > > at ~= 0.5V indicated by the first point of the [Rising Waveform]. > > > Similarly, the High VI curve can be correlated to the last point > > of the Rising Waveform. This should be repeated for all waveforms. > > > ** Note that this check requires LOW curve = [PullDown] + [GND_Clamp]. > > > > > 3) EXTREME CURRENTS IN VI CURVE...(Generally found shunt curves) > > > REASON: > > ------- > > > Many SPICE models are tested against data-book performance parameters > > designed to be used within the normal operating range of the device > > and are and not meant for simulation outside of that operating range > > into the protection range. However, for accurate SI simulation, it > > becomes important to have a well-defined protection range. > > > Even if a model would fail this test, it still may be usable for SI > > simulation implying that failing this test should flag a WARNING > > but not an ERROR. The model developer will become aware that the > > SPICE model could be improved. > > > > RULE: > > ----- > > > Any VI point current should not exceed XX.X Amps when the voltage > > is within +-2.5V of operating range. > > > > > 4) VERY FEW TRANSITION POINTS IN VI CURVE... > > > > REASON: > > ------- > > > > Perhaps a more important check (then #3) would test for a > > significant number of transition points at the elbow of a shunt > > curve or bend(s) within VI curves. > > > This test could be applied to all VI curves (not just shunt) > > as a test to determine if the voltage step was small enough. > > > > RULE: > > ----- > > > I believe this can be implemented as a comparison of some absolute > > maximum "delta ohms" to the second derivative at each point of > > each VI curve. > > > > Example Shunt Curve that FAILS test #4... > > > +I > > > | > > > ----------*---*---*--*---*---*-- +V > > | > > | > > | > > * | > > | > > | > > * | > > | > > | > > > > > Example Shunt Curve that PASSES test #4... > > > +I > > > | > > > ----------********************* +V > > **** | > > ** | > > * | > > ** | > > * | > > ** | > > * | > > ** | > > * | > > > > > > --------------------------------------------------------------------------- > > >-- End of excerpt from Bob Ross From owner-ibis Thu Feb 22 08:39:42 1996 Received: from ormail.intel.com (ormail.intel.com [134.134.192.3]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id IAA21261 for ; Thu, 22 Feb 1996 08:39:41 -0800 (PST) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.intel.com (8.6.12/8.6.12) with ESMTP id IAA29510; Thu, 22 Feb 1996 08:31:14 -0800 Received: from xtg801 by ichips.intel.com (8.7.1/jIII); Thu, 22 Feb 1996 08:31:11 -0800 (PST) Received: from localhost by xtg801 (4.1/10.0i); Thu, 22 Feb 96 08:31:10 PST Message-Id: <9602221631.AA26484@xtg801> To: ibis@vhdl.org Cc: crokusek@qdt.com Subject: EGG10 - Proposed Automatic Validation Checks Date: Thu, 22 Feb 1996 08:31:09 -0800 From: Stephen Peters Hello Chris, and Fellow IBISans: Reading Chris's EEG 10 got me thinking about another test I would like to see added to this golden parser EGG. How about a 'units' check? I would like to see a warning if the values listed with [C_comp], [Package], R_pin, L_pin, C_pin, [Ramp] and the waveform fixture variables do not have a suffix attached. For example, if a model maker entered '5' instead of '5p' as the value of C_comp, the golden parser would flag it with a warning. I have seen this error several times, especially with the ramp rate number (leaving the 'n' off the Dt portion of the ratio). Regards, Stephen Peters Intel Corp. =------------------------------------ Fellow IBISians, Here is EGG10 proposing 4 "automatic" checks that could be built into the ibis checker to prevent some common model building pitfalls at build time rather than at simulation time after the model has been distributed. Any feedback is greatly appreciated! -Chris Rokusek Quad Design ------------------------------------------------------------------- EGG10 - PROPOSED AUTOMATIC VALIDATION CHECKS FOR IBIS_CHK. ------------------------------------------------------------------- Items #1 and #2 are aimed toward checking that an IBIS file was built correctly and prevent common mistakes like getting spice output files overwritten, names mangled, and current/voltage polarity reversed. Items #3 and #4 attempt to verify that the data contained within the IBIS file is generally useful for SI simulation. 1) CURRENT DIRECTION REVERSED OVER 50% OF POINTS IN TABLE. REASON: ------- Simple protection against wrong current polarity. RULE: ----- (increase = more positive or less negative): For [Pulldown] and [GND Clamp] tables: As Voltage increases, Current should increase. For [Pullup] and [POWER Clamp] tables: As Voltage increases, Current should decrease. 2) WAVEFORM "DC" POINTS DO NOT MATCH VI CURVE FOR SPECIFIED LOAD. REASON: ------- To insure that the Voltage/Time waveforms match the specified test load. To insure that the min/typ/max VT table corresponds to the min/typ/max VI table RULE: ----- This check would look at the beginning and ending voltages of a VT Waveform which indicate DC settling points and compare each of these voltages to the given DC VI curves using the load specified for the waveform data. For example, given... [Rising Waveform] R_fixture = 50 V_fixture = 2.5 C_fixture = 50.0pF /* not important for this test */ ...and a waveform like... +V | | | 4.2V | ******** | **** | | * | | first point * | | | * | 2.5V | | * | | | * last point | V * | * 0.5V | ********** | | ------------------------------------- +Time Can use the first point (see above) at 0.5V to check against the low VI curve (see below)... +I | Low State VI Curve | | | V | x LLLLLLLLLLLLLLLLLLLL | x LLLLLLL | x LLL | xLL | LLvx | L v x | L v x | L v x | L v x |L v x <--- slope = -50.0 = R_fixture |L v x L v x _------ Voltage = V_fixture L v x / ----L-------v---------x---------------------- +V L| | | | L 0.0V ?=? 2.5V 5.0V 0.5V? The load line "xxxx" should intersect the low state VI curve "LLLL" at ~= 0.5V indicated by the first point of the [Rising Waveform]. Similarly, the High VI curve can be correlated to the last point of the Rising Waveform. This should be repeated for all waveforms. ** Note that this check requires LOW curve = [PullDown] + [GND_Clamp]. 3) EXTREME CURRENTS IN VI CURVE...(Generally found shunt curves) REASON: ------- Many SPICE models are tested against data-book performance parameters designed to be used within the normal operating range of the device and are and not meant for simulation outside of that operating range into the protection range. However, for accurate SI simulation, it becomes important to have a well-defined protection range. Even if a model would fail this test, it still may be usable for SI simulation implying that failing this test should flag a WARNING but not an ERROR. The model developer will become aware that the SPICE model could be improved. RULE: ----- Any VI point current should not exceed XX.X Amps when the voltage is within +-2.5V of operating range. 4) VERY FEW TRANSITION POINTS IN VI CURVE... REASON: ------- Perhaps a more important check (then #3) would test for a significant number of transition points at the elbow of a shunt curve or bend(s) within VI curves. This test could be applied to all VI curves (not just shunt) as a test to determine if the voltage step was small enough. RULE: ----- I believe this can be implemented as a comparison of some absolute maximum "delta ohms" to the second derivative at each point of each VI curve. Example Shunt Curve that FAILS test #4... +I | ----------*---*---*--*---*---*-- +V | | | * | | | * | | | Example Shunt Curve that PASSES test #4... +I | ----------********************* +V **** | ** | * | ** | * | ** | * | ** | * | --------------------------------------------------------------------------- From owner-ibis Thu Feb 22 16:11:44 1996 Received: from ormail.intel.com (ormail.intel.com [134.134.192.3]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id QAA24486; Thu, 22 Feb 1996 16:11:42 -0800 (PST) Received: from relay.jf.intel.com (relay.jf.intel.com [134.134.131.6]) by ormail.intel.com (8.6.12/8.6.12) with SMTP id QAA03970; Thu, 22 Feb 1996 16:03:14 -0800 Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.29.1 #4) id m0tpkyb-000Hz1C; Thu, 22 Feb 96 16:03 PST Received: by ccm.hf.intel.com (ccmgate 3.2 #6) Thu, 22 Feb 96 16:03:09 PST Date: Thu, 22 Feb 96 15:56:00 PST From: Arpad Muranyi Message-ID: To: owner-ibis@vhdl.org, ibis@vhdl.org cc: crokusek@qdt.com Subject: Re: EGG10 - Proposed Automatic Validation Checks Text item: Stephen, Sounds like a good idea, but what do you do if the value is expressed in the base unit? This might happen often with the resistance values, or if one uses engineering or scientific notation. Arpad ============================================================================== Hello Chris, and Fellow IBISans: Reading Chris's EEG 10 got me thinking about another test I would like to see added to this golden parser EGG. How about a 'units' check? I would like to see a warning if the values listed with [C_comp], [Package], R_pin, L_pin, C_pin, [Ramp] and the waveform fixture variables do not have a suffix attached. For example, if a model maker entered '5' instead of '5p' as the value of C_comp, the golden parser would flag it with a warning. I have seen this error several times, especially with the ramp rate number (leaving the 'n' off the Dt portion of the ratio). Regards, Stephen Peters Intel Corp. =------------------------------------ Fellow IBISians, Here is EGG10 proposing 4 "automatic" checks that could be built into the ibis checker to prevent some common model building pitfalls at build time rather than at simulation time after the model has been distributed. Any feedback is greatly appreciated! -Chris Rokusek Quad Design ------------------------------------------------------------------- EGG10 - PROPOSED AUTOMATIC VALIDATION CHECKS FOR IBIS_CHK. ------------------------------------------------------------------- Items #1 and #2 are aimed toward checking that an IBIS file was built correctly and prevent common mistakes like getting spice output files overwritten, names mangled, and current/voltage polarity reversed. Items #3 and #4 attempt to verify that the data contained within the IBIS file is generally useful for SI simulation. 1) CURRENT DIRECTION REVERSED OVER 50% OF POINTS IN TABLE. REASON: ------- Simple protection against wrong current polarity. RULE: ----- (increase = more positive or less negative): For [Pulldown] and [GND Clamp] tables: As Voltage increases, Current should increase. For [Pullup] and [POWER Clamp] tables: As Voltage increases, Current should decrease. 2) WAVEFORM "DC" POINTS DO NOT MATCH VI CURVE FOR SPECIFIED LOAD. REASON: ------- To insure that the Voltage/Time waveforms match the specified test load. To insure that the min/typ/max VT table corresponds to the min/typ/max VI table RULE: ----- This check would look at the beginning and ending voltages of a VT Waveform which indicate DC settling points and compare each of these voltages to the given DC VI curves using the load specified for the waveform data. For example, given... [Rising Waveform] R_fixture = 50 V_fixture = 2.5 C_fixture = 50.0pF /* not important for this test */ ...and a waveform like... +V | | | 4.2V | ******** | **** | | * | | first point * | | | * | 2.5V | | * | | | * last point | V * | * 0.5V | ********** | | ------------------------------------- +Time Can use the first point (see above) at 0.5V to check against the low VI curve (see below)... +I | Low State VI Curve | | | V | x LLLLLLLLLLLLLLLLLLLL | x LLLLLLL | x LLL | xLL | LLvx | L v x | L v x | L v x | L v x |L v x <--- slope = -50.0 = R_fixture |L v x L v x _------ Voltage = V_fixture L v x / ----L-------v---------x---------------------- +V L| | | | L 0.0V ?=? 2.5V 5.0V 0.5V? The load line "xxxx" should intersect the low state VI curve "LLLL" at ~= 0.5V indicated by the first point of the [Rising Waveform]. Similarly, the High VI curve can be correlated to the last point of the Rising Waveform. This should be repeated for all waveforms. ** Note that this check requires LOW curve = [PullDown] + [GND_Clamp]. 3) EXTREME CURRENTS IN VI CURVE...(Generally found shunt curves) REASON: ------- Many SPICE models are tested against data-book performance parameters designed to be used within the normal operating range of the device and are and not meant for simulation outside of that operating range into the protection range. However, for accurate SI simulation, it becomes important to have a well-defined protection range. Even if a model would fail this test, it still may be usable for SI simulation implying that failing this test should flag a WARNING but not an ERROR. The model developer will become aware that the SPICE model could be improved. RULE: ----- Any VI point current should not exceed XX.X Amps when the voltage is within +-2.5V of operating range. 4) VERY FEW TRANSITION POINTS IN VI CURVE... REASON: ------- Perhaps a more important check (then #3) would test for a significant number of transition points at the elbow of a shunt curve or bend(s) within VI curves. This test could be applied to all VI curves (not just shunt) as a test to determine if the voltage step was small enough. RULE: ----- I believe this can be implemented as a comparison of some absolute maximum "delta ohms" to the second derivative at each point of each VI curve. Example Shunt Curve that FAILS test #4... +I | ----------*---*---*--*---*---*-- +V | | | * | | | * | | | Example Shunt Curve that PASSES test #4... +I | ----------********************* +V **** | ** | * | ** | * | ** | * | ** | * | --------------------------------------------------------------------------- Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. From: Stephen Peters Date: Thu, 22 Feb 1996 08:31:09 -0800 Subject: EGG10 - Proposed Automatic Validation Checks Cc: crokusek@qdt.com To: ibis@vhdl.org Message-Id: <9602221631.AA26484@xtg801> Received: from localhost by xtg801 (4.1/10.0i); Thu, 22 Feb 96 08:31:10 PST Received: from xtg801 by ichips.intel.com (8.7.1/jIII); Thu, 22 Feb 1996 08:31:1 1 -0800 (PST) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.in tel.com (8.6.12/8.6.12) with ESMTP id IAA29510; Thu, 22 Feb 1996 08:31:14 -0800 Received: from ormail.intel.com (ormail.intel.com [134.134.192.3]) by vhdl.vhdl. org (8.7.3/8.7.3) with SMTP id IAA21261 for ; Thu, 22 Feb 1996 08 :39:41 -0800 (PST) Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by ormail.intel.com ( 8.6.12/8.6.12) with ESMTP id IAA00827; Thu, 22 Feb 1996 08:39:11 -0800 Received: from ormail.intel.com by relay.jf.intel.com with smtp (Smail3.1.29.1 #4) id m0tpe33-000I82C; Thu, 22 Feb 96 08:39 PST From owner-ibis Fri Feb 23 08:37:09 1996 Received: from ormail.intel.com (ormail.intel.com [134.134.192.3]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id IAA08891 for ; Fri, 23 Feb 1996 08:37:06 -0800 (PST) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.intel.com (8.6.12/8.6.12) with ESMTP id IAA09832; Fri, 23 Feb 1996 08:28:32 -0800 Received: from xtg801 by ichips.intel.com (8.7.1/jIII); Fri, 23 Feb 1996 08:28:29 -0800 (PST) Received: from localhost by xtg801 (4.1/10.0i); Fri, 23 Feb 96 08:28:28 PST Message-Id: <9602231628.AA00989@xtg801> To: ibis@vhdl.org Cc: crokusek@qdt.com Subject: Re: EGG10 - Proposed Automatic Validation Checks Date: Fri, 23 Feb 1996 08:28:27 -0800 From: Stephen Peters Hello Arpad: Mmmmm.....that's OK if a resistance is expressed as '0.2' instead of '200m' - it just results in an additional warning message. We could handle scientific notation by simply checking the exponent value, but the real point of this bird is to detect the missing suffix (the most common error). Thanks for your comments! Regards, Stephen Text item: Stephen, Sounds like a good idea, but what do you do if the value is expressed in the base unit? This might happen often with the resistance values, or if one uses engineering or scientific notation. Arpad ============================================================================== Hello Chris, and Fellow IBISans: Reading Chris's EEG 10 got me thinking about another test I would like to see added to this golden parser EGG. How about a 'units' check? I would like to see a warning if the values listed with [C_comp], [Package], R_pin, L_pin, C_pin, [Ramp] and the waveform fixture variables do not have a suffix attached. For example, if a model maker entered '5' instead of '5p' as the value of C_comp, the golden parser would flag it with a warning. I have seen this error several times, especially with the ramp rate number (leaving the 'n' off the Dt portion of the ratio). Regards, Stephen Peters Intel Corp. =------------------------------------ Fellow IBISians, Here is EGG10 proposing 4 "automatic" checks that could be built into the ibis checker to prevent some common model building pitfalls at build time rather than at simulation time after the model has been distributed. Any feedback is greatly appreciated! -Chris Rokusek Quad Design ------------------------------------------------------------------- EGG10 - PROPOSED AUTOMATIC VALIDATION CHECKS FOR IBIS_CHK. ------------------------------------------------------------------- Items #1 and #2 are aimed toward checking that an IBIS file was built correctly and prevent common mistakes like getting spice output files overwritten, names mangled, and current/voltage polarity reversed. Items #3 and #4 attempt to verify that the data contained within the IBIS file is generally useful for SI simulation. 1) CURRENT DIRECTION REVERSED OVER 50% OF POINTS IN TABLE. REASON: ------- Simple protection against wrong current polarity. RULE: ----- (increase = more positive or less negative): For [Pulldown] and [GND Clamp] tables: As Voltage increases, Current should increase. For [Pullup] and [POWER Clamp] tables: As Voltage increases, Current should decrease. 2) WAVEFORM "DC" POINTS DO NOT MATCH VI CURVE FOR SPECIFIED LOAD. REASON: ------- To insure that the Voltage/Time waveforms match the specified test load. To insure that the min/typ/max VT table corresponds to the min/typ/max VI table RULE: ----- This check would look at the beginning and ending voltages of a VT Waveform which indicate DC settling points and compare each of these voltages to the given DC VI curves using the load specified for the waveform data. For example, given... [Rising Waveform] R_fixture = 50 V_fixture = 2.5 C_fixture = 50.0pF /* not important for this test */ ...and a waveform like... +V | | | 4.2V | ******** | **** | | * | | first point * | | | * | 2.5V | | * | | | * last point | V * | * 0.5V | ********** | | ------------------------------------- +Time Can use the first point (see above) at 0.5V to check against the low VI curve (see below)... +I | Low State VI Curve | | | V | x LLLLLLLLLLLLLLLLLLLL | x LLLLLLL | x LLL | xLL | LLvx | L v x | L v x | L v x | L v x |L v x <--- slope = -50.0 = R_fixture |L v x L v x _------ Voltage = V_fixture L v x / ----L-------v---------x---------------------- +V L| | | | L 0.0V ?=? 2.5V 5.0V 0.5V? The load line "xxxx" should intersect the low state VI curve "LLLL" at ~= 0.5V indicated by the first point of the [Rising Waveform]. Similarly, the High VI curve can be correlated to the last point of the Rising Waveform. This should be repeated for all waveforms. ** Note that this check requires LOW curve = [PullDown] + [GND_Clamp]. 3) EXTREME CURRENTS IN VI CURVE...(Generally found shunt curves) REASON: ------- Many SPICE models are tested against data-book performance parameters designed to be used within the normal operating range of the device and are and not meant for simulation outside of that operating range into the protection range. However, for accurate SI simulation, it becomes important to have a well-defined protection range. Even if a model would fail this test, it still may be usable for SI simulation implying that failing this test should flag a WARNING but not an ERROR. The model developer will become aware that the SPICE model could be improved. RULE: ----- Any VI point current should not exceed XX.X Amps when the voltage is within +-2.5V of operating range. 4) VERY FEW TRANSITION POINTS IN VI CURVE... REASON: ------- Perhaps a more important check (then #3) would test for a significant number of transition points at the elbow of a shunt curve or bend(s) within VI curves. This test could be applied to all VI curves (not just shunt) as a test to determine if the voltage step was small enough. RULE: ----- I believe this can be implemented as a comparison of some absolute maximum "delta ohms" to the second derivative at each point of each VI curve. Example Shunt Curve that FAILS test #4... +I | ----------*---*---*--*---*---*-- +V | | | * | | | * | | | Example Shunt Curve that PASSES test #4... +I | ----------********************* +V **** | ** | * | ** | * | ** | * | ** | * | --------------------------------------------------------------------------- Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. From: Stephen Peters Date: Thu, 22 Feb 1996 08:31:09 -0800 Subject: EGG10 - Proposed Automatic Validation Checks Cc: crokusek@qdt.com To: ibis@vhdl.org Message-Id: <9602221631.AA26484@xtg801> Received: from localhost by xtg801 (4.1/10.0i); Thu, 22 Feb 96 08:31:10 PST Received: from xtg801 by ichips.intel.com (8.7.1/jIII); Thu, 22 Feb 1996 08:31:1 1 -0800 (PST) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by ormail.in tel.com (8.6.12/8.6.12) with ESMTP id IAA29510; Thu, 22 Feb 1996 08:31:14 -0800 Received: from ormail.intel.com (ormail.intel.com [134.134.192.3]) by vhdl.vhdl. org (8.7.3/8.7.3) with SMTP id IAA21261 for ; Thu, 22 Feb 1996 08 :39:41 -0800 (PST) Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by ormail.intel.com ( 8.6.12/8.6.12) with ESMTP id IAA00827; Thu, 22 Feb 1996 08:39:11 -0800 Received: from ormail.intel.com by relay.jf.intel.com with smtp (Smail3.1.29.1 #4) id m0tpe33-000I82C; Thu, 22 Feb 96 08:39 PST From owner-ibis Fri Feb 23 09:47:45 1996 Received: from icx.com (icx.rain.com [204.119.8.12]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id JAA09344 for ; Fri, 23 Feb 1996 09:47:37 -0800 (PST) Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 23 Feb 96 09:37 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 23 Feb 96 09:40 PST Message-Id: Date: Fri, 23 Feb 96 09:40 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org, speters@ichips.intel.com Subject: Re: EGG10 - Proposed Automatic Validation Checks Hello Stephen: The ibischk2 parser already does some numerical checking of some table end-points values and correctly handles numbers/units/scientific notation combinations. For example, .5, 500m, 500e3u, and 500e-3 are all correctly interpreted as .5 So the warning tests should be on actual selected numerical values, not on the format. Bob Ross Interconnectix, Inc. > To: ibis@vhdl.org > Cc: crokusek@qdt.com > Subject: Re: EGG10 - Proposed Automatic Validation Checks > Date: Fri, 23 Feb 1996 08:28:27 -0800 > From: Stephen Peters > Status: R > Hello Arpad: > Mmmmm.....that's OK if a resistance is expressed as '0.2' instead > of '200m' - it just results in an additional warning message. We could > handle scientific notation by simply checking the exponent value, but > the real point of this bird is to detect the missing suffix (the most > common error). > Thanks for your comments! > Regards, > Stephen > Text item: > Stephen, > Sounds like a good idea, but what do you do if the value is expressed in the > base unit? This might happen often with the resistance values, or if one uses > engineering or scientific notation. > Arpad > ============================================================================== > Hello Chris, and Fellow IBISans: > Reading Chris's EEG 10 got me thinking about another test > I would like to see added to this golden parser EGG. How about a 'units' > check? I would like to see a warning if the values listed with > [C_comp], [Package], R_pin, L_pin, C_pin, [Ramp] and the waveform > fixture variables do not have a suffix attached. For example, if > a model maker entered '5' instead of '5p' as the value of C_comp, > the golden parser would flag it with a warning. I have seen this > error several times, especially with the ramp rate number (leaving > the 'n' off the Dt portion of the ratio). > Regards, > Stephen Peters > Intel Corp. From owner-ibis Mon Feb 26 15:29:42 1996 Received: from sass165.sandia.gov (sass165.sandia.gov [132.175.109.1]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id PAA15733 for ; Mon, 26 Feb 1996 15:29:39 -0800 (PST) Received: from sass191.ess.sandia.gov (sass191.csu891.sandia.gov [134.253.21.54]) by sass165.sandia.gov (8.6.12/8.6.12) with SMTP id QAA27862; Mon, 26 Feb 1996 16:21:50 -0700 Received: from sass1365.sandia.gov by sass191.ess.sandia.gov (4.1/SMI-4.1) id AA04905; Mon, 26 Feb 96 16:23:13 MST Date: Mon, 26 Feb 96 16:23:13 MST From: gdpeter@sandia.gov (Gary Peterson) Message-Id: <9602262323.AA04905@sass191.ess.sandia.gov> To: si-list@silab.Eng.Sun.COM, ibis@vhdl.org Subject: Wanted...PCI bus 3V driver/receiver models I am trying to get a feel for how one might mix 3-volt level signaling and 5-volt level signaling PCI bus driver/receivers on a common PCI bus. I have IBIS models for 5-volt level signaling driver/receivers from the IBIS library courtesy of Intel. I would like to get models that are 3-volt level signaling and "5-volt compliant" (I think this just means no VCC clamping diode so the parts can be used with 5-volt supply) and models that are 3-volt level signaling ONLY (cannot be used with 5-volt supply because they have proction diodes?). I am modeling the behavior of a specific PCI bus design using Quad XTK. We will run at 25MHz instead of 33MHz so have more than 10ns for data to settle. IBIS models are preferred as they require less trouble on my part to translate into useable Quad models (I'm one of those u-s-e-r-s who wants models that plug-and-play without any effort on my part...ha). I can use Hspice models, if that's all that is available, and will establish non-disclosure agreements as necessary to get them. Thanks to any and all who are willing to help. P.S. I'm placing an order with ZEELAN ASAP in order to get as many plug-and-play models as I can afford. I've finally bit the bullet and decided I'll have to pay time and $ to get the models I need. Gary P. --- Gary D. Peterson _/_/_/ _/ _/ _/ SANDIA NATIONAL LABORATORIES _/_/_/ _/ _/_/ _/ _/ P.O. Box 5800, M/S 0503 _/_/ _/_/_/ _/ _/ _/ _/ Albuquerque, NM 87185-0503 _/_/_/_/_/_/ _/ _/ _/_/ _/ Phone: (505)844-6980 _/ _/_/ _/ _/_/_/ _/ _/ _/_/_/_/ FAX: (505)844-2925 _/ _/_/ _/ E-Mail: gdpeter@sandia.gov _/_/_/ From owner-ibis Mon Feb 26 15:54:56 1996 Received: from gate.ti.com (news.ti.com [192.94.94.33]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id PAA15943 for ; Mon, 26 Feb 1996 15:54:52 -0800 (PST) Received: from kadet.asic.sc.ti.com ([156.117.182.198]) by gate.ti.com (8.6.13/) with ESMTP id RAA27346; Mon, 26 Feb 1996 17:45:42 -0600 Received: from sho.asic.sc.ti.com (sho.asic.sc.ti.com [156.117.182.238]) by kadet.asic.sc.ti.com (8.6.10/8.6.6) with ESMTP id RAA19968; Mon, 26 Feb 1996 17:43:59 -0600 Received: from localhost (andresen@localhost) by sho.asic.sc.ti.com (8.6.4/8.6.4) id RAA27260; Mon, 26 Feb 1996 17:43:41 -0600 Date: Mon, 26 Feb 1996 17:43:41 -0600 From: Ben Andresen Message-Id: <199602262343.RAA27260@sho.asic.sc.ti.com> To: si-list@silab.Eng.Sun.COM, ibis@vhdl.org, gdpeter@sandia.gov Subject: Re: Wanted...PCI bus 3V driver/receiver models Gary, what you are requesting is in violation of PCI protocol. There can only be one signaling level on a PCI bus. A universal PCI interface will have macros that work in either 3V or 5V signaling environments, but they need to meet all the 3V signaling specs when the PCI voltage is connected to 3V and all the 5V specs when the PCI bus is connected to 5V. This includes clamping inputs to the 3V rail in the 3V signaling environment. Anything else is non- compliant to PCI spec. FYI, Texas Instruments has several ASIC product lines containing universal PCI inputs and outputs which ARE fully PCI compliant in both 3V and 5V environments. If you are interested I can have our marketing department send you additional information. Regards, Ben Andresen andresen@asic.sc.ti.com > From owner-ibis@vhdl.vhdl.org Mon Feb 26 17:27:12 1996 > To: si-list@silab.Eng.Sun.COM, ibis@vhdl.org > Subject: Wanted...PCI bus 3V driver/receiver models > > I am trying to get a feel for how one might mix 3-volt level signaling and > 5-volt level signaling PCI bus driver/receivers on a common PCI bus. I have > IBIS models for 5-volt level signaling driver/receivers from the IBIS > library courtesy of Intel. I would like to get models that are 3-volt level > signaling and "5-volt compliant" (I think this just means no VCC clamping > diode so the parts can be used with 5-volt supply) and models that are > 3-volt level signaling ONLY (cannot be used with 5-volt supply because they > have proction diodes?). > > I am modeling the behavior of a specific PCI bus design using Quad XTK. We > will run at 25MHz instead of 33MHz so have more than 10ns for data to settle. > IBIS models are preferred as they require less trouble on my part to translate > into useable Quad models (I'm one of those u-s-e-r-s who wants models that > plug-and-play without any effort on my part...ha). I can use Hspice models, > if that's all that is available, and will establish non-disclosure agreements > as necessary to get them. Thanks to any and all who are willing to help. > > P.S. I'm placing an order with ZEELAN ASAP in order to get as many > plug-and-play models as I can afford. I've finally bit the bullet > and decided I'll have to pay time and $ to get the models I need. > > Gary P. > --- > Gary D. Peterson > _/_/_/ _/ _/ _/ SANDIA NATIONAL LABORATORIES _/_/_/ > _/ _/_/ _/ _/ P.O. Box 5800, M/S 0503 _/_/ > _/_/_/ _/ _/ _/ _/ Albuquerque, NM 87185-0503 _/_/_/_/_/_/ > _/ _/ _/_/ _/ Phone: (505)844-6980 _/ _/_/ _/ > _/_/_/ _/ _/ _/_/_/_/ FAX: (505)844-2925 _/ _/_/ _/ > E-Mail: gdpeter@sandia.gov _/_/_/ > > > From owner-ibis Mon Feb 26 16:24:31 1996 Received: from ormail.intel.com (ormail.intel.com [134.134.192.3]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id QAA16148 for ; Mon, 26 Feb 1996 16:24:31 -0800 (PST) Received: from relay.jf.intel.com (relay.jf.intel.com [134.134.131.6]) by ormail.intel.com (8.6.12/8.6.12) with SMTP id QAA20294 for ; Mon, 26 Feb 1996 16:16:02 -0800 Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.29.1 #4) id m0trD5G-000Hz7C; Mon, 26 Feb 96 16:16 PST Received: by ccm.hf.intel.com (ccmgate 3.2 #6) Mon, 26 Feb 96 16:16:02 PST Date: Mon, 26 Feb 96 16:05:00 PST From: Arpad Muranyi Message-ID: To: ibis@vhdl.org Subject: Re: Wanted...PCI bus 3V driver/receiver models Text item: Gary, Many of the Intel chipset IBIS models have 5V safe 3.3V PCI buffers. One example is the 82437VX. To obtain some these IBIS models you might need to arrange an NDA agreement, but they are available. Arpad Muranyi Intel Corporation ============================================================================ I am trying to get a feel for how one might mix 3-volt level signaling and 5-volt level signaling PCI bus driver/receivers on a common PCI bus. I have IBIS models for 5-volt level signaling driver/receivers from the IBIS library courtesy of Intel. I would like to get models that are 3-volt level signaling and "5-volt compliant" (I think this just means no VCC clamping diode so the parts can be used with 5-volt supply) and models that are 3-volt level signaling ONLY (cannot be used with 5-volt supply because they have proction diodes?). I am modeling the behavior of a specific PCI bus design using Quad XTK. We will run at 25MHz instead of 33MHz so have more than 10ns for data to settle. IBIS models are preferred as they require less trouble on my part to translate into useable Quad models (I'm one of those u-s-e-r-s who wants models that plug-and-play without any effort on my part...ha). I can use Hspice models, if that's all that is available, and will establish non-disclosure agreements as necessary to get them. Thanks to any and all who are willing to help. P.S. I'm placing an order with ZEELAN ASAP in order to get as many plug-and-play models as I can afford. I've finally bit the bullet and decided I'll have to pay time and $ to get the models I need. Gary P. --- Gary D. Peterson _/_/_/ _/ _/ _/ SANDIA NATIONAL LABORATORIES _/_/_/ _/ _/_/ _/ _/ P.O. Box 5800, M/S 0503 _/_/ _/_/_/ _/ _/ _/ _/ Albuquerque, NM 87185-0503 _/_/_/_/_/_/ _/ _/ _/_/ _/ Phone: (505)844-6980 _/ _/_/ _/ _/_/_/ _/ _/ _/_/_/_/ FAX: (505)844-2925 _/ _/_/ _/ E-Mail: gdpeter@sandia.gov _/_/_/ Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: Wanted...PCI bus 3V driver/receiver models To: si-list@silab.Eng.Sun.COM, ibis@vhdl.org Message-Id: <9602262323.AA04905@sass191.ess.sandia.gov> From: gdpeter@sandia.gov (Gary Peterson) Date: Mon, 26 Feb 96 16:23:13 MST Received: from sass1365.sandia.gov by sass191.ess.sandia.gov (4.1/SMI-4.1) id AA04905; Mon, 26 Feb 96 16:23:13 MST Received: from sass191.ess.sandia.gov (sass191.csu891.sandia.gov [134.253.21.54] ) by sass165.sandia.gov (8.6.12/8.6.12) with SMTP id QAA27862; Mon, 26 Feb 1996 16:21:50 -0700 Received: from sass165.sandia.gov (sass165.sandia.gov [132.175.109.1]) by vhdl.v hdl.org (8.7.3/8.7.3) with SMTP id PAA15733 for ; Mon, 26 Feb 199 6 15:29:39 -0800 (PST) Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by ormail.intel.com ( 8.6.12/8.6.12) with ESMTP id PAA14217; Mon, 26 Feb 1996 15:31:03 -0800 Received: from ormail.intel.com by relay.jf.intel.com with smtp (Smail3.1.29.1 #4) id m0trCNk-000HzEC; Mon, 26 Feb 96 15:31 PST From owner-ibis Mon Feb 26 19:20:59 1996 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id TAA17353 for ; Mon, 26 Feb 1996 19:20:58 -0800 (PST) Received: from us1rmc.bb.dec.com by mail11.digital.com (5.65v3.2/1.0/WV) id AA17107; Mon, 26 Feb 1996 22:03:05 -0500 Received: from wrksys.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94) id AA09923; Mon, 26 Feb 96 22:01:12 -0500 Message-Id: <9602270301.AA09923@us1rmc.bb.dec.com> Received: from wrksys.enet; by us1rmc.enet; Mon, 26 Feb 96 22:03:34 EST Date: Mon, 26 Feb 96 22:03:34 EST From: Andy Ingraham To: gdpeter@sandia.gov, si-list@silab.eng.sun.com, ibis@vhdl.org Cc: ingraham@wrksys.ENET.dec.com Apparently-To: ibis@vhdl.org, si-list@silab.eng.sun.com, gdpeter@sandia.gov Subject: Re: Wanted...PCI bus 3V driver/receiver models > I am trying to get a feel for how one might mix 3-volt level signaling and > 5-volt level signaling PCI bus driver/receivers on a common PCI bus. Perhaps you didn't mean to say "signaling"? 3-volt signaling and 5-volt signaling -- as in sections 4.2.1 and 4.2.2 of the PCI spec -- are mutually exclusive environments that can never mix. (Like mixing TTL and ECL.) What you can do, however, is use a device that is powered by 3.3V, and outputs 0/3-volt output levels, on a PCI bus designated as a 5V signaling environment. This is what you referred to as "3-volt level signaling and '5-volt compliant.'" This arrangement is permitted because the output voltage specs of the 5V signaling environment are wide enough to encompass what you might call 3V switching levels, even though they are indeed "5V signaling environment" PCI levels. And by the way, the output levels of these 3.3V-powered, 5V signaling devices is rather similar to good old TTL, which, despite having 5V power, might drive only as high as 2.4V in the high state. The 5V PCI switching levels are essentially TTL levels. There are other differences besides the lack of clamping diodes that differentiate 3.3V signaling devices from 5V signaling devices, but that is one of the biggies. Regards, Andy From owner-ibis Tue Feb 27 01:34:30 1996 Received: from ds9.Dortmund.loca.net (bin@ds9.Dortmund.loca.net [194.39.202.133]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id BAA19968 for ; Tue, 27 Feb 1996 01:34:28 -0800 (PST) From: olaf@pad.incases.com Received: (from bin@localhost) by ds9.Dortmund.loca.net (8.6.12/8.6.12) id KAA29748 for ; Tue, 27 Feb 1996 10:25:56 +0100 Received: from isdn.pad.incases.com(194.64.13.226) by ds9.Dortmund.loca.net via smap (V1.3) id sma029733; Tue Feb 27 10:24:42 1996 Received: from pluto.incases.com by mail.pad.incases.com with smtp (Smail3.1.28.1 #3) id m0trLdl-00044yC; Tue, 27 Feb 96 10:24 MET Received: by pluto.incases.com (4.1) id AA01518; Tue, 27 Feb 96 10:23:58 +0100 Message-Id: <9602270923.AA01518@pluto.incases.com> Subject: SULTAN To: ibis@vhdl.org Date: Tue, 27 Feb 1996 10:23:58 +0100 (MET) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Hello IBISIANS As I mentioned in the last telephone conference we would like to make an alternative suggestion for egg 8. I propose to investigate the description format SULTAN which was developed in a European reseach project called JESSI AC5. This project is on EMC related issues for systems and PCBs and several mayor European companies like Philips, Siemens, BULL Computers, Matra Aerospace etc. participated in this project. The SULTAN format aims at a neutral description of PCB data that gives sufficient information for emc analysis. I agree with Kellee that there is no real standard available in this area which is easy to use and contains enough information for the analysis. As SULTAN is already used in the project mentioned above it has shown its applicability for this purpose. I see the following advantages of using SULTAN: - Context free grammar * simple parser generation - Well structured scopes for * PCBs * Components * Parts * etc. - Based on primitive graphical elements (PGE) * easy to expand for new elements - Multiple PCBs possible - SULTAN has already shown its applicability in various projects To give you a complete overview on SULTAN I put the SULTAN description in postscript format on our ftp server (ftp.pad.incases.com) and I would ask everybody to download the document. You will find the document in the directory 'transfer/SULTAN'. The postscript file is gziped and is named 'sultan.ps.gz'. I did not attach it in this mail as it is too large! Looking forward for your feedback on the reflector, Olaf -- ------------------------------------------------------------------------------- INCASES Engineering GmbH * Vattmannstr. 3 * D-33100 Paderborn * Germany Olaf Rethmeier * Tel/Fax +49-5251-150-625/-700 * Email olaf@pad.incases.com ------------------------------------------------------------------------------- From owner-ibis Tue Feb 27 08:00:47 1996 Received: from spsem01.sps.mot.com (spsem01.sps.mot.com [192.70.231.4]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id IAA28762 for ; Tue, 27 Feb 1996 08:00:45 -0800 (PST) Received: from mogate (mogate.sps.mot.com) by spsem01.sps.mot.com (4.1/SMI-4.1/Email 2.1 10/25/93) id AA10974 for ibis@vhdl.org; Tue, 27 Feb 96 08:52:11 MST Received: from motsps by mogate (4.1/SMI-4.1/Email-2.0) id AA11722; Tue, 27 Feb 96 08:52:10 MST Received: from amcu-tx.sps.mot.com (sol-tx.sps.mot.com) by motsps (4.1/SMI-4.1/Email-2.1) id AA07785 for ibis@vhdl.org; Tue, 27 Feb 96 08:52:07 MST Received: from lobsang.sps.mot.com by amcu-tx.sps.mot.com (4.1/SMI-4.1) id AA14240; Tue, 27 Feb 96 09:52:09 CST Received: by lobsang.sps.mot.com (4.1/SMI-4.1) id AA05630; Tue, 27 Feb 96 09:51:44 CST Date: Tue, 27 Feb 96 09:51:44 CST From: artc@lobsang.sps.mot.com (Arthur Collard) Message-Id: <9602271551.AA05630@lobsang.sps.mot.com> To: gdpeter@sandia.gov, si-list@silab.Eng.Sun.COM, ibis@vhdl.org Subject: Re: Wanted...PCI bus 3V driver/receiver models Cc: ingraham@wrksys.enet.dec.com On Mon, 26 Feb 96 16:23:13 MST (Gary Peterson wrote: > > I am trying to get a feel for how one might mix 3-volt level signaling and > > 5-volt level signaling PCI bus driver/receivers on a common PCI bus. > On Mon, 26 Feb 96 22:03:34 EST Andy Ingraham wrote: > Perhaps you didn't mean to say "signaling"? 3-volt signaling and 5-volt > signaling -- as in sections 4.2.1 and 4.2.2 of the PCI spec -- are mutually > exclusive environments that can never mix. (Like mixing TTL and ECL.) > > What you can do, however, is use a device that is powered by 3.3V, and > outputs 0/3-volt output levels, on a PCI bus designated as a 5V > signaling environment. This is what you referred to as "3-volt level > signaling and '5-volt compliant.'" > > This arrangement is permitted because the output voltage specs of the > 5V signaling environment are wide enough to encompass what you might > call 3V switching levels, even though they are indeed "5V signaling > environment" PCI levels. > > And by the way, the output levels of these 3.3V-powered, 5V signaling > devices is rather similar to good old TTL, which, despite having 5V > power, might drive only as high as 2.4V in the high state. The 5V PCI > switching levels are essentially TTL levels. > > There are other differences besides the lack of clamping diodes that > differentiate 3.3V signaling devices from 5V signaling devices, but that > is one of the biggies. > The choice Andy proposes is one which I have been working with from a circuit rather than a model point of view. We have an automotive customer who desires reduced system operating power while reducing battery drain during key off. The MCU is powered by a nominal 3.3 volt supply and interfaces with other system chips powered by 5 volts. The IC technology for the MCU is CMOS which requires special attention to the pin I/O driver design. First supplying switching levels from .4 to 2.4 volts is not a big problem. The problem comes in when the I/O pin is configured as an input driven by a 5.5 volt source. The normal configuration of a CMOS P-channel device creates a foward bias parasitic diode from pin to the 3 volt IC rail (P-ch drain to backgate) which will raise the IC power current limited by the 5 volt external driving source. There are methods to protect from this but it comes with a cost (usually silicon area, complexity and degraded speed). Third, the problem gets worse for advanced CMOS technologies employing < 110 A gate oxide thickness. This implies g/d, g/s, and g/b breakdowns close to 5.5 volts. With the advanced technology we have to protect both N-ch pulldown and P-ch pullup from this breakdown (protect N-ch or P-ch - gate at Vss from drain at 5.5 volts). I have recently completed a design of one of these 3 volt - 5 volt friendly type I/O drivers and its not pretty but it works. Regards AC -------------------------------------------------------------------------- | M O T O R O L A - Advanced Microcontroller Division (AMCU) | | ------------------------------------------------------------------------ | | Art Collard Modular Circuit Design email: artc@amcu-tx.sps.mot.com| | ------------------------------------------------------------------------ | | Mail Drop: OE320 | | Motorola - Advanced Microcontroller Division | | 6501 William Cannon Drive West, Austin, Texas 78735-8598 | | Tel: (512)891-8651 Fax: (512)891-3348 Pager: (512)933-7333 pgr# 89-8651| -------------------------------------------------------------------------- From owner-ibis Wed Feb 28 13:27:58 1996 Received: from crl.dec.com (crl.dec.com [192.58.206.2]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id NAA16995 for ; Wed, 28 Feb 1996 13:27:57 -0800 (PST) From: chu@rock.enet.dec.com Received: by crl.dec.com; id AA22950; Wed, 28 Feb 96 16:13:54 -0500 Received: by easynet.crl.dec.com; id AA21645; Wed, 28 Feb 96 16:13:51 -0500 Message-Id: <9602282113.AA21645@easynet.crl.dec.com> Received: from rock.enet; by crl.enet; Wed, 28 Feb 96 16:13:52 EST Date: Wed, 28 Feb 96 16:13:52 EST To: gdpeter@sandia.gov Cc: chu@rock.enet.dec.com, ibis@vhdl.org Apparently-To: ibis@vhdl.org, gdpeter@sandia.gov Subject: RE:Wanted...PCI bus 3V driver/receiver models Gary: I believe your situation as pictured below 5V 3V | | | | ------ PCI bus ------ | 5V | --------------- | 3V | | chip| | chip| ------ ------ is perfectly valid under the rules of the PCI protocol provided no additional power is drawn from the 5V when it is driving the bus. FYI: Digital and others have been doing this successfully for years. I'll be glad to provide you with any infomation you may need for the success of your project. Jeff Chu Digital Equipment Corp. ====================================================== ====================================================== Date: 26-FEB-1996 18:55:05.73 From: CRL::"gdpeter@sandia.gov" "Gary Peterson" Subj: Wanted...PCI bus 3V driver/receiver models To: si-list@silab.Eng.Sun.COM, ibis@vhdl.org CC: I am trying to get a feel for how one might mix 3-volt level signaling and 5-volt level signaling PCI bus driver/receivers on a common PCI bus. I have IBIS models for 5-volt level signaling driver/receivers from the IBIS library courtesy of Intel. I would like to get models that are 3-volt level signaling and "5-volt compliant" (I think this just means no VCC clamping diode so the parts can be used with 5-volt supply) and models that are 3-volt level signaling ONLY (cannot be used with 5-volt supply because they have proction diodes?). I am modeling the behavior of a specific PCI bus design using Quad XTK. We will run at 25MHz instead of 33MHz so have more than 10ns for data to settle. IBIS models are preferred as they require less trouble on my part to translate into useable Quad models (I'm one of those u-s-e-r-s who wants models that plug-and-play without any effort on my part...ha). I can use Hspice models, if that's all that is available, and will establish non-disclosure agreements as necessary to get them. Thanks to any and all who are willing to help. P.S. I'm placing an order with ZEELAN ASAP in order to get as many plug-and-play models as I can afford. I've finally bit the bullet and decided I'll have to pay time and $ to get the models I need. Gary P. --- Gary D. Peterson _/_/_/ _/ _/ _/ SANDIA NATIONAL LABORATORIES _/_/_/ _/ _/_/ _/ _/ P.O. Box 5800, M/S 0503 _/_/ _/_/_/ _/ _/ _/ _/ Albuquerque, NM 87185-0503 _/_/_/_/_/_/ _/ _/ _/_/ _/ Phone: (505)844-6980 _/ _/_/ _/ _/_/_/ _/ _/ _/_/_/_/ FAX: (505)844-2925 _/ _/_/ _/ E-Mail: gdpeter@sandia.gov _/_/_/ % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: by easynet.crl.dec.com; id AA29668; Mon, 26 Feb 96 18:52:15 -0500 % Received: by crl.dec.com; id AA06904; Mon, 26 Feb 96 18:45:00 -0500 % Received: from sass165.sandia.gov (sass165.sandia.gov [132.175.109.1]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id PAA15733 for ; Mon, 26 Feb 1996 15:29:39 -0800 (PST) % Received: from sass191.ess.sandia.gov (sass191.csu891.sandia.gov [134.253.21.54]) by sass165.sandia.gov (8.6.12/8.6.12) with SMTP id QAA27862; Mon, 26 Feb 1996 16:21:50 -0700 % Received: from sass1365.sandia.gov by sass191.ess.sandia.gov (4.1/SMI-4.1)id AA04905; Mon, 26 Feb 96 16:23:13 MST % Date: Mon, 26 Feb 96 16:23:13 MST % From: gdpeter@sandia.gov (Gary Peterson) % Message-Id: <9602262323.AA04905@sass191.ess.sandia.gov> % To: si-list@silab.Eng.Sun.COM, ibis@vhdl.org % Subject: Wanted...PCI bus 3V driver/receiver models From owner-ibis Wed Feb 28 15:26:05 1996 Received: from ormail.intel.com (ormail.intel.com [134.134.192.3]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id PAA17809 for ; Wed, 28 Feb 1996 15:26:04 -0800 (PST) Received: from relay.hf.intel.com (relay.hf.intel.com [143.181.7.24]) by ormail.intel.com (8.6.12/8.6.12) with SMTP id PAA19526; Wed, 28 Feb 1996 15:16:08 -0800 Received: from ccm.hf.intel.com by relay.hf.intel.com (Smail3.1.28.1 #2) id m0trv3H-000qDoC; Wed, 28 Feb 96 15:12 PST Received: by ccm.hf.intel.com (ccmgate 3.2 #1) Wed, 28 Feb 96 15:12:55 PST Date: Wed, 28 Feb 96 15:02:00 PST From: Scott McMorrow Message-ID: To: artc@lobsang.sps.mot.com, gdpeter@sandia.gov, si-list@silab.Eng.Sun.COM, ibis@vhdl.org cc: ingraham@wrksys.enet.dec.com Subject: Re[2]: Wanted...PCI bus 3V driver/receiver models Text item: On Mon, 26 Feb 96 16:23:13 MST (Gary Peterson wrote: > > I am trying to get a feel for how one might mix 3-volt level signaling and > > 5-volt level signaling PCI bus driver/receivers on a common PCI bus. > On Mon, 26 Feb 96 22:03:34 EST Andy Ingraham wrote: > Perhaps you didn't mean to say "signaling"? 3-volt signaling and 5-volt > signaling -- as in sections 4.2.1 and 4.2.2 of the PCI spec -- are mutually > exclusive environments that can never mix. (Like mixing TTL and ECL.) > > What you can do, however, is use a device that is powered by 3.3V, and > outputs 0/3-volt output levels, on a PCI bus designated as a 5V > signaling environment. This is what you referred to as "3-volt level > signaling and '5-volt compliant.'" > > This arrangement is permitted because the output voltage specs of the > 5V signaling environment are wide enough to encompass what you might > call 3V switching levels, even though they are indeed "5V signaling > environment" PCI levels. > > And by the way, the output levels of these 3.3V-powered, 5V signaling > devices is rather similar to good old TTL, which, despite having 5V > power, might drive only as high as 2.4V in the high state. The 5V PCI > switching levels are essentially TTL levels. > > There are other differences besides the lack of clamping diodes that > differentiate 3.3V signaling devices from 5V signaling devices, but that > is one of the biggies. > In a 5 volt signaling environment with 3.3V voltage level devices, you may want to be careful about low to high switching of the 3.3 V devices on the bus. 5 volt devices will overshoot far enough to turn on the high clamp diodes, supressing the ringback component to reasonable levels. But with 3.3 volt drivers, all of the overshoot energy will ringback and can enter the threshold region of receivers on the PCI bus. With small geometry, fast devices, there can be an extreme amount of overshoot. --scott Scott McMorrow scottmc@teleport.com Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Cc: ingraham@wrksys.ENET.dec.com Subject: Re: Wanted...PCI bus 3V driver/receiver models To: gdpeter@sandia.gov, si-list@silab.Eng.Sun.COM, ibis@vhdl.org Message-Id: <9602271551.AA05630@lobsang.sps.mot.com> From: artc@lobsang.sps.mot.com (Arthur Collard) Date: Tue, 27 Feb 96 09:51:44 CST Received: by lobsang.sps.mot.com (4.1/SMI-4.1) id AA05630; Tue, 27 Feb 96 09:51:44 CST Received: from lobsang.sps.mot.com by amcu-tx.sps.mot.com (4.1/SMI-4.1) id AA14240; Tue, 27 Feb 96 09:52:09 CST Received: from amcu-tx.sps.mot.com (sol-tx.sps.mot.com) by motsps (4.1/SMI-4.1/E mail-2.1) id AA07785 for si-list@silab.Eng.Sun.COM; Tue, 27 Feb 96 08:52:07 MST Received: from motsps by mogate (4.1/SMI-4.1/Email-2.0) id AA11719; Tue, 27 Feb 96 08:52:09 MST Received: from mogate (mogate.sps.mot.com) by spsem01.sps.mot.com (4.1/SMI-4.1/E mail 2.1 10/25/93) id AA10973 for si-list@silab.Eng.Sun.COM; Tue, 27 Feb 96 08:52:11 MST Received: by mercury.Sun.COM (Sun.COM) id HAA01142; Tue, 27 Feb 1996 07:53:44 -0800 Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5. 3) id AA29238; Tue, 27 Feb 1996 16:34:33 -0800 Errors-To: si-admin@silab.Eng.Sun.COM Received: from Eng.Sun.COM (engmail1) by silab.Eng.Sun.COM (4.1/SMI-4.1) id AA02516; Tue, 27 Feb 96 16:35:02 PST Errors-To: si-admin@silab.Eng.Sun.COM Received: from silab.Eng.Sun.COM (silab-188.Eng.Sun.COM) by Eng.Sun.COM (5.x/SMI -5.3) id AA08551; Tue, 27 Feb 1996 16:36:24 -0800 Received: by mercury.Sun.COM (Sun.COM) id QAA00582; Tue, 27 Feb 1996 16:36:47 -0800 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by desiree.telepor t.com (8.6.12/8.6.9) with ESMTP id RAA03243 for ; Tue, 27 Feb 1996 17:13:07 -0800 Received: from desiree.teleport.com (desiree.teleport.com [192.108.254.21]) by o rmail.intel.com (8.6.12/8.6.12) with ESMTP id RAA13726 for ; Tue, 27 Feb 1996 17:16:18 -0800 Received: from ormail.intel.com by relay.hf.intel.com with smtp (Smail3.1.28.1 #2) id m0traV9-000qDOC; Tue, 27 Feb 96 17:16 PST From owner-ibis Wed Feb 28 15:47:36 1996 Received: from gate.ti.com (news.ti.com [192.94.94.33]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id PAA17946 for ; Wed, 28 Feb 1996 15:47:35 -0800 (PST) Received: from kadet.asic.sc.ti.com ([156.117.182.198]) by gate.ti.com (8.6.13/) with ESMTP id RAA16225; Wed, 28 Feb 1996 17:34:08 -0600 Received: from sho.asic.sc.ti.com (sho.asic.sc.ti.com [156.117.182.238]) by kadet.asic.sc.ti.com (8.6.10/8.6.6) with ESMTP id RAA19189; Wed, 28 Feb 1996 17:32:36 -0600 Received: from localhost (andresen@localhost) by sho.asic.sc.ti.com (8.6.4/8.6.4) id RAA04016; Wed, 28 Feb 1996 17:32:33 -0600 Date: Wed, 28 Feb 1996 17:32:33 -0600 From: Ben Andresen Message-Id: <199602282332.RAA04016@sho.asic.sc.ti.com> To: gdpeter@sandia.gov, chu@rock.enet.dec.com Subject: RE:Wanted...PCI bus 3V driver/receiver models Cc: ibis@vhdl.org, andresen@asic.sc.ti.com Jeff, I agree that 5V chips powered from 5V and 3V chips powered from 3V can both talk on a PCI bus, but it isn't as simple as you show it to be. The motherboard defines the signaling environment, EITHER 3V or 5V. All cards must meet the specs for that signaling environment, and the characteristics are different. The 3V signaling environment input thresholds are much tighter than for 5V so an input buffer conforming only to 5V specs will not be 3V PCI compliant. The output buffer V-I characteristics change between 3V and 5V operation. Also, there MUST be a Vcc clamp diode for 3V PCI (PCI Local Bus Spec Rev 2.1, section 4.2.2.2) which will cause outputs driving 5V rail to rail severe problems in a 3V signaling environment. Bottom line is you must use I/Os specifically designed for the signaling environment defined by the motherboard to be PCI compliant. You CAN'T arbitrarily mix 3V and 5V signaling components and expect it to work. This doesn't say anything about the supply voltages and technologies of the various components on the bus which can be almost anything. I'm talking only about the PCI signaling environment as defined by the motherboard. If the final signaling environment is undefined the solution is to use "universal" PCI I/O buffers. These sense the PCI signaling environment being used by measuring the PCI I/O designated power pin voltage, and adapt their characteristics to fit the appropriate specs. These CAN be used as without reservation as described in your msg below. Ben Andresen > From owner-ibis@vhdl.vhdl.org Wed Feb 28 15:23:37 1996 > To: gdpeter@sandia.gov > Cc: chu@rock.enet.dec.com, ibis@vhdl.org > Subject: RE:Wanted...PCI bus 3V driver/receiver models > > Gary: I believe your situation as pictured below > > 5V 3V > | | > | | > ------ PCI bus ------ > | 5V | --------------- | 3V | > | chip| | chip| > ------ ------ > > is perfectly valid under the rules of the PCI protocol provided no > additional power is drawn from the 5V when it is driving the bus. > > FYI: Digital and others have been doing this successfully for years. > I'll be glad to provide you with any infomation you may need for the > success of your project. > > Jeff Chu > Digital Equipment Corp. > ====================================================== > ====================================================== > Date: 26-FEB-1996 18:55:05.73 > From: CRL::"gdpeter@sandia.gov" "Gary Peterson" > Subj: Wanted...PCI bus 3V driver/receiver models > To: si-list@silab.Eng.Sun.COM, ibis@vhdl.org > CC: > I am trying to get a feel for how one might mix 3-volt level signaling > and > 5-volt level signaling PCI bus driver/receivers on a common PCI bus. I > have > IBIS models for 5-volt level signaling driver/receivers from the IBIS > library courtesy of Intel. I would like to get models that are 3-volt > level > signaling and "5-volt compliant" (I think this just means no VCC > clamping > diode so the parts can be used with 5-volt supply) and models that are > 3-volt level signaling ONLY (cannot be used with 5-volt supply because > they > have proction diodes?). > > I am modeling the behavior of a specific PCI bus design using Quad XTK. > We > will run at 25MHz instead of 33MHz so have more than 10ns for data to > settle. > IBIS models are preferred as they require less trouble on my part to > translate > into useable Quad models (I'm one of those u-s-e-r-s who wants models > that > plug-and-play without any effort on my part...ha). I can use Hspice > models, > if that's all that is available, and will establish non-disclosure > agreements > as necessary to get them. Thanks to any and all who are willing to > help. > > P.S. I'm placing an order with ZEELAN ASAP in order to get as many > plug-and-play models as I can afford. I've finally bit the bullet > and decided I'll have to pay time and $ to get the models I need. > > Gary P. > --- > Gary D. Peterson > _/_/_/ _/ _/ _/ SANDIA NATIONAL LABORATORIES _/_/_/ > _/ _/_/ _/ _/ P.O. Box 5800, M/S 0503 _/_/ > _/_/_/ _/ _/ _/ _/ Albuquerque, NM 87185-0503 > _/_/_/_/_/_/ > _/ _/ _/_/ _/ Phone: (505)844-6980 _/ _/_/ > _/ > _/_/_/ _/ _/ _/_/_/_/ FAX: (505)844-2925 _/ _/_/ _/ > E-Mail: gdpeter@sandia.gov _/_/_/ > > > > % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== > % Received: by easynet.crl.dec.com; id AA29668; Mon, 26 Feb 96 18:52:15 > -0500 > % Received: by crl.dec.com; id AA06904; Mon, 26 Feb 96 18:45:00 -0500 > % Received: from sass165.sandia.gov (sass165.sandia.gov [132.175.109.1]) > by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id PAA15733 for > ; Mon, 26 Feb 1996 15:29:39 -0800 (PST) > % Received: from sass191.ess.sandia.gov (sass191.csu891.sandia.gov > [134.253.21.54]) by sass165.sandia.gov (8.6.12/8.6.12) with SMTP id > QAA27862; Mon, 26 Feb 1996 16:21:50 -0700 > % Received: from sass1365.sandia.gov by sass191.ess.sandia.gov > (4.1/SMI-4.1)id AA04905; Mon, 26 Feb 96 16:23:13 MST > % Date: Mon, 26 Feb 96 16:23:13 MST > % From: gdpeter@sandia.gov (Gary Peterson) > % Message-Id: <9602262323.AA04905@sass191.ess.sandia.gov> > % To: si-list@silab.Eng.Sun.COM, ibis@vhdl.org > % Subject: Wanted...PCI bus 3V driver/receiver models > > > > From owner-ibis Wed Feb 28 18:46:26 1996 Received: from icx.com (icx.rain.com [204.119.8.12]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id SAA18939 for ; Wed, 28 Feb 1996 18:46:23 -0800 (PST) Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 28 Feb 96 18:37 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 28 Feb 96 18:40 PST Message-Id: Date: Wed, 28 Feb 96 18:40 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS ROSTER Update IBISians: The IBIS roster has been updated to reflect 1996 participation. It is on vhdl.org under /pub/ibis/roster and is available from the EIA/IBIS Home page. I am still waiting for a few more replys to complete the roster. So I expect some more updates. Please check that your listing is correct. Thanks for your inputs. Bob Ross Interconnectix, Inc. From owner-ibis Thu Feb 29 07:38:53 1996 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id HAA29860 for ; Thu, 29 Feb 1996 07:38:52 -0800 (PST) Received: from us1rmc.bb.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA01900; Thu, 29 Feb 1996 10:21:34 -0500 Received: from wrksys.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94) id AA21566; Thu, 29 Feb 96 10:11:54 -0500 Message-Id: <9602291511.AA21566@us1rmc.bb.dec.com> Received: from wrksys.enet; by us1rmc.enet; Thu, 29 Feb 96 10:22:07 EST Date: Thu, 29 Feb 96 10:22:08 EST From: Andy Ingraham To: si-list@silab.eng.sun.com, ibis@vhdl.org Cc: ingraham@wrksys.ENET.dec.com Apparently-To: ibis@vhdl.org, si-list@silab.eng.sun.com Subject: Re[n]: Wanted...PCI bus 3V driver/receiver models Scott McMorrow wrote: > In a 5 volt signaling environment with 3.3V voltage level devices, you may want > to be careful about low to high switching of the 3.3 V devices on the bus. 5 > volt devices will overshoot far enough to turn on the high clamp diodes, > supressing the ringback component to reasonable levels. But with 3.3 volt > drivers, all of the overshoot energy will ringback and can enter the threshold > region of receivers on the PCI bus. With small geometry, fast devices, there > can be an extreme amount of overshoot. This is indeed a very good point. It's quite true. You can get some rather long bus delays (settling times) which exceed the 10ns PCI spec. I'm glad others out there are recognizing this problem. Regards, Andy From owner-ibis Thu Feb 29 09:22:15 1996 Received: from netcomsv.netcom.com (uucp9.netcom.com [163.179.3.9]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id JAA00834 for ; Thu, 29 Feb 1996 09:22:15 -0800 (PST) Received: from contec.UUCP by netcomsv.netcom.com with UUCP (8.6.12/SMI-4.1) id JAA09103; Thu, 29 Feb 1996 09:05:10 -0800 Received: from contec13.contec.COM by contec.COM (4.1/SMI-4.1) id AA10191; Thu, 29 Feb 96 08:56:45 PST Received: by contec13.contec.COM (5.0/SMI-SVR4) id AA00449; Thu, 29 Feb 1996 08:55:53 +0800 Date: Thu, 29 Feb 1996 08:55:53 +0800 From: dileep@contec.contec.COM (Dileep Divekar) Message-Id: <9602291655.AA00449@contec13.contec.COM> To: ibis@vhdl.org Subject: Re: SULTAN Cc: dileep@contec.contec.COM X-Sun-Charset: US-ASCII After several tries, I am still unable to copy the file sultan.ps.gz. When I try to ftp to ftp.pad.incases.com, I get a message saying that there is no response from the server. Has anybody copied that file? If so, I would like to receive it by email, if possible. (dileep@contec.com) Thanks. Dileep Divekar From owner-ibis Thu Feb 29 10:11:33 1996 Received: from icx.com (icx.rain.com [204.119.8.12]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id KAA01216 for ; Thu, 29 Feb 1996 10:11:22 -0800 (PST) Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 29 Feb 96 10:00 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 29 Feb 96 10:03 PST Message-Id: Date: Thu, 29 Feb 96 10:03 PST From: bob@icx.com ( Bob Ross) To: dileep@contec.contec.COM, ibis@vhdl.org, olaf@pad.incases.com Subject: Re: SULTAN Olaf: I have had similar problems getting through to your site. Once I actually got ftp working, but it was very slow and it disconnected. Could you e-mail the compressed file to those who request it? Thanks, Bob Ross Interconnectix, Inc. > Date: Thu, 29 Feb 1996 08:55:53 +0800 > From: dileep@contec.contec.COM (Dileep Divekar) > To: ibis@vhdl.org > Subject: Re: SULTAN > Cc: dileep@contec.contec.COM > After several tries, I am still unable to copy the > file sultan.ps.gz. When I try to ftp to ftp.pad.incases.com, > I get a message saying that there is no response from > the server. > Has anybody copied that file? If so, I would like to > receive it by email, if possible. (dileep@contec.com) > Thanks. > Dileep Divekar From owner-ibis Thu Feb 29 11:17:04 1996 Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id LAA01677 for ; Thu, 29 Feb 1996 11:17:03 -0800 (PST) Received: from uucp3.UU.NET by relay5.UU.NET with SMTP id QQafay06425; Thu, 29 Feb 1996 14:07:29 -0500 (EST) Received: from qdt.UUCP by uucp3.UU.NET with UUCP/RMAIL ; Thu, 29 Feb 1996 14:08:23 -0500 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00814; Thu, 29 Feb 96 10:37:47 PST Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA03191; Thu, 29 Feb 96 10:37:47 PST Received: from uucp2.UU.NET by relay5.UU.NET with SMTP id QQafaw26495; Thu, 29 Feb 1996 13:32:50 -0500 (EST) Received: from qdt.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Thu, 29 Feb 1996 13:32:50 -0500 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00762; Thu, 29 Feb 96 10:29:40 PST Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA03135; Thu, 29 Feb 96 10:29:40 PST Date: Thu, 29 Feb 96 10:29:40 PST From: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell) Message-Id: <9602291829.AA03135@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA08666; Thu, 29 Feb 96 10:29:36 PST To: uunet!uunet!contec.contec.COM!dileep@uunet.uu.net Cc: uunet!uunet!vhdl.org!ibis@uunet.uu.net, uunet!uunet!contec.contec.COM!dileep@uunet.uu.net In-Reply-To: <9602291655.AA00449@contec13.contec.COM> (uunet!contec.contec.COM!dileep) Subject: Re: SULTAN I am also unable to contact this ftp site jon From owner-ibis Thu Feb 29 11:34:43 1996 Received: from maxwell.ansoft.com (maxwell.ansoft.com [192.149.1.1]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id LAA01798 for ; Thu, 29 Feb 1996 11:34:42 -0800 (PST) Received: from saturn.ansoft.com by maxwell.ansoft.com (4.1/SMI-4.1) id AA02551; Thu, 29 Feb 96 14:24:46 EST Received: by saturn.ansoft.com (4.1/SMI-4.1) id AA18911; Thu, 29 Feb 96 14:24:44 EST Message-Id: <9602291924.AA18911@saturn.ansoft.com> To: ibis@vhdl.org Subject: sultan.ps Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <18909.825621883.1@saturn.ansoft.com> Date: Thu, 29 Feb 1996 14:24:43 -0500 From: Eric Bracken If someone manages to get the file to North America, could they maybe put it up on the vhdl.org FTP site? --Eric __________________________________________________________________ ________ ________ __ ________ /\_______\ /\_______\ /\_\ /\_______\ J. Eric Bracken, Ph.D. / / ______// / ____ // / // / ______/ Ansoft Corporation / / /__\ / / /__\/ // / // / / Four Station Square, Suite 660 / / ____/ / / ___ _// / // / /___ Pittsburgh, PA 15219-1119 / / /____\ / / / \/ / / / // / /____\ (412) 261-3200 FAX (412) 471-9427 \/_______/ \/_/ \/_/ \/_/ \/_______/ bracken@ansoft.com http://www.ece.cmu.edu/afs/ece/usr/bracken/.home-page.html __________________________________________________________________ From owner-ibis Thu Feb 29 16:56:01 1996 Received: from absolut-zero.winternet.com (root@absolut-zero.winternet.com [198.174.169.4]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id QAA04476 for ; Thu, 29 Feb 1996 16:55:42 -0800 (PST) Received: from parka (bward@parka.winternet.com [198.174.169.9]) by absolut-zero.winternet.com (8.7.4/8.6.12) with ESMTP id SAA16401 for ; Thu, 29 Feb 1996 18:47:04 -0600 (CST) Received: (from bward@localhost) by parka (8.7.4/8.6.12) id SAA13701 for ibis@vhdl.org; Thu, 29 Feb 1996 18:47:03 -0600 (CST) Date: Thu, 29 Feb 1996 18:47:03 -0600 (CST) From: Bob Ward Posted-Date: Thu, 29 Feb 1996 18:47:03 -0600 (CST) Message-Id: <199603010047.SAA13701@parka> To: ibis@vhdl.org Subject: SULTAN All- I also have tried several times and from a variety of Internet connections to reach the server at incases. I get about 4K of the file and then get timed out and disconnected. Hmmmmm..... If anyone can get a copy of this spec, please upload it to vhdl.org so the general others can also get it. Sounds like a worthy thing to be aware of!! All the best, Bob Ward bward@winternet.com