From owner-ibis Fri Mar 1 16:47:46 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 QAA20374 for ; Fri, 1 Mar 1996 16:47:27 -0800 (PST) Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 1 Mar 96 13:39 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 1 Mar 96 16:41 PST Message-Id: Date: Fri, 1 Mar 96 16:41 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS MEETING AGENDA 3/8/96 IBIS Open Forum Meeting Agenda for 3/8/96 Bridge Number Reservation # Passcode (916) 356-9200 1-55736 5232597 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 Express-G comment - Progress on ANSI/EIA-656 Publication Rusher 8:25 Administrative and Project Discussions Roster Ross Web Project Update Huq Counter Models at Company Site Golden Parser 2.1 Status Ross/Powell Bugs 1-3 S2IBIS 2.1 Status Ross/Steer New Administrative Issues All 8:50 Review of Priorities for 1996 Hobbs, All 9:00 Technical Discussion BIRD33 - Physical Package Description Discussion Crisafulli (EGG8) SULTAN Alternaive Proposal for EGG8 Rethmeier BIRD31 - Connector Models Ross BIRD32 - Matrix Name Enhancement Proposal Kumar/Peters BIRD34 - Stored Charge Proposal Progress (EGG9) Ross/Powell EGG10 - PARSER TESTS 1-5 Rukusek/Peters New Technical Issues All 9:50 Wrap Up and Next Meetings Plans Hobbs 9:55 Sign Off From owner-ibis Mon Mar 4 10:45:05 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 KAA22958 for ; Mon, 4 Mar 1996 10:43:42 -0800 (PST) Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 4 Mar 96 10:34 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 4 Mar 96 10:37 PST Message-Id: Date: Mon, 4 Mar 96 10:37 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: BIRD34 - Stored Charge Effects To IBIS Members: One of my action items was to recast EGG9 into BIRD34 to deal with the topic of handling Stored Charge effects in Diodes. Because of stored charge, a clamping diode will not release instanteously from the clamped mode as predicted by IBIS models. There will be a delay while the diode is turning off. This creates a glitch which itself can propogate up and down a line. This glitch is significant enough that IBIS needs to include a way to model it. The major contributor to the effect is the TT parameter which produces a non-linear transit time capacitance when a diode is conducting. The proposal here is to add effective parameters defined by [TTgnd] and [TTpower] keywords to the [Model] keyword description. Bob Ross, Interconnectix, Inc. ****************************************************************************** ****************************************************************************** BIRD ID#: 34 ISSUE TITLE: Stored Charge Effects REQUESTER: Bob Ross, Interconnectix, Inc. DATE SUBMITTED: 3/5/96 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: The effect of transit time capacitances is not currently handled in the IBIS format, yet its effects are important for certain simulations. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: Two new keywords [TTgnd] and [TTpower] provide effective transit time parameters for modeling the ground clamp and the power clamp transit time capacitances independently. Approximation equations are included in the description. The additional keywords are described after the [Model] keyword as follows. |============================================================================== | Keywords: [TTgnd], [TTpower] | Required: No | Description: The data for these keywords enters the transist time parameters | to estimate the transit time capacitances for the [Gnd Clamp] | and [Power Clamp] tables. | Usage Rules: For each of these keywords, the three columns hold the transit | values corresponding to the typical, minimum and maximum | [Gnd Clamp] or [Power Clamp] tables, respectively. The | entries for TT(typ), TT(min), and TT(max) must be placed on | a single line and must be separated by at least one white | space or tab or tab character. All three columns are | required under these keywords. However, data is required | only in the typical column. If minimum and/or maximum values | are not available, the reserved word "NA" must be used | indicating the TT(typ) value by default. | Other Notes: The transit time capacitance is added to C_comp. It is | in a Spice reference model as Ct = TT * d(Id)/d(Vd) where | d(Id)/d(Vd) defines the DC conductance at the incremental | DC operating point of the diode, and TT is the transit time. | This expression does not include any series resistance | component. Assume that the internal diode current (Id) - | voltage (Vd) relationship is Id = Is * (exp(q(Vd)/kT) - 1) | where Is is the saturation current, q is electron charge, k is | Boltzmann's constant, and T is temperature in degrees Kelvin. | Then d(Id)/d(Vd) is approximately (q/kT) * Id when the diode | is conducting, and zero otherwise. This yields the simplifi- | cation Ct = TT * (q/kT) * Id. The Id is found from the | [Gnd Clamp] and [Power Clamp] operating points, and the cor- | responding TTgnd or TTpower is used to calculate the Ct value. | If the [Temperature] keyword is not defined, then use the | default "typ" temperature for all Ct calculations. | | The effective TT parameter values are intended to APPROXIMATE | the effects. They may be different from the values found in | the Spice diode equations. Refer to the NOTES ON DATA | DERIVATION METHOD for extracting the effective values. |------------------------------------------------------------------------------ | variable TT(typ) TT(min) TT(max) [TTgnd] 10n 12n 9n [TTpower] 12n NA NA | |============================================================================== Add Section (4) to NOTES ON DATA DERIVATION METHOD: | 4) Transit Time Extractions: | The transit time parameter is indirectly derived to be the value that | produces the same effect as that extracted by the reference measurement | or reference simulation. | | The test circuit consists of the following: | a) A pulse source (10 ohms, 1 ns at full duration ramp) or equivalent | and transitioning over the full expected input transition, such as | between 0 V and Vcc for CMOS technology, and between 0 V and 3.3 V | for TTL and Low voltage technologies, | b) A 50 ohm, 1 ns long trace or transmission line, | c) A 500 ohm termination to the ground clamp reference voltage for TTgnd | extraction and to the power clamp reference voltage for TTpower | extraction (to provide a convenient, minimum loading 450 ohm - | 50 ohm divider for high-speed sampling equipment observation | of the device under test), and | d) The device under test. | | The TTgnd extraction will be done only if a [Gnd Clamp] table exists. | A high to low transition that produces a positive "glitch", perhaps | several nanoseconds later indicates a stored charge in the ground | clamp circuit. The test circuit is simulated using the complete | IBIS model with C_comp and the Ct model defined under the [TTgnd] and | [TTpower] keywords. An effective TTgnd value that produces a "glitch" | with the same delay is extracted. | | Similarily, the TTpower extraction will be done only if a [Power Clamp] | table exists. A low to high transition that produces a negative | "glitch", perhaps several nanoseconds later indicates a stored charge | in the power clamp circuit. An effective TTpower value that produces a | glitch with the same delay is extracted. | | It is preferred to do the extractions with the package parameters | removed. However, if the extraction is done from measurements, then | the package model should be included in the IBIS based simulation. ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Refer to Spice diode reference information concerning the complete equations. The emission coefficient (N) is assumed to be 1. For measured values or cases where N is not 1, use the effective TT values. So the TT values may not be the exact values used in a Spice model. The Spice diode and transistor models differs slightly from the IBIS Clamp models. The definition and position of the capacitances is different. Furthermore, the IBIS table combines the diode and resistor, but can support more complex non-linear characteristics. Intrinsic RS Diode +-----+ |\ | ----> Id | | ----> Id o---/\/\/\--+--| >|--+----o +-----|Clamp|-----+ | |/ | | | | | | | | o----| +-----+ |----o | | | | | | | | +---| |--+ +-------| |-------+ | | | | Cj + Ct C_comp + Ct Fixed values of C_comp serve to estimate voltage dependent non-linear junction capacitance plus other metalization effects. Note, while shown here across the diode, the C_comp and Ct term would be lumped as capacitances between the terminal and ground to provide an equivalent AC circuit. Methods to connect capacitance contributions to each of the voltage rails are not available in the IBIS model. Note, this example illustrates one diode. It can be connected to the ground reference voltage (usually ground) or to the power reference voltage (usually Vcc) serving as either a [Gnd Clamp] or a [Power Clamp]. In practice, both clamps can exist and C_comp would contain the effects of both diodes and metalization. The Ct value is a function of absolute temperature. As an approximation, the default typical temperature is sufficient if [Temperature] is not specified. It is recommended to include the [Temperature] keyword when TT is specified to remove ambiguity regarding minimum and maximum transit time calculations for CMOS versus Bipolar technologies. An underlying assumption is that the equations will be applied only to the Clamping data, not the combined data that includes [Pulldown] and [Pullup] data. So when this detail is needed for Output models, the clamping data needs to be derived, if not provided. Because of these differences and possible missing details, the simplified equation and approximation approach is justified to capture the dominant behavioral effects. So the TT values may be the effective values that are consistent with the IBIS model and data. There are several formatting choices to describe transit time: (1) A [Model] subparameter similar to Vinl and Vinh, e.g., TTgnd = 12n TTpower = 10n This was not chosen because minimum and maximum process Spice models may have different values. (2) A [Model] subparameter similar to C_comp, e.g., TTgnd 10n 12n 9n TTpower 12n NA NA This was not chosen because the rules for minimum and maximum columns for C_comp are based on magnitude, whereas the rules for TT are based on process extremes. This may be confusing if they are similarly formatted. However, this is the second choice since TTgnd, TTpower and C_comp all relate to capacitances. (3) A [Gnd Clamp] and [Power Clamp] subparameter similar to C_comp, e.g [Gnd Clamp] TT 10n 12n 9n This was not chosen because it can cause unnecessary [Gnd Clamp] and [Power Clamp] table complexity and it can make the TT parameters hard to locate. (4) A [Model] keyword modifier similar to [Temperature] and other keywords which are a function of typical, minimum and maximum process and measurement conditions. e.g., [TTgnd] 10n 12n 9n [TTpower] 12n NA NA Since these keywords are related to the [Gnd Clamp] and [Power Clamp] tables and to the conditions under which they were derived, this format was chosen. BIRD34 also includes in its description a proposed extraction method. The method is based on using the typical input signal transitions. It is also designed so that it can be done under actual measurement conditions since the "real" effect may not be accurately modeled in Spice. An alternative which does not closely reflect actual conditions would be to measure the delay forward biased (perhaps by one volt) clamp diode takes to turn off when the bias voltage is removed or reverse biased. This approach has not been fully simulated. However, it is expected to be very sensitive to the selected bias voltages and not necessarily mimic actual operating conditions. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: BIRD34 expands EGG9 and adds more detail on modifying IBIS. It also expands on the mathematical basis as requested by Kellee Crisafulli. It also adds some comments based on EGG9 response from Stephen Peters and others on the positioning of C_comp in the ANALYSIS PATH section. ****************************************************************************** From owner-ibis Tue Mar 5 10:11:53 1996 Received: from montana.okisemi.com (ns.okisemi.com [199.35.228.186]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id KAA09290 for ; Tue, 5 Mar 1996 10:11:53 -0800 (PST) From: Tom_Chao01osg@okisemi.com Received: from palm.okisemi.com (palm.okisemi.com [199.35.228.34]) by montana.okisemi.com - id KAA28652 for ; Tue, 5 Mar 1996 10:08:59 -0800 (PST) Received: from quickmail.okisemi.com (quickmail.okisemi.com [199.35.229.216]) by palm.okisemi.com - id KAA06721 for ; Tue, 5 Mar 1996 10:02:17 -0800 (PST) Received: from Mailer (QuickMail 2525) by quickmail.okisemi.com (PostalUnion/SMTP 1.2.1) id AA0.2908864765; Tue, 05 Mar 1996 10:05:51 PST Message-ID: <1996Mar05.095925.2908864765@quickmail.okisemi.com> To: ibis@vhdl.org (ibis forum) Organization: Oki Semiconductor Date: Tue, 05 Mar 1996 09:59:25 PST Subject: IBIS Pin Mapping IBIS Pin Mapping Dear IBIS folks, At Oki, we have been working to bring up the IBIS models. I have downloaded most of the documentation as well as the s2ibis2 program developed by North Carolina State University. I am confused with the [Pin Mapping] section from the tryme.s2i file provided by Steve Lipa. It includes the comment that "the Pin Mapping really doesn't do anything - the file would work without it." When I tried running an in-house sample, the program got a core dump without this Pin Mapping section. Please help us with this problem. Thank you for your attention and prompt response. Best regards, Thomas Chao From owner-ibis Wed Mar 6 07:43:43 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 HAA24033 for ; Wed, 6 Mar 1996 07:43:41 -0800 (PST) Received: from kadet.asic.sc.ti.com ([156.117.182.198]) by gate.ti.com (8.6.13/) with ESMTP id JAA20005 for ; Wed, 6 Mar 1996 09:34:34 -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 JAA26980 for ; Wed, 6 Mar 1996 09:33:29 -0600 Received: from localhost (andresen@localhost) by sho.asic.sc.ti.com (8.6.4/8.6.4) id JAA15768 for ibis@vhdl.org; Wed, 6 Mar 1996 09:33:27 -0600 Date: Wed, 6 Mar 1996 09:33:27 -0600 From: Ben Andresen Message-Id: <199603061533.JAA15768@sho.asic.sc.ti.com> To: ibis@vhdl.org Subject: Ringback in Universal Signaling Buffers It's not correct to say all the energy will ringback. Remember the PMOS driver stage remains on and sinks current into the 3.3V bus during overshoot. It will sink even more current than the V/I curves predict for the PMOS driver with a given drain-source voltage because the gate-source voltage is higher when the pin voltage exceeds the 3.3V supply level. Ben andresen@asic.sc.ti.com ----- Begin Included Message ----- >From owner-ibis@vhdl.vhdl.org Thu Feb 29 09:31:02 1996 To: si-list@silab.eng.sun.com, ibis@vhdl.org Cc: ingraham@wrksys.ENET.dec.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 ----- End Included Message ----- ----- End Included Message ----- From owner-ibis Thu Mar 7 12:21:06 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 MAA13630 for ; Thu, 7 Mar 1996 12:20:16 -0800 (PST) Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 7 Mar 96 12:11 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Thu, 7 Mar 96 12:13 PST Message-Id: Date: Thu, 7 Mar 96 12:13 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: SULTAN DONWLOAD To IBIS members. Olaf Rethmeier informs me that the problems with the ftp site where Sultan can be downloaded have been fixed. I have also received a copy of sultan.ps.gz by mail and have posted it on vhdl.org under the directory /pub/ibis/sultan. Several compressed formats exist plus the full sultan.ps version. Check the 00readme file for details. The original source is ftp ftp.pad.incases.com under the directory transfer/SULTAN. The reason I give you this is that I have not been able to print my version of sultan.ps. I think it is an internal problem, but I am not sure. So the posted version may be corrupted, and I recommend trying the "incases" site first. Bob Ross Interconnectix, Inc. From owner-ibis Fri Mar 8 09:14: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 JAA03258 for ; Fri, 8 Mar 1996 09:14:03 -0800 (PST) Received: from uucp5.UU.NET by relay5.UU.NET with SMTP id QQagee11177; Fri, 8 Mar 1996 12:05:26 -0500 (EST) Received: from qdt.UUCP by uucp5.UU.NET with UUCP/RMAIL ; Fri, 8 Mar 1996 12:05:27 -0500 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01824; Fri, 8 Mar 96 08:46:13 PST Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA16165; Fri, 8 Mar 96 08:46:06 PST Date: Fri, 8 Mar 96 08:46:06 PST From: jonp@qdt.com (Jon Powell) Message-Id: <9603081646.AA16165@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA18499; Fri, 8 Mar 96 08:46:05 PST To: ibis@vhdl.org Cc: jonp@qdt.com Subject: DAC IBIS booth I am heading up the effort to have an IBIS booth at DAC 96. I will be making a Member Company collage for the booth back drop. Please supply me with a physical sign with your company Logo/message to be put on the backdrop. The sign should be: 1) Smaller than a 8X11 inch footprint 2) Stiff (not just paper but either mounted or metal etc) suggested messages: EDA-COM see us in booth 37 PRO-IC IBIS models available now !! Please mail to: Jon Powell Quad Design 1385 Del Norte Camarillo CA 93010 If you absolutely cannot make a sign I will make one for you using the gif art your company has sent to me. It won't be as nice as if you provide the sign yourself. Let's get going on this now !!! NOTE: THe 8x11 restriction is NON-NEGOTIABLE. If a 8x11 piece of paper will not cover your sign it will not be displayed. thanks and see you at DAC, jon From owner-ibis Fri Mar 8 11:20:08 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 LAA04131 for ; Fri, 8 Mar 1996 11:20:04 -0800 (PST) Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 8 Mar 96 10:51 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 8 Mar 96 10:54 PST Message-Id: Date: Fri, 8 Mar 96 10:54 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org, jonp@qdt.com Subject: Re: DAC IBIS booth Jon: Do you really mean 8-1/2 X 11 as the size limit? Bob Ross Interconnectix, Inc. > Date: Fri, 8 Mar 96 08:46:06 PST > From: jonp@qdt.com (Jon Powell) > Message-Id: <9603081646.AA16165@hal.qdt.com> > Received: by f14.qdt.com (4.1/SMI-4.1) > id AA18499; Fri, 8 Mar 96 08:46:05 PST > To: ibis@vhdl.org > Cc: jonp@qdt.com > Subject: DAC IBIS booth > Status: RO > I am heading up the effort to have an IBIS booth > at DAC 96. > I will be making a Member Company collage for > the booth back drop. > Please supply me with a physical sign with your > company Logo/message to be put on the backdrop. > The sign should be: > 1) Smaller than a 8X11 inch footprint > 2) Stiff (not just paper but either > mounted or metal etc) > > suggested messages: > EDA-COM > see us in booth 37 > PRO-IC > IBIS models available now !! > Please mail to: > Jon Powell > Quad Design > 1385 Del Norte > Camarillo CA 93010 > If you absolutely cannot make a sign I will make one > for you using the gif art your company has sent to me. > It won't be as nice as if you provide the sign yourself. > Let's get going on this now !!! > NOTE: THe 8x11 restriction is NON-NEGOTIABLE. If a 8x11 piece > of paper will not cover your sign it will not be displayed. > thanks and see you at DAC, > jon From owner-ibis Fri Mar 8 11:43:10 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 LAA04277 for ; Fri, 8 Mar 1996 11:43:09 -0800 (PST) Received: from uucp1.UU.NET by relay5.UU.NET with SMTP id QQageo23294; Fri, 8 Mar 1996 14:34:33 -0500 (EST) Received: from qdt.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Fri, 8 Mar 1996 14:34:33 -0500 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA02555; Fri, 8 Mar 96 11:33:32 PST Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA17466; Fri, 8 Mar 96 11:33:33 PST Date: Fri, 8 Mar 96 11:33:33 PST From: jonp@qdt.com (Jon Powell) Message-Id: <9603081933.AA17466@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA18553; Fri, 8 Mar 96 11:33:31 PST To: ibis@vhdl.org Subject: DAC again OK, so I slipped up. The size limit is 8.5X11 instead of 8X11 sorry jon From owner-ibis Fri Mar 8 11:45:09 1996 Received: from montana.nwlink.com (kellee@montana.nwlink.com [199.242.23.13]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id LAA04330 for ; Fri, 8 Mar 1996 11:45:08 -0800 (PST) Received: (from kellee@localhost) by montana.nwlink.com (8.6.12/8.6.9) id LAA29483; Fri, 8 Mar 1996 11:39:49 -0800 Message-Id: <2.2.32.19960308193113.006a9144@mail.nwlink.com> X-Sender: kellee@mail.nwlink.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 08 Mar 1996 11:31:13 -0800 To: ibis@vhdl.org From: Kellee Crisafulli Subject: EDIF and DIE Hellow IBIS land, I emailed Patti rusher and got the following info: 1) EDIF V3 9 9 (ballot version of EDIF V4 0 0) is available, I will follow up getting a copy/s 2) There is no license or usage fee for EDIF except purchasing the final document. 3) The EDIF final document will be $495 for members and $895 for non-members. 4) All comments on DIE have been addresed and finial version is rev 1.0.5. Kellee Have a great day...Kellee Crisafulli, HyperLynx Inc. From owner-ibis Fri Mar 8 12:46:21 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 MAA04800 for ; Fri, 8 Mar 1996 12:46:20 -0800 (PST) Received: from uucp5.UU.NET by relay5.UU.NET with SMTP id QQages08492; Fri, 8 Mar 1996 15:37:43 -0500 (EST) Received: from qdt.UUCP by uucp5.UU.NET with UUCP/RMAIL ; Fri, 8 Mar 1996 15:37:44 -0500 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA02736; Fri, 8 Mar 96 12:11:25 PST Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA17902; Fri, 8 Mar 96 12:11:26 PST Date: Fri, 8 Mar 96 12:11:26 PST From: jonp@qdt.com (Jon Powell) Message-Id: <9603082011.AA17902@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA18580; Fri, 8 Mar 96 12:11:24 PST To: ibis@vhdl.org Subject: DAC again OK, so I slipped up. The size limit is 8.5X11 instead of 8X11 sorry jon From owner-ibis Fri Mar 8 15:30:51 1996 Received: from montana.nwlink.com (kellee@montana.nwlink.com [199.242.23.13]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id PAA06131 for ; Fri, 8 Mar 1996 15:30:50 -0800 (PST) Received: (from kellee@localhost) by montana.nwlink.com (8.6.12/8.6.9) id PAA26215; Fri, 8 Mar 1996 15:25:17 -0800 Message-Id: <2.2.32.19960308231640.006b7790@mail.nwlink.com> X-Sender: kellee@mail.nwlink.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 08 Mar 1996 15:16:40 -0800 To: ibis@vhdl.org From: Kellee Crisafulli Subject: Jon, which orientation on DAC signs landscape or portrait? Which direction do you want the DAC signs, vertical or sideways on the 8.5 x 11? Have a great day...Kellee Crisafulli, HyperLynx Inc. From owner-ibis Fri Mar 8 15:55:24 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 PAA06248 for ; Fri, 8 Mar 1996 15:55:23 -0800 (PST) Received: from us1rmc.bb.dec.com by mail11.digital.com (5.65v3.2/1.0/WV) id AA31268; Fri, 8 Mar 1996 18:36:50 -0500 Received: from wrksys.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94) id AA22315; Fri, 8 Mar 96 18:18:18 -0500 Message-Id: <9603082318.AA22315@us1rmc.bb.dec.com> Received: from wrksys.enet; by us1rmc.enet; Fri, 8 Mar 96 18:37:22 EST Date: Fri, 8 Mar 96 18:37:22 EST From: Andy Ingraham To: ibis@vhdl.org Cc: ingraham@wrksys.ENET.dec.com Apparently-To: ibis@vhdl.org Subject: Re: SULTAN DONWLOAD I copied "sultan.ps" from vhdl.org and successfully printed it, with one minor modification. The original file wouldn't print on my printer because of a command "a4tray", which I guess is probably an European thing that we don't find on our printers here in the States. "A4" size paper is similar to our "A" (8.5 x 11 inch) size. The fix that worked for me was to locate this section of text: /lline 0 array def logme a4 /initialstate save def /PSpagelength 3150 def and delete just the line that has simply "a4". It's line number 750. That worked for my printer, but this being PostScript, there are no guarantees. Since "sultan.ps" contains some rather wide lines of text (up to 573 characters wide), that also might cause a problem should they become truncated, or line-wrapped inappropriately. When you edit the file, use an editor that doesn't impose its own line-wrapping. Regards, Andy Ingraham From owner-ibis Fri Mar 8 16:44:50 1996 Received: from ormail.intel.com (ormail.intel.com [134.134.192.3]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id QAA06553 for ; Fri, 8 Mar 1996 16:44:49 -0800 (PST) Received: from relay.jf.intel.com (relay.jf.intel.com [134.134.131.6]) by ormail.intel.com (8.7.4/8.7.3) with SMTP id QAA21377; Fri, 8 Mar 1996 16:36:08 -0800 (PST) Received: (from ccmgate@localhost) by relay.jf.intel.com (8.6.12/8.6.12) id QAA17964; Fri, 8 Mar 1996 16:36:07 -0800 Received: by ccm.jf.intel.com (ccmgate 3.2 #6) Fri, 08 Mar 96 16:36:07 PST Date: Fri, 08 Mar 96 16:33:00 PST From: Will Hobbs Message-ID: To: owner-ibis@vhdl.org, ibis@vhdl.org Subject: Re: Jon, which orientation on DAC signs landscape or portrai Text item: Kellee, Jon, My vote would be to allow either. Since these are going to be velcro'd to the wall in an array around the central IBIS logo, I think either orientation can be artistically arranged in any combination. Will Which direction do you want the DAC signs, vertical or sideways on the 8.5 x 11? Have a great day...Kellee Crisafulli, HyperLynx Inc. 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: Jon, which orientation on DAC signs landscape or portrait? From: Kellee Crisafulli To: ibis@vhdl.org Date: Fri, 08 Mar 1996 15:16:40 -0800 Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: Windows Eudora Pro Version 2.2 (32) X-Sender: kellee@mail.nwlink.com Message-Id: <2.2.32.19960308231640.006b7790@mail.nwlink.com> Received: (from kellee@localhost) by montana.nwlink.com (8.6.12/8.6.9) id PAA262 15; Fri, 8 Mar 1996 15:25:17 -0800 Received: from montana.nwlink.com (kellee@montana.nwlink.com [199.242.23.13]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id PAA06131 for ; Fri, 8 M ar 1996 15:30:50 -0800 (PST) Received: from vhdl.vhdl.org by SSD.intel.com (4.1/SMI-4.1) id AA23384; Fri, 8 Mar 96 16:25:52 PST Received: from SSD.intel.com by ichips.intel.com (8.7.1/jIII); Fri, 8 Mar 1996 1 6:27:21 -0800 (PST) Received: from ichips.intel.com (ichips.intel.com [134.134.50.200]) by relay.jf. intel.com (8.6.12/8.6.12) with ESMTP id QAA16915; Fri, 8 Mar 1996 16:27:24 -0800 Return-Path: owner-ibis@vhdl.vhdl.org From owner-ibis Mon Mar 11 08:56:56 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 IAA08250 for ; Mon, 11 Mar 1996 08:56:51 -0800 (PST) Received: from uucp5.UU.NET by relay5.UU.NET with SMTP id QQagpf20473; Mon, 11 Mar 1996 11:47:33 -0500 (EST) Received: from qdt.UUCP by uucp5.UU.NET with UUCP/RMAIL ; Mon, 11 Mar 1996 11:48:07 -0500 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00634; Mon, 11 Mar 96 08:47:22 PST Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA26341; Mon, 11 Mar 96 08:47:22 PST Received: from uucp5.UU.NET by relay5.UU.NET with SMTP id QQagpe18409; Mon, 11 Mar 1996 11:41:04 -0500 (EST) Received: from qdt.UUCP by uucp5.UU.NET with UUCP/RMAIL ; Mon, 11 Mar 1996 11:41:04 -0500 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00491; Mon, 11 Mar 96 08:13:57 PST Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA26083; Mon, 11 Mar 96 08:13:57 PST Date: Mon, 11 Mar 96 08:13:57 PST From: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell) Message-Id: <9603111613.AA26083@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA20096; Mon, 11 Mar 96 08:13:56 PST To: uunet!uunet!hyperlynx.com!kellee@uunet.uu.net Cc: uunet!uunet!vhdl.org!ibis@uunet.uu.net In-Reply-To: <2.2.32.19960308231640.006b7790@mail.nwlink.com> (uunet!hyperlynx.com!kellee) Subject: Re: Jon, which orientation on DAC signs landscape or portrait? I don't think orientation matters. In fact, I hope that signs are vaguely different in shape because it will make for a prettier back drop. jon From owner-ibis Tue Mar 12 17:20:54 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 RAA28525 for ; Tue, 12 Mar 1996 17:20:22 -0800 (PST) Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 12 Mar 96 17:11 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 12 Mar 96 17:14 PST Message-Id: Date: Tue, 12 Mar 96 17:14 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS MINUTES 3/8/96 DATE: March 12, 1996 SUBJECT: 3/8/96 EIA IBIS Open Forum Minutes VOTING MEMBERS AND 1996 PARTICIPANTS LIST: AMP Hank Herrmann* 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, Jim 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 Apteq Design System Dan FitzPatrick Compaq Mark Leonard Cypress Bruce Wenniger Digital Equipment Corp. Jeff Chu EIA Patti Rusher IC Works Eric Chen Micron Technology Brian Johnson MicroSim Ralph Perez North Carolina State U. (Michael Steer) Oki Semiconductor Tom Chao* S3, Inc. Sarathy Sribhashyam, Phap Duong Seimans Nixdorf Arnaud Lacariere Tektronix, Inc. Brock Hannibal TRW & Free Model Foundation Robert Harrison Veribest/Integraph Ian Dodd*, David Wiens* 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/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 Tom Chao of Oki Semiconductor introduced himself and indicated that Oki will be making IBIS models for their ASICs. EIA MEMBERSHIP AND TREASURER'S REPORT Hank Herrmann reported that AMP is now a full IBIS member. No treasurer's report was available. MINUTES REPORT, MISC. Jim Kruchowski first name correction in m012969.txt and m021696.txt minutes. MISCELLANY/ANNOUNCEMENTS A simple IBIS default home page now exists on http://www.vhdl.org/pub/ibis/ which is intended to be accessed by the top level vhdl.org. It consists of some background information and a link to the IBIS directories, the official EIA/IBIS home page, and the RAIL directories. 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 In EDN, March 1, 1996, pg. 50, winibis by Hyperlynx is mentioned. In EE Times, February 26, 1996. pg. 88, IBIS is mentioned in a Quad Design introduction writeup. NEW MODELS Sung Oh reports that VLSI now has dozens of IBIS models available. To get a list, e-mail ibismodel@tempe.vlsi.com Syed Huq suggested that Sung also provide a list of available models on vhdl.org. He can contact Michael Steer to have it set up. OPENS FOR NEW ISSUES None EIA/IBIS 1996 MEMBERSHIP AR - Bob Ross find from Patti Rusher who now are official EIA/IBIS members for 1996. Dave Moxley of NCR and Dileep Divekar of Contec Microelectronics still report not receiving the revised invoice or FAX. DAC STANDARDS BOOTH Jon Powell proposed all official member companies generate their own logo art on 8.5 inch by 11 inch paper with Velcro backing to stick on a poster wall. All members can put this in an array around a central IBIS logo and add any message such as "see us at booth 435". Jon says that you can just print the artwork using a color printer and take it to a print shop and have them mount the artwork on a poster board with Velcro backing. Alternatively, Jon can make the posters from the existing supplied logos. He can still do so for those who request it. However, the preference is for each company to make their own posters. AR - Everyone making posters for DAC please send them to Jon Powell prior to DAC. Bob Ross suggested that non-EIA/IBIS members who are producing IBIS models would also be permitted to have a poster displayed. Will Hobbs suggested "I Speak IBIS" badges. Jon Powell will look into this. This seemed like a very good idea and Jon thinks it will be easy to do. ANSI/EIA-656 INTERNATIONAL RATIFICATION Patti Rusher has received a response request regarding pending IBIS International ratification. The request was to put IBIS into an Express-G format. This appears to be a defacto requirement for EDA standards, such as EDIF 4 0 0. The Express format produces graphical relationships and produces a self consistent document from which a parser can easily be developed. It is still not known what the total impact is. We appear to have three options: Push of International Standardization based on its defacto acceptance and broad support without an Express representation. Attempt to do an Express representation through any number of resources including interested members, university project, and ARPA funding of a contractor. Withdraw the request for international standardization. We are still trying to understand the impact and scope, since the committee representatives are not familiar with Express. AR - Bob Ross invite the commentors to the next IBIS meeting for their direct knowledge and input on the issue. AR - Bob Ross and Will Hobbs will post the comments related to Express-G on the reflector so we can get other opinions. ANSI/EIA-656 PUBLICATION No further status was available. The standard is planned to be available through Global Engineering Documents. IBIS ROSTER UPDATE Bob Ross reported that the 1996 roster is on vhdl.org. It contains all of the official member companies plus the other companies that have responded. Others who have not responded have been removed. The roster will continue to be updated as new responses come in. The old roster is archived. EIA WEB UPDATE Syed Huq reported that the EIA/IBIS home page counters are now working on all pages. He has also added revision numbers to all pages. He has been receiving logo updates and new logos from Cadence, Incases, TI, NCR, Mentor Graphics. VLSI logo has not been received by Jon Powell, and Sung Oh will look into this. Currently Mentor is not a member company so their logo would not be permitted. Once the updates are made (including) some new home page links, Syed will announce the Home page. Syed thanks EIA for their support. Syed would also like to put a model tools section to reference s2ibis and s2iplt, winibis, the cookbook and the parsers. The committee endorsed this expansion. GOLDEN PARSER UPDATE Bob Ross formally submitted the three bugs through the newly established parser reporting system before we issue a parser correction. A bug directory exists, and a BUG form is available there. These old bugs consist of multiple disclaimers, missing legal suffixes in package model matrix data, and failure to detect a minor subparameter syntax error under [Model]. The first and third error does not exist in the original ibis_chk utility. In addition, we would like to see the parser version number printed so people know which parser is being used (e.g., Version 2.1.10) Unfortunately, there is no formal validation suite. However, the fixes should be minor and are important for Specification compliance. Additions to the parser as proposed in EGG10 (later) will not be included. AR - Bob Ross contact Paul Munsey about the time/cost of the fixes. SPICE TO IBIS VERSION 1.2, 2.1 AR - Bob Ross will seek further information regarding the status of the project. Several bugs have been submitted from various sources, but they are not on a formal list. Also Bob reported a VERSION 1.2 bug regarding handling of the Pullup Table in the Clamping region - a double counting of the clamping current. It was suggested that the bug tracking system be expanded to include s2ibis bugs. Subdirectories for each utility can be established. The general e-mail address for submittal can be changed to ibis-bug@vhdl.org. PRIORITIES FOR 1996 Will Hobbs deferred further discussion of priorities for 1996. Instead, he presented the list of priorities from the last meeting. 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 ... BIRD33 (EGG8) - PHYSICAL PACKAGE DISCUSSION Olaf Rethmeier indicated that computer problems have been fixed and the SULTAN proposal was available for downloading. Bob Ross also put copies on vhdl.org under /pub/ibis/sultan. His version did not print, however. (The problem was discovered later to the size A4 statement in line 750 which can be deleted.) The major discussion centered around Kellee Crisafulli's proposal and also on the fact that there are several other existing proposals. Kellee's proposal is expected to be simpler than SULTAN, EDIF, etc., and is intended to be user easier to use. C. Kumar suggested that an IBIS subset of EDIF could meet the needs - if it were possible to generate. Ian Dodd had a question on whether EDIF required a royalty payment. Further discussion concerned the completeness of Kellee's proposal since it does not include arbitrary shaped or meshed planes. Stephen Peters questioned what were the limitations. AR - Kellee Crisafulli contact Patti Rusher concerning royalties on EDIF and also on the availability of EDIF 4 0 0 itself. [Done - not required, and Patti will make it available.] Will Hobbs proposed a subgroup to get the physical package discussion off center. Such a group was formed and consists of Stephen Peters, C. Kumar, Olaf Rethmeier, Jon Powell, Ian Dodd, and Kellee Crisafulli. The first meeting will be Friday, March 15, 1996, and Stephen will set up the conference call. After some discussion, the groups focus will be to address the physical representation first. Some eventual choices may be to propose BIRD33, to propose an existing representation such as SULTAN or EDIF, or to propose a subset of an existing representation. It will report back at the next meeting. The group can also address the electrical description problem, but it's priority is to deal with the physical description issue first. BIRD31 - CONNECTOR MODELS No report. Bob Ross plans to issue BIRD31.1 BIRD32 PACKAGE MODEL ENHANCEMENT No update from Stephen Peters. C. Kumar is still interested in a Spice- like description. However, Jon Powell proposed a proven Quad Design structure also be considered. His concern continues to be properly describing the inductive coupling polarity of package models. This discussion can be carried by the Physical package subcommittee. BIRD34 (EGG9) - HANDLING STORED CHARGE Bob Ross described BIRD34 as an extension of the old EGG9 proposal. It also includes the assumed formulas and a TT extraction method description which produces the effective value. The method is intended to mimic a real signal. The description was very unclear to Stephen Peters, so it needs to be redone and clarified. Jon Powell has experimental support for modeling TT as long as the series resistance is not too large. He has used C vs. V tables to produce good correlation. EGG10 - PARSER ADDITIONS FOR NUMERICAL CHECKING In the brief time remaining, this topic was introduced. Bob Ross indicated that the first proposal concerning monotonicity checks was not clear since there are both Warning and Error checks already in ibischk2 as a result of extensive past discussions. It is not clear whether the request was for some new capability. Bob also indicated that Stephen Peter's addition to give warning of such parameters as C_comp, C_pkg, etc., should be based on actual values, not the existence of suffixes, since numerical values can be extracted (such as with the monotonocity tests). NEXT MEETING: The next telephone meeting is set for Friday, March 29, 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 Mar 18 19:05: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 TAA02332 for ; Mon, 18 Mar 1996 19:03:55 -0800 (PST) Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 18 Mar 96 18:54 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 18 Mar 96 18:57 PST Message-Id: Date: Mon, 18 Mar 96 18:57 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: BIRD31.1 MATED MODELS To IBIS Members: Finally I have gotten around with the long promised BIRD31.1. Based on initial comments and concerns, the original BIRD31 was not acceptable because it required splitting up the electrical model. The name of BIRD31.1 is changed to "Mated Model" to be more inclusive of connector, cable and socket alternatives which can use the proposed description. BIRD31.1 is a total rewrite of BIRD31. The contents of this extension are blended with the existing PACKAGE MODELING text plus BIRD28.3 extensions. Because this extension is not yet finalized, the writeup may be somewhat rough. The key points of this extension are elaborated in the ANALYIS PATH ... section. Briefly they are: (1) The mated model extension applies to connectors, cables and sockets. (2) The mated model uses the same package model electrical extensions. (3) The mated model introduces the [Define Mated Model] and [End Mated Model] keywords with the following differences from the package model: (a) It has optional pad capacitance subparameters Cpad_1 and Cpad_2. (b) Mated models must exist in a separate .mmf file. (c) Mated models are not reference by any [Component] in a .ibs file. (d) The "mated model" contains two columns of pins versus one in package models. (4) The mated model captures the electrical data. However, its connection and usage syntax is simulator dependent. Mated models can be used to attach boards through connectors, attach boards through cables, and attach components through sockets to boards. Bob Ross, Interconnectix, Inc. ****************************************************************************** ****************************************************************************** BIRD ID#: 31.1 ISSUE TITLE: Mated Models REQUESTER: Bob Ross, Interconnectix, Inc. DATE SUBMITTED: 11/22/95, 3/18/96 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: No guidance is given within IBIS with respect to modeling connectors, cables and sockets used to connect boards to boards and boards to components. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: "Mated model" text is blended within the original PACKAGE MODELING section, and the section is renamed as PACKAGE, CONNECTOR, CABLE AND SOCKET MODELS. The whole section is presented with BIRD28.3 extensions and additional changes noted by "|*" lines. (References to the "PACKAGE MODELING" section elsewhere would be changed to the new title. These are not shown.) |============================================================================= | |* PACKAGE, CONNECTOR, CABLE, AND SOCKET MODELING |* |* This section describes the [Define Package Model] syntax and its matrix, |* transmission line, and discrete element extension formats. This section |* also describes [Define Mated Model] as a generic class of I/O terminal |* extensions which can be used to describe the electrical characteristics |* of connectors, sockets, and cables. These can be referred to as "mated |* models" because the are used to provide the interconnection between circuit |* boards through connectors or cables, and also between boards and components |* through sockets. |* |* The electrical format for data is identical. Some operational details |* and syntax are noted. |* | The [Package Model] keyword is optional. If more than the default RLC |* package model is desired, use the [Define Package Model] keyword. There |* is no reference within the [Component] keyword to any connector model. |* The information within the [Define Mated Model] is available to |* simulators to define the interconnections using the simulator-specific |* syntax and interfaces. | | Use the [Package Model] keyword within a [Component] to indicate the package | model for that part. The specification permits .ibs files to contain the | following additional list of package model keywords. Note that the actual | package models can be in a separate .pkg file or can | exist in the IBIS files between the [Define Package Model]... |* [End Package Model] keywords for each package model that is defined. |* However, the mated model keywords can exist only in a separate |* .mmf, and not in a .ibs or .pkg file. It exits |* between the [Define Mated Model] ... [End Mated Model] keywords for each |* connector that is defined. For reference, the keywords are listed |* below. Full descriptions follow. |* Simulators that do not support these keywords will ignore all entries between |* the [Define Package Model] and [End Package Model] keywords or between the |* [Define Mated Model] and [End Connector Model] keywords. |* | |* [Define Package Model] Required if the [Package Model] keyword is used |* [Define Mated Model] (note 3) | [Manufacturer] (note 1) | [OEM] (note 1) | [Description] (note 1) |** BIRD28.3 ADDITION BELOW |** [Number of Sections] (optional) | [Number of Pins] (note 1) | [Pin Numbers] (note 1) |* [Model Data] (note 4) |* [Resistance Matrix] (note 4, optional) |* [Inductance Matrix] (note 4) |* [Capacitance Matrix] (note 4) |* [Bandwidth] (note 4, required for Banded_matrix matrices only) |* [Row] (note 4) |* [End Model Data] (note 4) |* [End Package Model] (note 2) |* [End Mated Model] (note 3) | |* (note 1) Required when the [Define Package Model] or [Define Mated Model] |* keyword is used |* (note 2) Required for ending a package model definition |* (note 3) Required for beginning and ending a mated model definition |* (note 4) Used only when the [Model Data] ... [End Model Data] is used |* | When package model definitions occur within a .ibs file, their scope is | "local" -- they are known only within that .ibs file and no other. | In addition, within that .ibs file, they override any globally defined | package models that have the same name. | |* USAGE RULES FOR THE .PKG AND .MMF FILES | | Package models are stored in a file whose name looks like: | .pkg. |* |* Mated models are stored in a file whose name looks like: | .mmf. | | The provided must adhere to the General Syntax Rules. Use the |* ".pkg" extension to identify files containing package models. Use the |* ".mmf" extension to identify files containing mated models. The .pkg and |* .mmf files | must contain all of the required elements of a normal .ibs file, including | [IBIS Ver], [File Name], [File Rev], and the [End] keywords. Optional | elements include the [Date], [Source], [Notes], [Disclaimer], [Copyright], | and [Comment Char] keywords. | | All of the elements follow the same rules as those for a normal .ibs file. | | Note that the [Component] and [Model] keywords are not allowed in the .pkg |* or .mmf files. The .pkg file is for package models only. The .mmf file |* is used for mated models only. | |============================================================================== | Keyword: [Define Package Model] | Required: Yes | Description: Marks the beginning of a package model description. | Usage Rules: If the .pkg file contains data for more than one package, | each section must begin with a new [Define Package Model] | keyword. The length of the package model name must not | exceed 40 characters in length. Blank characters are | allowed. For every package model name defined under the | [Package Model] keyword, there must be a matching [Define | Package Model] keyword. |------------------------------------------------------------------------------ [Define Package Model] QS-SMT-cer-8-pin-pkgs | |*============================================================================= |* Keyword: [Define Mated Model] |* Required: Yes |* Sub-params: Cpad_1, Cpad_2 |* Description: Marks the beginning of a mated model description. |* Usage Rules: If the .mmf file contains data for more than one mated model, |* each section must begin with a new [Define Mated Model] |* keyword. The length of the mated model name must not |* exceed 40 characters in length. Blank characters are |* allowed. |* |* The Cpad_1 and Cpad_2 subparameters are optional and define |* default pad capacitances at sides 1 and 2 of the mated model. |* The values default to 0 pF if omitted. However, in all case |* the simulator may override the default values based on |* actual geometrical pad dimensions. |*------------------------------------------------------------------------------ [Define Mated Model] CONN4X40 Cpad_1 = .5pF Cpad_2 = 1.0pF |* |============================================================================== | Keyword: [Manufacturer] | Required: Yes | Description: Declares the manufacturer of the part(s) that use this package |* or mated model. | Usage Rules: The length of the manufacturer's name must not exceed 40 | characters (blank characters are allowed, e.g., Texas | Instruments). In addition, each manufacturer must use a | consistent name in all .ibs and .pkg files. |------------------------------------------------------------------------------ [Manufacturer] Quality Semiconductors Ltd. | |============================================================================== | Keyword: [OEM] | Required: Yes |* Description: Declares the manufacturer of the package or mated model. | Usage Rules: The length of the manufacturer's name must not exceed 40 | characters (blank characters are allowed). In addition, each | manufacturer must use a consistent name in all .ibs and .pkg | files. | Other Notes: This keyword is useful if the semiconductor vendor sells a | single IC in packages from different manufacturers. |------------------------------------------------------------------------------ [OEM] Acme Packaging Co. | |============================================================================== | Keyword: [Description] | Required: Yes | Description: Provides a concise yet easily human-readable description of |* what kind of package the [Package Model] or mated model is |* representing. | Usage Rules: The description must be less than 60 characters in length, | must fit on a single line, and may contain spaces. |------------------------------------------------------------------------------ [Description] 220-Pin Quad Ceramic Flat Pack | |****************************************************************************** |****************************************************************************** |* BIRD28.3 ADDITION |****************************************************************************** |****************************************************************************** |============================================================================== | Keyword: [Number of Sections] | Required: No |Description: Defines the maximum number of sections that make up a 'package |* stub' or mated model. | A package stub is defined as the connection between | the die pad and the corresponding package pin; it can include | (but is not limited to) the bondwire, the connection between | the bondwire and pin, and the pin itself. This keyword must | be used if a modeler wishes to describe any package stub as | other than a single, lumped L/R/C. The sections of a package | stub are assumed to connect to each other in a series fashion. |* This keyword also defines the number of sections that make up |* a mated model. |Usage Rules: The argument is a positive integer greater than zero. This | keyword, if used, must appear in the specification before the | [Pin Numbers] keyword. |----------------------------------------------------------------------------- [Number of Sections] 3 | |****************************************************************************** |****************************************************************************** |* END OF BIRD28.3 ADDITION |****************************************************************************** |****************************************************************************** |============================================================================== | Keyword: [Number of Pins] | Required: Yes | Description: Tells the parser how many pins to expect. | Usage Rules: The field must be a positive decimal integer. |------------------------------------------------------------------------------ [Number of Pins] 128 | |****************************************************************************** |****************************************************************************** |* BIRD28.3 REPLACEMENT BELOW |****************************************************************************** |****************************************************************************** |============================================================================= | Keyword: [Pin Numbers] | Required: Yes |Description: Tells the parser the set of names that are used for the package |* or mated model | pins and also defines pin ordering. If the [Number of Sections] | keyword is present it also lists the elements for each section |* of a pin's die to pin connection or mated model connection. | Sub-Params: Len, L, R, C, Matrix |Usage Rules: Following the [Pin Numbers] keyword, the names of the pins are | listed. There must be as many names listed as there are pins | (as given by the preceding [Number of Pins] keyword). Pin names | can not exceed 5 characters in length. The first pin name | given is the "lowest" pin, and the last pin given is the | "highest." If the [Number of Sections] keyword is used then | each pin name must be followed by one or more of the legal | subparameter combinations listed below. If the [Number of | Sections] keyword is not present then subparameter usage is | NOT allowed. |* |* For package models, the first column is used for listing each |* pin. For mated models, the first and second columns are used |* to list the side 1 pins and the corresponding side 2 pins. |* Normally the side 2 listing is the same as the side 1 listing. |* However, for cables and connectors that crossover or have |* different pin names or groupings at either end, the two columns |* will have different entries. All Matrix references will be |* based on the first column notation and order. | | Subparameters: | The subparameters specify the length, inductance, capacitance |* and resistance of each section of each stub on a package or mated |* model. If | a particular section exhibits coupling to an adjacent (same | numbered) section of a different package stub then the Matrix | subparameter is used. The subparameters are defined as | follows: |* Len The length of a package or mated model stub section. |* Lengths are given | in terms of arbitrary 'units'. |* L The inductance of a package stub or mated model section, |* in terms of | 'inductance/unit length'. For example, if the total | inductance of a package stub section is 3.0nH and the | length of this section is 2 'units', the inductance | would be listed as L = 1.5nH (i.e. 3.0 / 2). |* C The capacitance of a package stub or mated model section, |* in terms of | capacitance per unit length. |* R The DC (ohmic) resistance of a package stub or mated |* model section,in | terms of ohms per unit length. | Matrix Use of this subparameter means that this package stub |* or mated model | sections electrical parameters are presented as part of | a coupling matrix. The data for the matrix is included | between the [Model Data]/[End Model Data] keyword pairs | as described below. | | Specifying a length or L/R/C value of zero is allowed. If | Len = 0 is specified, then the L/R/C values are the total | for that section. If a non-zero length is specified, then | the total L/R/C for a section is calculated by multiplying | the value of the Len subparameter by the value of the L, | R or C subparameter. | |* Using the Subparameters to Describe Package or Mated Model |* Sections: | Each section description must begin with the Len subparameter and | ends with the slash (/) character. The value of a sub- | parameter and the subparameter itself are separated by an equals | sign (=); whitespace around the equals sign is optional. All | package stub descriptions must contain the same number of | sections however, a particular section description can contain | no data (i.e. the description is given as 'Len = 0 /'. See the | example below). | | Legal Subparameter Combinations: | A) A single Len = 0 subparameter, followed by a slash. | The is used to describe a section with no data. | | B) Len and a single Matrix subparameter, followed by a | slash. The Len subparameter specifies the length of that | section while the Matrix subparameter indicates that this | section of this package stub is electrically coupled to the | corresponding (same numbered) section of an adjacent package | stub (or stubs) and the coupling terms are listed in a matrix | format. The matrix description must include both the 'self' | inductance/capacitance/resistance (as required) of a section | as well as the mutual coupling terms. If one section is | described using the the Matrix subparameter then the | corresponding (same numbered) sections on ALL other package | stubs must use the Matrix subparameter. | | C) Len, and one or more of the L, R and C subparameters. If | the Len subparameter is given as zero, then the L/R/C sub- | parameters represent lumped elements. If the the Len sub- | parameter is non-zero, then the L/R/C subparameters represent | distributed elements. | | | In the example below the first section is a lumped inductor, | the second section is described using a matrix, and the third | section is modeled using distributed elements. Pin A3 shows | an example of sections with no data. Pins A4 and A5 illustrate | how a section description can be broken across multiple lines | and how each section description is delimited by the slash. |----------------------------------------------------------------------------- [Pin Numbers] A1 Len = 0 L=1.2n / Len = 1.3 Matrix / Len=0.47 L=8.35n C=3.34p R=0.01 / A2 Len = 0 L=1.4n / Len = 1.2 Matrix / Len=0.47 L=6.21n C=3.34p R=0.01 / A3 Len = 0 / Len = 1.1 Matrix / Len = 0 / A4 Len = 0 L=1.2n / Len = 1.0 Matrix / Len=0.47 L=8.35n C=3.34p R=0.01/ A5 Len = 0 L=1.2n / Len=1.2 Matrix / Len=0.47 L= 8.35n C=3.34p R=0.01 / | | Note that the actual length for each section is reported, even for | those sections that use the Matrix subparameter. | |* Note that there are two columns of pin numbers if this is for a |* mated model definition. |============================================================================= | Keyword: [Model Data] |* Required: Yes, if any of the sections in a package stub or mated model |* description | use the 'Matrix' subparameter or if the [Number of Sections] | keyword is not used. |*Description: Indicates the beginning of the matrix data used to describe |* a package stub or mated model section. |Usage Rules: If the [Number of Sections] keyword is used then the [Model | Data] keyword must be followed by the word 'section' and the | section number the matrix data applies to. There must be a | [Model Data] keyword for every section in a package stub |* or mated model | description that uses the Matrix keyword. Note that if the | [Number of Sections] keyword is used but no package stub |* or mated model | sections use the Matrix subparameter then the [Model Data] | and [End Model Data] keyword are not required. |----------------------------------------------------------------------------- [Model Data] section 2 | |============================================================================= | Keyword: [End Model Data] | Required: Yes, if the [Model Data] keyword is present. |Description: Indicates the end of the matrix data used to describe |* a package stub or mated model section. |Usage Rules: In between the [Model Data] and [End Model Data] keywords is | the matrix data itself. The data is a set of three matrices: | the resistance (R) , inductance (L) , and capacitance (C), | matrices. Each matrix can be formatted differently (see | below). Use one of the matrix keywords to mark the | beginning of each matrix. As with the [Model Data] keyword | the [End Model Data] keyword is followed by the word 'section' | and the section number. |----------------------------------------------------------------------------- [End Model Data] section 2 | |****************************************************************************** |****************************************************************************** |* END OF BIRD28.3 REPLACEMENT OF EXITING VERSION 2.1 TEXT |****************************************************************************** |****************************************************************************** |============================================================================== | Keywords: [Resistance Matrix], [Inductance Matrix], [Capacitance Matrix] | Required: [Resistance Matrix] is optional. If it is not present, its | entries are assumed to be zero. [Inductance Matrix] and | [Capacitance Matrix] are required. | Sub-Params: Banded_matrix, Sparse_matrix, or Full_matrix | Description: The subparameters mark the beginning of a matrix, and | specify how the matrix data is formatted. | Usage Rules: For each matrix keyword, use only one of the subparameters. | After each of these subparameters, insert the matrix data in | the appropriate format. (These formats are described in detail | below.) | Other Notes: The resistance, inductance, and capacitance matrices are also | referred to as "RLC matrices" within this specification. | | When measuring the entries of the RLC matrices, either with | laboratory equipment or field-solver software, currents are |* defined as ENTERING the pins of the package or mated model |* from the board | (General Syntax Rule #11). The corresponding voltage drops are | to be measured with the current pointing "in" to the "+" sign | and "out" of the "-" sign. | | I1 +-----+ I2 | -----> | | <------ | board o--------| Pkg |---------o board | + V1 - | | - V2 + | +-----+ | | It is important to observe this convention in order to get the | correct signs for the mutual inductances and resistances. | |------------------------------------------------------------------------------ [Resistance Matrix] Banded_matrix [Inductance Matrix] Sparse_matrix [Capacitance Matrix] Full_matrix | |============================================================================== | | RLC MATRIX NOTES | For each [Resistance Matrix], [Inductance Matrix], or [Capacitance | Matrix] a different format can be used for the data. The choice of | formats is provided to satisfy different simulation accuracy and speed | requirements. Also, there are many packages in which the resistance | matrix can have no coupling terms at all. In this case, the most | concise format (Banded_matrix) can be used. | |****************************************************************************** |****************************************************************************** |* BIRD28.3 ADDITION |****************************************************************************** |****************************************************************************** | There are two different ways to extract the coefficients that are reported | in the the capacitance and inductance matrices. For the purposes of this | specification, the coefficients reported in the capacitance matrices shall | be the 'electrostatic induction coefficients' or 'Maxwell's capacitances'. | The Maxwell capacitance Kij is defined as the charge induced on conductor "j" | when conductor "i" is held at 1 volt and all other conductors are held at | zero volts. Note that Kij ( when i /= j) will be a negative number and | should be entered as such. Likewise, for the inductance matrix the | coefficients for Lij are defined as the voltage induced on conductor "j" | when conductor "i"'s current is changed by 1amp/sec and all other | conductors have no current change. | |****************************************************************************** |****************************************************************************** |* END OF BIRD28.3 ADDITION |****************************************************************************** |****************************************************************************** | One common aspect of all the different formats is that they exploit | the symmetry of the matrices they describe. This means that the | entries below the main diagonal of the matrix are identical to the | corresponding entries above the main diagonal. Therefore, only | roughly one-half of the matrix needs to be described. By convention, | the main diagonal and the UPPER half of the matrix are provided. | | In the following text, we use the notation [I, J] to refer to the entry in | row I and column J of the matrix. Note that I and J are allowed to be | alphanumeric strings as well as integers. An ordering of these | strings is defined in the [Pin Numbers] section. In the following text, | "Row 1", means the row corresponding to the first pin. | | Also note that the numeric entries of the RLC matrices are standard IBIS | floating point numbers. As such, it is permissible to use metric "suffix" | notation. Thus, an entry of the C matrix could be given as 1.23e-12 or as | 1.23p or 1.23pF. | | Full_matrix | | When the Full_matrix format is used, the couplings between every pair of | elements is specified explicitly. Assume that the matrix has N rows and N | columns. The Full_matrix is specified one row at a time, starting with Row 1 | and continuing down to Row N. | | Each new row is identified with the Row keyword. | |============================================================================== | Keyword: [Row] | Required: Yes | Description: Indicates the beginning of a new row of the matrix. | Usage Rules: The argument must be one of the pin numbers listed under the | [Pin Numbers] keyword. |------------------------------------------------------------------------------ [Row] 3 | |============================================================================== | Following a [Row] keyword is a block of numbers that represent the | entries for that row. Suppose that the current row is number M. Then | the first number listed is the diagonal entry, [M,M]. Following this | number are the entries of the upper half of the matrix that belong to row M: | [M, M+1], [M, M+2], ... up to [M,N]. | |* For even a modest-sized package or mated model, |* this data will not all fit on one line. | You can break the data up with new-line characters so that this limit is | observed. | | An example: suppose the package has 40 pins and that we are currently | working on Row 19. There is 1 diagonal entry, plus 40 - 19 = 21 entries in | the upper half of the matrix to be specified, for 22 entries total. The data | might be formatted as follows: | [Row] 19 5.67e-9 1.1e-9 0.8e-9 0.6e-9 0.4e-9 0.2e-9 0.1e-9 0.09e-9 8e-10 7e-10 6e-10 5e-10 4e-10 3e-10 2e-10 1e-10 9e-11 8e-11 7e-11 6e-11 5e-11 4e-11 | | In the above example, the entry 5.67e-9 is on the diagonal of row 19. | | Observe that Row 1 always has the most entries, and that each successive row | has one fewer entry than the last; the last row always has just a single | entry. | | Banded_matrix | | A Banded_matrix is one whose entries are guaranteed to be zero if they | are farther away from the main diagonal than a certain distance, known | as the "bandwidth." Let the matrix size be N x M, and let the bandwidth | be B. An entry [I,J] of the matrix is zero if: | | | I - J | > B | | where |.| denotes the absolute value. | | The Banded_matrix is used to specify the coupling effects up to B pins | on either side. Two variations are supported. One allows for the coupling | to circle back on itself. This is technically a simple form of a bordered | block diagonal matrix. However, its data can be completely specified | in terms of a Banded_matrix for an N x M matrix consisting of N rows | and M = N + B columns. The second variation is just in terms of an N x N | matrix where no circle back coupling needs to be specified. | | The bandwidth for a Banded_matrix must be specified using the [Bandwidth] | keyword: | |============================================================================== | Keyword: [Bandwidth] | Required: Yes (for Banded_matrix matrices only) | Description: Indicates the bandwidth of the matrix. The bandwidth field | must be a nonnegative integer. This keyword must occur after | the [Resistance Matrix], etc. keywords, and before the matrix | data is given. | Usage Rules: |------------------------------------------------------------------------------ [Bandwidth] 10 | |============================================================================== | Specify the banded matrix one row at a time, starting with row 1 and | working up to higher rows. Mark each row with the [Row] keyword, as | above. As before, symmetry is exploited: do not provide entries below the | main diagonal. | | For case where coupling can circle back on itself, consider a matrix of | N pins organized into N rows 1 ... N and M columms 1 ... N, 1 ... B. | The first row only needs to specify the entries [1,1] through [1,1+B] since | all other entries are guaranteed to be zero. The second row will need to | specify the entries [2,2] through [2,2+B], and so on. For row K | the entries [K,K] through [K,K+B] are given when K + B is less than or | equal to the size of the matrix N. When K + B exceeds N, the entries in the | last columns 1 ... B specify the coupling to the first rows. For row K, the | entries [K,K] ... [K,N] [K,1] ... [K,R] are given where R = | mod(K + B - 1, N) + 1. All rows will contain B + 1 entries. To avoid | redundant entries, the bandwidth is limited to B <= int((N - 1) / 2). | | For the case where coupling does not circle back on itself, the process is | modified. Only N columns need to be considered. When K + B finally exceeds | the size of the matrix N, the number of entries in each row starts to | decrease; the last row (row N) has only 1 entry. This construction | constrains the bandwidth to B < N. | | As in the Full_matrix, if all the entries for a particular row do not fit | into a single 80-character line, the entries can be broken across several | lines. | | It is possible to use a bandwidth of 0 to specify a diagonal matrix (a matrix | with no coupling terms.) This is sometimes useful for resistance matrices. | | Sparse_matrix | | A Sparse_matrix is expected to consist mostly of zero-valued entries, except | for a few nonzeros. Unlike the Banded_matrix, there is no restriction on | where the nonzero entries can occur. This feature is useful in certain | situations, such as for Pin Grid Arrays (PGAs). | | As usual, symmetry can be exploited to reduce the amount of data by | eliminating from the matrix any entries below the main diagonal. | | An N x N Sparse_matrix is specified one row at a time, starting with | row 1 and continuing down to row N. Each new row is marked with [Row] | keyword, as in the other matrix formats. | | Data for the entries of a row is given in a slightly different format, | however. For the entry [I, J] of a row, it is necessary to explicitly | list the name of pin J before the value of the entry is given. This | specification serves to indicate to the parser where the entry is put into | the matrix. | | The proper location is not otherwise obvious because of the lack of | restrictions on where nonzeros can occur. Each (Index, Value) pair is | listed upon a separate line. An example follows. Suppose that row 10 | has nonzero entries [10,10], [10,11], [10,15], and [10,25]. The | following row data would be provided: | [Row] 10 | Index Value 10 5.7e-9 11 1.1e-9 15 1.1e-9 25 1.1e-9 | | Note that each of the column indices listed for any row must be | greater than or equal to the row index, because they always come from | the upper half of the matrix. When alphanumeric pin names are used, | special care must be taken to ensure that the ordering defined in the | [Pin Numbers] section is observed. | | With this convention, please note that the N'th row of an | N x N matrix has just a single entry (the diagonal entry). | |============================================================================== | Keyword: [End Package Model] | Required: Yes | Description: Marks the end of a package model description. | Usage Rules: This keyword must come at the end of each complete package | model description. | | Optionally, add a comment after the [End Package Model] keyword | to clarify which package model has just ended. For example, | | [Define Package Model] My_Model | | | | ... content of model ... | | | [End Package Model] | end of My_Model | |----------------------------------------------------------------------------- [End Package Model] | |*============================================================================= |* Keyword: [End Mated Model] |* Required: Yes |* Description: Marks the end of a mated model description. |* Usage Rules: This keyword must come at the end of each complete mated |* model description. |* |* Optionally, add a comment after the [End Package Model] keyword |* to clarify which package model has just ended. For example, |* |* [Define Mated Model] My_Model |* | |* | ... content of model ... |* | |* [End Mated Model] | end of My_Model |* |*---------------------------------------------------------------------------- [End Mated Model] |* |============================================================================== | Package Model Example | | The following is an example of a package model file following the | package modeling specifications. For the sake of brevity, an 8-pin package | has been described. For purposes of illustration, each of the matrices is | specified using a different format. | |============================================================================== | [IBIS Ver] 2.1 [File Name] example.pkg [File Rev] 0.1 [Date] December 13, 1995 [Source] Quality Semiconductors. Data derived from Helmholtz Inc.'s field solver using 3-D Autocad model from Acme Packaging. [Notes] Example of couplings in packaging [Disclaimer] The models given below may not represent any physically realizable 8-pin package. They are provided solely for the purpose of illustrating the .pkg file format. | |============================================================================== | [Define Package Model] QS-SMT-cer-8-pin-pkgs [Manufacturer] Quality Semiconductors Ltd. [OEM] Acme Package Co. [Description] 8-Pin ceramic SMT package [Number of Pins] 8 | [Pin Numbers] 1 2 3 4 5 6 7 8 | [Model Data] | | The resistance matrix for this package has no coupling | [Resistance Matrix] Banded_matrix [Bandwidth] 0 [Row] 1 10.0 [Row] 2 15.0 [Row] 3 15.0 [Row] 4 10.0 [Row] 5 10.0 [Row] 6 15.0 [Row] 7 15.0 [Row] 8 10.0 | | The inductance matrix has loads of coupling | [Inductance Matrix] Full_matrix [Row] 1 3.04859e-07 4.73185e-08 1.3428e-08 6.12191e-09 1.74022e-07 7.35469e-08 2.73201e-08 1.33807e-08 [Row] 2 3.04859e-07 4.73185e-08 1.3428e-08 7.35469e-08 1.74022e-07 7.35469e-08 2.73201e-08 [Row] 3 3.04859e-07 4.73185e-08 2.73201e-08 7.35469e-08 1.74022e-07 7.35469e-08 [Row] 4 3.04859e-07 1.33807e-08 2.73201e-08 7.35469e-08 1.74022e-07 [Row] 5 4.70049e-07 1.43791e-07 5.75805e-08 2.95088e-08 [Row] 6 4.70049e-07 1.43791e-07 5.75805e-08 [Row] 7 4.70049e-07 1.43791e-07 [Row] 8 4.70049e-07 | | The capacitance matrix has sparse coupling | [Capacitance Matrix] Sparse_matrix [Row] 1 1 2.48227e-10 2 -1.56651e-11 5 -9.54158e-11 6 -7.15684e-12 [Row] 2 2 2.51798e-10 3 -1.56552e-11 5 -6.85199e-12 6 -9.0486e-11 7 -6.82003e-12 [Row] 3 3 2.51798e-10 4 -1.56651e-11 6 -6.82003e-12 7 -9.0486e-11 8 -6.85199e-12 [Row] 4 4 2.48227e-10 7 -7.15684e-12 8 -9.54158e-11 [Row] 5 5 1.73542e-10 6 -3.38247e-11 [Row] 6 6 1.86833e-10 7 -3.27226e-11 [Row] 7 7 1.86833e-10 8 -3.38247e-11 [Row] 8 8 1.73542e-10 | [End Model Data] [End Package Model] | |============================================================================== ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: BIRD31.1 is a total rewrite of BIRD31 which proposed connector models split and attached directly on [Component] models. It was impractical, limiting, and burdensome to provide split models. "Mated models" is introduced as a general term to describe connectors, cables and socket. Its electrical format is the same as the package model format. The final form will track any further developments in package model syntax. Thus the mated model text was merged with the existing package model text to form a combined section. The interconnection is based on simulator dependent interfaces. The [Component] pins for the connector footprint must contain reference to Model_names or NC, POWER, or GND. The package model elements can be used to approximate the termination effects if the connector is NOT mated. The mated model elements override these package parameters when the interconnection is made. The electrical model of cables contain the effects of the connectors at both ends along with the cable wire descriptions. For [Components] modeled on sockets, the package model of the [Component] model will be used. Here the simulator interface could distinguish between a connection made to another board, and a connection made to just a component. (3) The mated model introduces the [Define Mated Model] and [End Mated Model] keywords because it differs from the package model in the following ways: (a) It adds optional Cpad_1 and Cpad_2 subparameters for pad capacitance. Most connector model do not include these effects. (b) The mated model is NOT referenced by any [Component] directly. The simulator interface determines how a mated model is connected (or not connected as in the case of an empty socket for optional memory. (c) The mated model must exist only in a separate file since it cannot be determined which mated model file to use if it also exists within a .ibs file. (In contrast, the [Package Model] keyword provides the direct reference, and its model is searched first in the .ibs file and then in any .pkg file.) (d) The mated model contains two columns of pins so that the pins on one side can be defined differently than the pins on the other side. Thus cables which have cross-over connections, or which can be split and feed several different connectors can be described. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: ****************************************************************************** From owner-ibis Fri Mar 22 08:31: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 IAA03183 for ; Fri, 22 Mar 1996 08:31:22 -0800 (PST) Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 22 Mar 96 08:22 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 22 Mar 96 08:25 PST Message-Id: Date: Fri, 22 Mar 96 08:25 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: BIRD34.1 Stored Charge Effects To IBIS Members: BIRD34.1 is submitted in partial response to the verbal comments in the March 8, 1996 meeting. The main comment was that the extraction section was not understandable. This is now illustrated. An alternative method is also illustrated in the ANALYSIS section. The writeup has been modified slightly. Changes are noted by "|*" lines. There are still fundamental concerns about the approach which need to be validated. The following text introduces BIRD34.1 as it did for BIRD34. Because of stored charge, a clamping diode will not release instanteously from the clamped mode as predicted by IBIS models. There will be a delay while the diode is turning off. This creates a glitch which itself can propogate up and down a line. This glitch is significant enough that IBIS needs to include a way to model it. The major contributor to the effect is the TT parameter which produces a non-linear transit time capacitance when a diode is conducting. The proposal here is to add effective parameters defined by [TTgnd] and [TTpower] keywords to the [Model] keyword description. Bob Ross, Interconnectix, Inc. ****************************************************************************** ****************************************************************************** BIRD ID#: 34.1 ISSUE TITLE: Stored Charge Effects REQUESTER: Bob Ross, Interconnectix, Inc. DATE SUBMITTED: 3/5/96, 3/22/96 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: The effect of transit time capacitances is not currently handled in the IBIS format, yet its effects are important for certain simulations. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: Two new keywords [TTgnd] and [TTpower] provide effective transit time parameters for modeling the ground clamp and the power clamp transit time capacitances independently. Approximation equations are included in the description. The additional keywords are described after the [Model] keyword as follows. |============================================================================== | Keywords: [TTgnd], [TTpower] | Required: No | Description: The data for these keywords enters the transist time parameters |* to estimate the transit time capacitances or develop transit |* time capacitance tables for the [Gnd Clamp] | and [Power Clamp] tables. | Usage Rules: For each of these keywords, the three columns hold the transit | values corresponding to the typical, minimum and maximum | [Gnd Clamp] or [Power Clamp] tables, respectively. The | entries for TT(typ), TT(min), and TT(max) must be placed on | a single line and must be separated by at least one white | space or tab or tab character. All three columns are | required under these keywords. However, data is required | only in the typical column. If minimum and/or maximum values | are not available, the reserved word "NA" must be used | indicating the TT(typ) value by default. | Other Notes: The transit time capacitance is added to C_comp. It is | in a Spice reference model as Ct = TT * d(Id)/d(Vd) where | d(Id)/d(Vd) defines the DC conductance at the incremental | DC operating point of the diode, and TT is the transit time. | This expression does not include any series resistance |* component. Such a component is assumed to be negligible in |* practice. Assume that the internal diode current (Id) - | voltage (Vd) relationship is Id = Is * (exp(q(Vd)/kT) - 1) | where Is is the saturation current, q is electron charge, k is | Boltzmann's constant, and T is temperature in degrees Kelvin. | Then d(Id)/d(Vd) is approximately (q/kT) * Id when the diode | is conducting, and zero otherwise. This yields the simplifi- | cation Ct = TT * (q/kT) * Id. The Id is found from the | [Gnd Clamp] and [Power Clamp] operating points, and the cor- | responding TTgnd or TTpower is used to calculate the Ct value. | If the [Temperature] keyword is not defined, then use the | default "typ" temperature for all Ct calculations. | | The effective TT parameter values are intended to APPROXIMATE | the effects. They may be different from the values found in | the Spice diode equations. Refer to the NOTES ON DATA | DERIVATION METHOD for extracting the effective values. |------------------------------------------------------------------------------ | variable TT(typ) TT(min) TT(max) [TTgnd] 10n 12n 9n [TTpower] 12n NA NA | |============================================================================== Add Section (4) to NOTES ON DATA DERIVATION METHOD: | 4) Transit Time Extractions: | The transit time parameter is indirectly derived to be the value that | produces the same effect as that extracted by the reference measurement | or reference simulation. | | The test circuit consists of the following: | a) A pulse source (10 ohms, 1 ns at full duration ramp) or equivalent |* and transitioning between Vcc and 0 V, | b) A 50 ohm, 1 ns long trace or transmission line, | c) A 500 ohm termination to the ground clamp reference voltage for TTgnd | extraction and to the power clamp reference voltage for TTpower | extraction (to provide a convenient, minimum loading 450 ohm - | 50 ohm divider for high-speed sampling equipment observation | of the device under test), and |* d) The device under test (DUT). | |* DUT with [Gnd Clamp] |* ____________ | /| |* o---/\/\/\--O____________)---o--|< |--o GND |* 10 ohms Z0 = 1 nS | | \| | |* TD = 50 ohms | | |* |-/\/\/\-| |* | 500 ohm Load for Probing |* Vcc ---\ ------\ | |* \ \ o /--\ |* 0 V \------ \ / \------- |* | | \---------/ |* 1 nS |<----------->| |* 1 nS, 10 ohm Choose TTgnd that matches the measured |* Source Signal delay with the IBIS model simulation delay |* |* Example of TTgnd Extraction Setup |* | The TTgnd extraction will be done only if a [Gnd Clamp] table exists. | A high to low transition that produces a positive "glitch", perhaps | several nanoseconds later indicates a stored charge in the ground | clamp circuit. The test circuit is simulated using the complete | IBIS model with C_comp and the Ct model defined under the [TTgnd] and | [TTpower] keywords. An effective TTgnd value that produces a "glitch" | with the same delay is extracted. | | Similarily, the TTpower extraction will be done only if a [Power Clamp] | table exists. A low to high transition that produces a negative | "glitch", perhaps several nanoseconds later indicates a stored charge | in the power clamp circuit. An effective TTpower value that produces a | glitch with the same delay is extracted. | | It is preferred to do the extractions with the package parameters | removed. However, if the extraction is done from measurements, then | the package model should be included in the IBIS based simulation. ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: Refer to Spice diode reference information concerning the complete equations. The emission coefficient (N) is assumed to be 1. For measured values or cases where N is not 1, use the effective TT values. So the TT values may not be the exact values used in a Spice model. The Spice diode and transistor models differs slightly from the IBIS Clamp models. The definition and position of the capacitances is different. Furthermore, the IBIS table combines the diode and resistor, but can support more complex non-linear characteristics. Intrinsic RS Diode +-----+ |\ | ----> Id | | ----> Id o---/\/\/\--+--| >|--+----o +-----|Clamp|-----+ | |/ | | | | | | | | o----| +-----+ |----o | | | | | | | | +---| |--+ +-------| |-------+ | | | | Cj + Ct C_comp + Ct Fixed values of C_comp serve to estimate voltage dependent non-linear junction capacitance plus other metalization effects. Note, while shown here across the diode, the C_comp and Ct term would be lumped as capacitances between the terminal and ground to provide an equivalent AC circuit. Methods to connect capacitance contributions to each of the voltage rails are not available in the IBIS model. Note, this example illustrates one diode. It can be connected to the ground reference voltage (usually ground) or to the power reference voltage (usually Vcc) serving as either a [Gnd Clamp] or a [Power Clamp]. In practice, both clamps can exist and C_comp would contain the effects of both diodes and metalization. The Ct value is a function of absolute temperature. As an approximation, the default typical temperature is sufficient if [Temperature] is not specified. It is recommended to include the [Temperature] keyword when TT is specified to remove ambiguity regarding minimum and maximum transit time calculations for CMOS versus Bipolar technologies. An underlying assumption is that the equations will be applied only to the Clamping data, not the combined data that includes [Pulldown] and [Pullup] data. So when this detail is needed for Output models, the clamping data needs to be derived, if not provided. Because of these differences and possible missing details, the simplified equation and approximation approach is justified to capture the dominant behavioral effects. So the TT values may be the effective values that are consistent with the IBIS model and data. There are several formatting choices to describe transit time: (1) A [Model] subparameter similar to Vinl and Vinh, e.g., TTgnd = 12n TTpower = 10n This was not chosen because minimum and maximum process Spice models may have different values. (2) A [Model] subparameter similar to C_comp, e.g., TTgnd 10n 12n 9n TTpower 12n NA NA This was not chosen because the rules for minimum and maximum columns for C_comp are based on magnitude, whereas the rules for TT are based on process extremes. This may be confusing if they are similarly formatted. However, this is the second choice since TTgnd, TTpower and C_comp all relate to capacitances. (3) A [Gnd Clamp] and [Power Clamp] subparameter similar to C_comp, e.g [Gnd Clamp] TT 10n 12n 9n This was not chosen because it can cause unnecessary [Gnd Clamp] and [Power Clamp] table complexity and it can make the TT parameters hard to locate. (4) A [Model] keyword modifier similar to [Temperature] and other keywords which are a function of typical, minimum and maximum process and measurement conditions. e.g., [TTgnd] 10n 12n 9n [TTpower] 12n NA NA Since these keywords are related to the [Gnd Clamp] and [Power Clamp] tables and to the conditions under which they were derived, this format was chosen. BIRD34 also includes in its description a proposed extraction method. The method is based on using the typical input signal transitions. It is also designed so that it can be done under actual measurement conditions since the "real" effect may not be accurately modeled in Spice. An alternative which does not closely reflect actual conditions would be to measure the delay forward biased (perhaps by one volt) clamp diode takes to turn off when the bias voltage is removed or reverse biased. This approach has not been fully simulated. However, it is expected to be very sensitive to the selected bias voltages and not necessarily mimic actual operating conditions. DUT with [Gnd Clamp] 50 ohms | /| Pulse Source o---/\/\/\----o--|< |--o GND -2 V to Vcc | | \| | | | |-/\/\/\-| | 50 ohm Probe Load Vcc/2 /----- /------- / / Without DUT -> / / <- With DUT ___/------/ -1 V | | Choose TTgnd such that measured delay equals IBIS model simulation delay Example of TTgnd Extraction ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: BIRD34 expands EGG9 and adds more detail on modifying IBIS. It also expands on the mathematical basis as requested by Kellee Crisafulli. It also adds some comments based on EGG9 response from Stephen Peters and others on the positioning of C_comp in the ANALYSIS PATH section. ****************************************************************************** From owner-ibis Fri Mar 22 09:34:52 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 JAA03866 for ; Fri, 22 Mar 1996 09:34:48 -0800 (PST) Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 22 Mar 96 09:26 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 22 Mar 96 09:28 PST Message-Id: Date: Fri, 22 Mar 96 09:28 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS EXPRESS INFORMATION MODEL To IBIS Members: Tom Thurman has concerns putting ANSI/EIA-656 (IBIS Version 2.1) on a fast track path for international standardization. His primary objection is the lack of an EXPRESS information based model. Per the discussion at the last meeting, we have invited Tom to participate in the March 29, 1996 meeting to help us understand the EXPRESS information model and what it might take to provide one. Because of his committments that day and because of his interest in physical representations, we have scheduled this discussion after 9:00 A.M PST. Tom's response is attached. Bob Ross, Interconnectix, Inc. Secretary, EIA/IBIS Committee Regarding the proposal to fast track the IBIS spec. I vote no for the following reasons: 1) there is no EXPRESS based information model in the document. 2) there appears to be information in the document that is overlapping with the information in the C/ATLAS document (signal specifications), and perhaps in standard VHDL packages, but there is no information provided to show the relationships to these ANSI standards. 3) some of the information (pin-mapping) appears to be overlapping to that in ISO CD 10303-210 and EDIF 3 0 0. 4) some of the information (package definition) appears to be overlapping to that in ISO CD 10303-210 and EDIF 3 5 0. Item 1 will increase the effort required to interface this important document into the ongoing efforts in WG1, WG3 and ISO/TC184/SC4/JWG9. Item 1 will increase the effort required to review the document during the ballot process, and likely will lessen the quality of the review since reviewers typically aren't funded to develop the required information model necessary for a useful review. I will change my No to a yes if an information model is made available for review by the developers of the IBIS standard. (They have verified that the information model provided meets the domain semantics encoded in the standard.) Regards, Tom -- ===================================================================== | Thomas R. "Tom" Thurman PDES INC. EE TEAM MEMBER | | Principal Engineer | | Rockwell Collins Avionics and Communications Division | | 400 Collins Road N.E. phone:(319)395-2280 | | Cedar Rapids Ia, 52498, USA FAX:(319)395-5429 | | email: trthurma@cacd.rockwell.com | | opinions expressed are those of the author | | and not necessarily of his employer | ===================================================================== From owner-ibis Fri Mar 22 12:21:21 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 MAA04995 for ; Fri, 22 Mar 1996 12:20:53 -0800 (PST) Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 22 Mar 96 12:11 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 22 Mar 96 12:14 PST Message-Id: Date: Fri, 22 Mar 96 12:14 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: IBIS AGENDA 2/29/96 IBIS Open Forum Meeting Agenda for 3/29/96 Bridge Number Reservation # Passcode (916) 356-9200 1-55737 1119667 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/Sign Powell - Progress on ANSI/EIA-656 Publication Rusher 8:25 Administrative and Project Discussions Web Project Update Huq Models at Company Site Golden Parser 2.1 Status Hobbs/Ross S2IBIS 1.3 Status Ross S2IBIS 2.1 Status Ross New Administrative Issues All 8:50 Review of Priorities for 1996 Hobbs, All 9:00 Technical Discussion BIRD31.1 - Connector Models Ross EXPRESS Information Model Ross/Thurman Physical Package Committee Report Peters, etc. (BIRD33, SULTAN, EDIF, BIRD32, etc.) BIRD34.1 - Stored Charge Proposal Progress Ross EGG10 - PARSER TESTS 1-5 Rukusek/Peters New Technical Issues All 9:50 Wrap Up and Next Meetings Plans Hobbs 9:55 Sign Off From owner-ibis Tue Mar 26 14:24:50 1996 Received: from relay3.UU.NET (relay3.UU.NET [192.48.96.8]) by vhdl.vhdl.org (8.7.3/8.7.3) with ESMTP id OAA06127 for ; Tue, 26 Mar 1996 14:24:47 -0800 (PST) Received: from uucp2.UU.NET by relay3.UU.NET with SMTP id QQaitk03304; Tue, 26 Mar 1996 17:12:58 -0500 (EST) Received: from qdt.UUCP by uucp2.UU.NET with UUCP/RMAIL ; Tue, 26 Mar 1996 17:13:49 -0500 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00901; Tue, 26 Mar 96 13:48:56 PST Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA24375; Tue, 26 Mar 96 13:48:56 PST Date: Tue, 26 Mar 96 13:48:56 PST From: jonp@qdt.com (Jon Powell) Message-Id: <9603262148.AA24375@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA01079; Tue, 26 Mar 96 13:48:54 PST To: ibis@vhdl.org Subject: a package syntax Enclosed is a word file that gives an example of a segment oriented electrical description suitable for describing packages, simms, and mcms. This is not meant as (necessarily) a proposal but rather as an example of a known working alternative for package description. This is especially for the package subcommittee (you know who you are). regards, jon #------ cut here ------ cut here ------ cut here ------ #!/bin/csh -f # a shar file for an entire directory # To recreate: # 1) cut at the line above # 2) cd to destination directory # 3) run this file as follows: # csh cat << \SOURCE_END_BIG_LONG_STRING | uudecode begin 666 SOURCE_FILE M'YV0:<2DF?,%SIHS+LB\&0.@H<.'$"-*G$BQHL6+%4%HO%&C!@@ &D'(B.$1 MI,88-&A\#'D21@T8,#7:B"'#!@P;,FC$N!'21LH;(#$*'4JTJ-&C2),J7Q8!7*A8&L(1]0%@ !__Q( ,& Q@$,!$R$T[.#0;$.P__X]]-HP MKMV[>//JW/'CJ4 >#,9 )V@10"XL0Q M#H \%),H:'C'+8(##8$$ (@;EV[#0N@=7C7 H " ?:Z;9A@MD-@$8T\!+(. M5"LJ&G8% '9AT(X,&Y2C;@B([L,KE3V3 4"D,L,Z -H **.9\T,HM@$,61 5 M@ 8 @+XMG[WX871 $HW/)UZ=6NY_[EVFV^W.02%$'7]T9!90U0F'AP / & M& "H 1$N[ & 84.^X*>>&%T]AD 291G1G;A 5#D96E4MEE#,S:$8T-,Y"B1 M@"C >!E0#@[IX- .#O'@$)ASTJGKKKSVZNNOO4I&&667?939 M9I=Y!MI$HI%V9G^L"5C?@ _5=EN,>>T&0&\0 0>1< X19QQRRH$"SB3/11> MCM5%A!UEVG'G79!-DH! @3%'&&6V4X08=(#PA1QJNTU$&&2! ,800(! QT!BSPT%' M&F\$S0 5:;@1!@A,A"''&&^T(88!NG^AQ!-.5#1555=EM5577X4U5EEGI;56 M6YP'#/[4H;?O_OOPQR]_8=R4@@8 5X"3 *ZGDF<17?_(VX&,THZZ/>0,0V'% M10@% &(XA U5$H%;'%$JB% P(K*HX$,RB,$*DD!5.(@("TX% 7@R@8AA @* M([)" .P- $9(8=>@D,+$-:2%#_D#Y@ 0JH;((86X H =4BBKAL BA0\Y8D24 M"!$EP*J)3WR($R/""EO!QR&NL.)#LA@1+L+0(?2P(C0<0@S' 6",#:'$Y )G MQ!UBP2$(T)SI&B*+R36#0$+A(!3-IS:S^(B)FG#(%),R2"E&T2%UC @Q:&5! M#3KD@A!A(E)^^)!4I>8A FB""UH% -8X!!$/F((0+* <3S8$#'18 7248QT? M-<0Z=:"+=73A-NN8C"I6P8I6AL(5KX!%+%J;R&[^%A&P- 1,>+S(;@10C694 M@Q,NV $)G$)$:V !?EPQ:<:@@PXHJ\A:!#M':9AGR- M#PYY(2$<$K:&,*)\#2$'KM@(-H=$H0YAP!T1RC"'-)QA,[9TQ"LEY1#K=.UK M#X$H/??F&WXNKB&H4QWK:A>[V=7N=KG;7>]^%[SA%6]]$=E>+K,ROY8RQBQ@ M&0!^ZL.MAWCK(4:X&P":D ;@O6$.;S #[*[P!CD(="%U:-WK2NB0)DR!J$8E MPD)RB,-%5-J]75[$F ! 9E%V XY"?$(>^7@" M&B"PBDA8\P2SR,8V 8 )MZAM00Z!!#[YVE RFK,A:"Q00]"Q3C Z!&:FB:=; MQ-(0$+CE4B+K&A7<4D\ @,$M8VL(&]Q2MH;@P2WC! @W/)"1+C%;0" A%M\ MH\^&6/1RJ5N=4F$G.]J]#J2ZXYWOY@"\- B/>%/BI[;8T2!^AA8 R%,>\YP' M/>D!8!.84RY$6*/=B/!31TXH:AO"P ;;/M9 0[ >]LR[T(;0A+T X"=/?0I4 MH8+ JB P0U'OFSR%W&$.(,A!_>Z7O_TUI#O^JP@ \_8P AK0(0@4B@(MPD ' M-@02%90@'4FX00X[Q!H>;@B((S)B 'RP(5HX)#DM:4(4JQ@ *8Y(C*G:$#4\ ML6MT>*(-8?SB46BNAP"PQ!.#J(DG%A$ U'AQDB.R9(BXX<@.>7)$I)PB,_I& M&F9\")8CLN4OVFURB44'F#=6N?@ZA!J:>^.((!9.:Y3YCD8I\4.H'!&U]+% M30YD0^A\%#[O&RRYJ@UC\-"8ADBLYPSH,X9:THMU MR*.=QFNG9%2W'.WM1W$7W-X1M+C'+5X#],L&-KSA#LD[ P@& H+ES0'8KP-! M47UK.V+OK@5L2,,:R@ ",AR[I,@% 1W0$ ;849L, QE>LT%J!CE$3]UH('?K MUOT&A3C[#'G =[M!P&X BZ$,K@-!':Z-.S$$_)\!-79!#SIM-X" "DP80K7= M@#LL4&$)^=TO3_)0!N?-P04@2 +!PV 'T#7 (MQEHA[LTP&YYX:8#'=A M[C!P7-UU< -(@=HZ;9L!W^2>!,3)0 E\1QO ;Z@#[.CP!A"<(0TMKS8(6L[Q M_0I=ZG(@;\CE,%XZH/SB^0;!'/+PNC#@P>A.!W 9\! &F/-\VG-P@R2FGO8T MP+RH=/ YWZ/- A"(0>H@"/NZRR 'I(, >K_-ML]K'GG8!=7Q9&AW&%!.A;2? MX0WDA?K1UTWM?:.AW]660QETT( BA&'MZJXZNW]^!M% M%UP>N'&X@P)I<'3F5E"J1P8I\'C1$W/U1V[%MG;G5P8=Z +Q1P5O =O\&]Y M(']I1W4Z^&^T@W^JIW;8=G,_MW9M]W;;-FPHEP2P P?V9@=I<():YP1%0 7: MYE&_A3LGB&R^!P+0MFX@('2PHSRM8W"(%WI5)X5O0(56>&T;)7D_YP87"&!H M2%!CEWAE8 :,YSICH(< ^ :+UW@$* =T('J.-W,\=W)HYW)'6(9UIX?0UFR& M1VX+!U( J'I^V'@ >(B]AUP@)7ZJUP(+UW]W!SUUL']N(&UE-SN!Z(B=1VYV M:&Z2F(9BF :6>' *QW"Q5X'Y]XO91P< Q08I)P1), 4@ (HO ?)4X$7R 8G M%W]8J(5CD'XQD #:J(U\\'C86(;UIVT6MSP$. 8&6'L-X 1/0 1%X(UK$ /E M-CLMUWA4D 50T(X!,1!?0 ;RR'A?D(?<"'T+\7[/=WG\B'6,MXS/^'QC@ ;& M]83(J(P6:&[&R(E_Z :!V !34 1'T 1%X 1:*(?PJ 4Z\!*IHP,BX0(PP#PH MZ0(RL(W=N'/) XES"#MCB ;EUH=AT'[N!G.WXW.!*();1WT+87,]N)$=^9$A MN3HRP)(@$ ,NN8T)P ="AP>P(X>[U0!)X 1$4 5#0 5/( 4@\!)N@ 12V8W7 MYE$&%W4_!VVJAW+/2'H -@:OUW,6UU]U, 94)P<:R9$>"9)&> 8ST !#@#U8 M^)4Y:08[R0:PDXTP&51'5X[G2&Z0)W1ZF6Z?^(PQT'I<68W4F(7N* /IN([M M>(UKT)0'.8\79X_X*! $D9K^F(=]F92 *9(@0))CN9)3@)(RH)).Z9*BB91_ MN91G()I;V95?&99C&0-E.9O#&9B#69A.<)A::&Z*R9,B<9:0N8P%>("463R6 M&8:9:7&B^9%$X)D-T 3YYXRM^(M#$'6L*&WJ20>P2% ^^)VK&'W2=G!T< <( M9W%863LO8(:WJ(?BMW@LF)_1!HSTV5."F&\!EXEX5VW:UX+A-@?Y1GE:!V]F MT(D<=6V763PH%UZV(W!\1VXX&(1O '!&&*(61Y<6QXN9B#OG-WDM0%[%0VXH M<)-1!SNJ&)^]N* (BIMS =E, 8E2'.)N9B)N(+[=9..]Z/ZR:#UB7\_-U[Z MMZ#>!XU%F'W;AWL!V'X$.8X_1U\UFG[<&7;[QGBRF'9,X#IG0(:[IZ8OV'C4 M9ID$-0?.$W!;&J"O V#K-G!R$'1I2EX\9XQ0V@8\:5QW1XCYUGC1IX=OF)"+ MEP:0"J?KQGEIMWR&.GUT)X!J=WK_%7?BB'EI<(#%(W9^FH@VF)Y!0 52D 18 M\ 5-$ 10(!)? 'EDD)=[^07G%SR1F@"B68WN"(_"J92!"8],@)(PX)N]"0,L MD(Z@:9I->:RUN3K*RJS.JI([\)G5J7G&ZI?(*H@/=RIE$ M0*NV&G^U"JNRZK"W.@.Y6CQ?0 =Y8*3P.)C$JE]O$+#/*8?+@9B8+"^"970*JU:"+(SD#HN2YQC(+,K2;,+:YX4&W_OJ:#M.9]5 M>I\)"J2OZ*!SZ7.76'$;%W 'J'KT)E[5!F#.UIZOAW0!QVY99Z2-%W0V!WV8 MBI-#P ),()1BRVYP &!$1V[.9GZ%NJ9RT*9E0+72*'LL]W]\FW7+DX RFXVV;4S*K6'VVZS\W98*I0(JJ=%YP9)=7"-5U3FUGA=:Y%R MD(*_&)>;&HG.2ZEMR'LV MAYEI=X(&=9>O4W6<:HE2NJ @ZGL 5K9W>J1YNJ>_Z(9PV',5>*2S-Q!M,+B& M^FQ0)WVK^HN\*+JD"X#/J*B,R:CXR;22Z[2:2FW?.ZH(2KP4!X"\"(K!FZ.4 M!X#):XR3*@?NEZ7M.0=U( 8MT+S(Y8@;B)'_]Z@]5X0HH(/F%Q!L$'#CY09Y ML()-&XN_V) K>VWY96_=&ZBP([J ^, N-XF!N5L%.FWNAH?2:W[4"X!@B[UW M$ 8!MXE]Z+M:%XB(& ;/.+YW ($P/*&1.\21>'G)8SNJ=WXH9P3[)9=\^'K% M4W@EB'1%6'I%]L]$5S=#JL3XC0!>H@"N^ M@"O,@"OV@"L?X$H@X$J=X$J>X$JGX$K^("?_("" M_1!\3=B!;=B#[1"%K=B'S=B)W1"+#=F-+=F/#0"1;=E_/=F87=F7W=F:?=D3 M,QN$TP *$ %H$ 3@ G^P D% -(R!F<=H1L2ECLAL!8!8G0)E0RXO69J1( M*G83F:0)^7S6%HFFJV_O2[G!Z+_%6X([G':(.Z%V"#N/6\0)9\)AG&WR>YDM M%[\ -@E0$ 13 'Y64 1-%]PSEY#4AJ'/9KR.][^>6GL ME\5&FH-WYSSD5GL _G[M.9'4]]T.MW(?ZH(IH)6C!Z&YB*&_ MJ'H\5Y<_;*%S!XT46>3A-FX;!P)-, 1-L(5:!WY-T 0KN'@6M^*Y:(DUBH@C M?&_DB 9Y4%#VFI/$-^3IQGMB6%3J)Y02"K4[275EIXG)-P?N%X;V)G4SB7)7 M8.=_WGYDH''2)JKD6P>Z2*/14W\.V8HK>* $/J'J2 6MR@!3 M4*M,L+9%@ 5!T 10P 1%P'H(D.W:ONW<[JW%.IKL6*RK>8^Y4P,T\ 5#P 1+ M\ 5/4 54X)SCNCHEBY(T"^\O&[/G"I6;::T\ZY3U+IW4N:38N9GFB9[$2JW@ M7IKIUY3U2.Y08.[HKN[L[N[V3ISSKJX5'YCX3N\NL.\[&Y@]F^\J29B&602( M:9U,*A(,:_#3FGX>2YKNF+,-WXX/?^[ION[M_N[\'I@77^\[+X<;CZX>+[ @ M[^\C#_ F7YTZB9V#6?!9Z.VDOIGJ&.Y1/^XT#_%$\*I!D/$D:_0PP/6K$_10 M.9@_OSHAS_%#/[*K@SLB__5(?_)+SY@@0 ,K__0V6V[@^O53WXY1OY(S7^[G MGO54L/5E?P8][P(U /8P:_2)7_AC@)(B'YTE#_?7*??E&G\0^ZJQ.JNU6K$7 MRW&\NE\>V_+OJ+-$W_4F.[,JF;*DW[*G+^\^B[)W;YHY6_@7?[(TFSOB3=Y% ML+ '_XV%'_0GZP(YP/K6N/"FK_:+G_KP2+/&'_/)'^_+KZU-J>^Z/]Y)4-Z^ M3_HB*_UG#P*XO_JSC_R.'_O./_YK4/L?+X??'_XK&=[8K_W>3JW1_[+MK_KO MO_O97P3/3_OUW^^I[V>)/W\%KOY?8&)[VDH PH#M=_Q.DP%$?0D095T_WM?_ M7-X#A'T!4/810("EF]8?!HR 0"O^"*W.E_DD%N>S5;A*5ZF\#1@&8D '?'W3 M#_RI/AGP_*I>\/-Z,G !3B5W93M04KYB4T'.4AVI,-2GYM4PZBDL:'0-0?AS M]VR@!SP#/>MD-:L84 '3WP5:[? V [C6 P=0 1%,#V$R-$!PEHL$EI($ @!,U M(DL4$!BA)YI#! 4)R)7*(HKD2,B18_H$ "!/CP V^0 ( [ \P0,P!04 M#D0 *# !, :P , H)LT!(C8)? !KL ##( L]HB=*!3PA % *.BFP0" A $ M",1H2"80 4]\Q(>@-8" #",U*&B/02K: X-0%; M 6S)0S =YK ;).[R!4\P )(:6E :0#5Y(T"H5$$(P2H6N@@P( #P; $;K<$!B 4*( =4M$=!%P,C 'B-^P$BU$:[ M,0!P & !0K /1X8?3@ M"-W7 G,3BJ1J,X)X[C>90(6*TV"DCGZ$JJXT/H M#N90.C:$NW@?;:)^M"7DL26^C?\8$0+D !B0RS$V6D<$&1_L8WQ9 $/Q0?+' M\O@0D&.%_!,7,D5F2 !@(#V%/JR,"V516(, 8 ,$0!)( & LA3'_B@4SM6Y MPGQ)H,T=N[DCW^Z.RJ%/5"L)\;KH%L &&'N2-EM*?_F>:(-RIL G'![V:L>Y MPGUUA$*0^%E5BVO@2*A1>)%@1P?30[MJ=K#"?&.IS%8K6C=X:XOAG[VE==+2 M$#(\Q0-W +F*LZOT$E#J.2=J^ORDLI!QA]K;YEMNQ+C](Z?N@. MP)W+%8D46/&P;_4+ZU2AH=,E"P]0&5UYP 9MI%A5!)21M3,"1H#>P8"RM -= M8!G"27A)+^V7+24&\N2AS#VC,@F42N91!% E2LH!+F &-*=#Y0X-E0'V,T 7K'JVI'% &S( 74!->0 ZP 14@ ?R:FM11 MN UP$2G#!PPAEP1@!:HE%4@"'@D$4( 8$ -*TDJ:=A4 \\&UAL !Z@D)J"E()ZT@KJB2NH)\"@GI"#T%(.0DL *"VQ8&\D@[UA M ?Z*+/@KXL!&C ,;00YLQ!E[)6Z# +B-!N V4(#;X %N PJX#3+@-NR V^@# M;L,/N(U#X#9$@=NP!6Y#KD$$H?D0B":<*"9(VT (K8I1-K6'N0#8!%F0+,A* .WX0W #MQ$ X 8' M@!LP &X0 ;B!!>"&&H ;<0!NR &XP0?@1B6 &ZD ;O0"N!$-X$8Y@!OW &[X M [CQ#^"& I ;)$!NX "YP03D1AB0&W1 ;M0!N6$'Y,8=D!N00&[( KE!#>2& M/Y ;_T!N@(#T,$I$2WIH ^GA$:2'6) >MD%ZX ;IP0#4#;%)/\.F_3R;:A-_ MCLVTN3_1IO_,G_RS?NI/ 1I D>9R" 'P &P>T 0JUQ:H F41#'1B0- 'BD I M: 1UH UT@F;0"KI!+Z@&E: <%(1ZT!"*046H!3VA'?2$4@2WT +D9]*H&TN@ M;C"!NG$'ZD8FJ!N]H&[X@KIA#.K&,:@;VZ!N_(.Z407NAA6X&W;@;E2"NV$) M[L8MN!O9X&Z$@[LA#NZ&/;@;&B!O;("\T0/RA@_(&S\@;P"!O!$$!$C>B )Y M8XTUA"J0-ZQ WL ">2,+Y(TMD#>X0-[P GGC"^2-,) WQ$#>6 9Y@QGD#7Z0 M-_H!&S.A*321(M)%6D(;Z0=UI"3TD4K22$I)1Z@E1:&,=))>4D4*23=I)JV@ M=.V 0H$ P$D_Z "]GP7TE*K25,H_(<)MNYPM8#>T">L01(BCUM 16$U'MHFO MT5F>2Z)P*< TF K384I,BZDQC0N&]"VXL;QQQ]X&&ZD ; 0*5(U 4#4H02-[ M9)$LE^VR7D8XAEE#J&8-X9K=$&W&S;P9. MFY0P H#, >C1+:%\3I:3TDWI2 M=_H0],'7M*?Z$Q]\37VJ/_$I_^2GK/1_]D^$1E +JD$]J 8M .R- #!.7NG$ ML!L^HCM0AN]0+\K#9:@93:)GY(PDL1F6!+RX&3Y#2EB$$'(0_<)!ZQH %:&V MA[^@4EMJ5&"I+C6F,@68&E/+QHL0$69A"=##A\ V@$ \^ =HX3T8@/!"=LC+ M%5DH8<# ;(K58!;0PJ9( $B@Y,";]M1#1H-90 !H (D4 M@*]A#%0@$70 M MC(&_L0:(":$XC$UU9&R+J!I0%E25:(U85:M&1ELQ&KZJ%0"K8E6G7(3$$02 M@#SX!Z'@ET7&@5+Y8,>;#?'XB$_P ;;@,F^$SC(;3 ML!H6@&MH#+-A,FRNW? ;AD/I2ET;0CD\A_V0';I#>"@/ZP(]+*D!(R%6A._* M#X^)/WP# %$@EM?6<%[+HWJE"##1(:Y%DC@1*R)4+(ZCD2>*BI#8%"= ?L2( M.?$HDL:*H!1C8H%UD C6* ;8NCA@S>%/W*\T,41&V*A((DLCE="'3!'#!L6G MN&$!;(=EL%7Q*CY&KN@5P:)8Q(QG,2V>!9+H%DU+7+2-"E; WL6\" #V8E]\ M"*T1Q:+'\9$:#N-L 2*,<4VQA4;&2=C9;R,93'&;D:V&%L^8P$(C3/CQ%($ MNW@:N4EJ7(U ]JAN60H)$;2&;*2-.!:D/LR.;?8^>D?P*![I[%2\$V268:A'NE ;W2-\E(_740#4 MQT#[(?.C MB/*Y%'FLW-;Z6F/K;*VMMY7<. '=ZAG$1@Q0MLS6V4*$: M4W0.U%2]& M%=LJU8G!;;VMO*6J]%;JM79-P2W;H: M".XJNAT#_+8B^-N_&E@3A\"->X;5>2#6!X1PBX?"G0@,%[(^W+$0<4TK/4RM MFE7D6LZ@D'&;ZL8="QU7XE(5N&MQYRZ@*+FRE;9ZC92;6Z7';G6Y,/>ARER> MFAJDK6Y:];EM%>@RE:LZ=+EJT3VW8I6LFE5WFU:;[L^5 M-E 7+4A=STMUK6Y>'0I;%^!ZW8&+G0INV"&["=X!6;@%NR! M6_@ HFTV=(+9X EFPRF8#?X @- %$H K!@&NP :XHA_@"A[@2I* *_D#KL00 MN))#X$H@@2NY!:X$&[B2)(F$D#\$+[Q$ 8&D: B31-)($ MD3@2(X)$'$(5$0K 0 &\ $F@ -2%-:@@JL8>5)!6 P @R4/PPX]D#?=A05Q( MW/"D$<.,I2&(89FJ4L>E"Q,V72BD")=SP^>4S8-[-IT0_V0WR\.%NHTD!C?B M)LA1XF0C) ?.NXDWNHCGX(YZ5PG;NE(G.(E MM3".QA$_'@?D;*F14W+NUA-:.5GGY>R?]%9S;@[TL3D[QR[A#F(D=(!=T1EP M26?IJ+AA=P:@#N(!0%<'< VEKM-XO@Y]$CO>I^R<'?^FA (/$XIRU(9(@JJ! M8.D5E1X#L\):S>/*DJ978XB?IH81\'&>"_P:*H/!WJDT:0\ M=J8']7@XUN-Z8(\-$S\@[O;8#MV#"Y$+*LH]Z;+XD)OCD^B83P5[/I%J^E2? MVG%]O%0=X#Y["/P()?+S4\Z4^GDY8LKWW""(_(KO3[71/^&&+OF?7Z2,[XYD M\DX): &ECB3G.I9<[J! )(X-9*#4P8%"$ B*5S^'!)D@@B($51 +$D E*@;= M.=M1@VY0#HK% $=I 2&T?"<]W"862NW8[6PA(>U^Q:"&[*UN4F5/Q9O9% *AR :!A5(R. M43)*4W2@&:6O:$0,?]\[DDH[\ Y*PE)%CKH3.MI[X@XVT2/6-&UJ2E?I"&DEKN25P))8(DMF M"289(;6$)X..GA2"<$E(4ANZ),*@5JS<2XI/\DVGI"?PY)YCXD;;Z2CCULJT M!)_/>'I*=>_=H;]A!?/HGW*V>LU9'REGZ=PZ%)]YSDWH^5G])AD0G)Z@<2+0 MR>E ,RR>>B)@T@8 %2T@ MA;2A7C ]"K,TFF'2/DV MX>:%P.X<<%*-!THA*$=])E,AX7J2>\@"=2GM\Y+!%$Y>='VN3)4?FURWZM1E M?E-O$B<=5KLEW6:8GIIU>PA,#BY-6*CF#:*R.3A)?0T/%Z1M9%>D@CJJJ5)= MJEBMFN&;/";6N6YQ41L3/;Q.U>=1'L8(3+:JB+7YUJ ,:(.A+SK_*D8UDX05 M^L.#Q"E;Y<#T7 5=G_)3UR?K66U!)P@#RY71XPG.CUWQ0'A5)Z^DJ-.294!? M<A8=P]DH6N>9_X& M(&@"6>Y:^@D__/?\<)8<[-@+4 0V;!)(F.#3E.K2L>A+N^P%U:D?#Z&66CZ' M:OE"A+.*L5;7VEK2IFNYN1NVC!(2V8(=/"=6CQ^UQ;88C]N"6\%.(-&M0S2) MG!C>TEM !1G[+:VM=007=L-2@*KJ1*X&E;@F49AL7 #F<1TW*I4&E!LH>U(;QLBY9'ZVA( M/H=[>:]F [[$$4UR8?@K$^;M\\6W+8ZP9E\VCF:SZ38EOU@W_1I>E3M*1RTI M*8KZ%_+*W-IF'CE)YG7 $AB49F#)(R@5H@BFHRA800$^&"QG<[#=_<%.ST_I M/B1L5^?M%/;>6-CX$ERM[G-/+UQ]D<5Q#A/=XMF'+0\@%GB4&+FT;G?)JR8&\!B@EM.)RC.021ACGH M0DEK"">-0Z@TEN;28)I,HVDV#:?I-)[FTX":4"-J1@VI-8REUA":VH6!:E*- MJEFU7'I#N!H7;@AAK2'T@+%6ULY:6EMK;>VMQ37-9C4=0BUO"+<< .1RSU;9 MN.9F0VS W&D*\ZDYS']Y,>?EP9R8*W-COLR1^3'/;)SMLTGS:!X1YJ[B-&VH M3;6QM@4!.0&+;(,(E#,JV#;2X7F[[@#-:1+](K -MTFW)2;YKQNWLV\ MN3?[YM\,G(.S4)/ MZ4D]K2?VU)[ M]^NEM))BTDXZV#5I81?L@7V>&O;$?M@3Z IM""VT;J &"I#::@-Q:$ZE(?Z M4" J1(FH$46B2I2).E$H*D6IJ!7%HEJ4BWI1,"I&R:@9--/;D?]^*.W)?[8F_NT)VP MAU(6,4J/.V#OZP$5I.]U_>E*W0(+3:9?X8(#@&9Z'I]I-)VFU12% P 5#@!8 M^%?8I@ZAFT[Q<%K%&\(VN^(-X9ME<71:)>HG/65L\-2Y(_:(X$\%:H$'Z2D5 MP=_3?8K=X[B#?_ 0_J IU 714+V[P$B\.76GKHW&6W.%:K7-N9-WYS+5*X)Y MIZJT";><5ZYZ7J]Z=$5ONUVZ:,'T9E[4&W15;^>EJT;7]>Y;V L ^BK7#;BT M5^[9WH.;>QMKPXVL$%>JZEV*JWR%[TH@OGC7^.I=D-OD1RX :+XF5_#:UNB[ M6\(7<7A=/WI MYA =NE?Q^@X'8D&LATCQODX$]AI>_V% ]//FU2#:5X7X$/)K@?6O)=;8YE@* M^V'-H4@4L29Q-7)-G5AG)T*#E8F8OB;>Q$C/Z9'MF*WT N#"/^Y8 MU.AC_:*8]?2)%C9V$B.;&"<"8Q0 CK'75C5>Q# +&$MDM%^0#N',LL>)@!L% )LUC6\6. K'_7ML;6VJ#;.+)<\^ MQP$0':?CKG4('!+0FD9!^QW#XW@\M9L6USZ$]7CEV^-[C(^X@D-.VH5?:5$B MKQ/VJ&M9)*@UA[&6U&+:'1GRW_VRS;6L]N#/1W,(:RFM;PR1'Y_E MUUF1GQY)?LPW^;SV16X3KQ!L:^2-S)&U=BA@^&:KX:$MAY^VD+>H2EZD*N)[ M[EH]O4\IZ*;X>\OBKZZ+5[KO]NK/>)%0XY?MC<>W5??H9EV*$'N[[F %N[E# M[!IT?MSDV_>M/)9_OH.7R[-=/OUSVK8C[=C M/_6"_GO;>M4^C_?QLO?M%]:X'W;FOF*M^T8>[R?Y@++D"7_?Q;A0?K1*>;=+ MY0N_WW6MSO?D)G[U_OK_R]O_8W+H ) Z!_(4(4SOX1(@ /X (, [PY4S A84!4X2+ M @ @,(>8P!78!9:!-00;6$/0@34$']A;(()E&B78"9:"K6 MV L6@\U@-=@- MEH/M8#W8#Z;5!&%#6!%VA#4$25A#L(0U!$U80_"$\5\-PQ3&-UAA6)@6=LIY M%I2%($!9D *412E 6;0"E(4K0%D Y0%.8 ?E /X00"0(<0"H44R$%I8 *6% M+%!:P'_SP#A!#XP3+\!? 03\%4G 7T$&_!5XP%_!"/P5H,!?$0W\%>/ 7Z$. M_!7KP%]!#_P5#X"-, +8"#> C; $V A>@(T !]@(=X"-@ ?8"(& C< )V BP M@(U #-@(V("-H [8"/Q /_?/-00.@-MP K@-.X#; ( U!&. VW 'N V)@-L M";@-D8#;P FX#>A >K U WIP/S7%E!W9@$!,$&94*B@ Y4*GH(K0@6U"H8 MED5:<0JJ@JI@*^C8T8*S8"[H"N*"NZ N> OZ@@L",/@*_H*]8#$8"Q8 PB O M2 PN@\%@,<@,#H/-X#.H#$:#U. K& L. ,D@BQ +'@"Z8"Q8"YZ"IF Q.$JA M@MC@+E@WS0!FP30(#:Z#ZF [F TZ@]6@.P@/LH/OH#18#\:#]R ]. _*@\\@ M14 %. 1+0D,0)106 , 71V/0!>4<4>=" 0#@73JE-KP(=@*>H"<08.X$VL W M7 X.03AA_\$8@YQ#P! (A [!!/ !4 #_0"4 "%1+)*%). &$ )1 20@(1($- M 0SP5\0 ?X4,\%?, '\%#?!7U !_A0WP5]P ?P4.\%?D '^%#O!7[ !_!0_P M5_0 ?P5%6"$$,PT!)@ 5 @#&0#!C%N #5B$ H +0-F8!%\ 5]F%?(3#P%0(! MG<)#!0R4A?O!7@$ , %J(22@%E(#:B$& &1 !!)80[ ,N 4*P&PP V M; %NPQK@-KP!;H,OX#8( VZ#-. V3$0-@3G@-J@#PR'<< / #54 W) %P UW M -RP!\ -H@#<8 K #<, W' ,:'4-03H -T <@,%(#?( '(#N-004 %R Q8@ M-_P!D G)#*R W, -R S0@-[P#^ !M'760'A " MZ<$HD!Z< NF!/I >^ /I 0=0-X =<,/4#<, 74#&% WD %U0RA0-Y0"=0,Q M4#<@ W5# =$0Q -UPSU0-U !=X, D#>@!G\#D/@RF'-#8I!() J)2.*1J"0: MB4QBD>@D)HE-(I3X)"Z)4V*42"5*B5CBE:@E6HE<8I7H)6:)76*2*"8" (S% M\9 \E"S41?0@!EP 0X .P 5< 5O)%1"6$ %<0!(0D7P!4, 2< 1@%4_ $& F M2A?-P_.@)E( ;6*=&)$8BLD(GJ@G\HE^8G2!)@J*T@.AZ";:B% 0I1F"04#H]/0*? "L\$_\ =8C'*! M=8 6I%4M$A0I(OT(DS0+F:+^&*W"&3QB_XB P M#@ "XT-5S0V)!Z/-F#8\5 OCLM4P!@ /(T80,8X)$V/%>#%>C"A%R*@TBHS/ MWE 0,@Z,)"/!N%HH%E0C:C P[E\. 7%D.64""D H%;\" ( Q8C]C1/RP#A! M .P-!<#>8 #L#=W WN -[ W?P-[@ OP5,"$ \ G\%=# 7Z$$V A=@(UP#=@( MZ8"-\ ^D!P) W1 "U TD "A8-[ #-6+=X [4#3AB0X /U WY0-V@#\Q/G=V? ML!_<#0G W1 !W TNP-WP MP-,,#=0 /<#37 W6 #W T^P-WP ]P-0,#=$ 3< M#4? W8 $W U)P-W0!-P-3L#=\ 3<#5# W1 %W U2P-TP!=P-/&)=H%/D#4ZA M)T$7F 680\DT'(QW_$2/)SA5CYC#'O,08 Y]S/;X%6"/K0'XZ%A-C_) /]=) M GD^4PPED.D>#T:,A,C]T ;'$^(C+3XQ4P&&$.<(^BC/=( MRGB/IHSWB,IXCZJ,]\C*>(^NC/<(RWB/LHSW2,MXC[;,](C+3(^ZC/>HQ"60 MQ8SW>,QXC\F,][C,>(_-C/>83B60T ,6 />@#G@#M@#_H!!X!!8!!Z!2> 2.$XT@0W!$]@0 MU(U38$-0!38$5Z!IH05R@5X@&"@&DH%F(!JH!K*!;B <* ?2@78@'J@'\H%^ M(" H"!*"AN QX38D@@W!(M@0-((BG-O0/N8'E* EB EJ@IR@)Z@X:G^C8 @P M#H:#]N ^* S:@O@@+%@*YH/4I#X836Z3U20WJ4UVD\W@,9@/\H/@Y#=I3I*3 MUN#(^ YN@]U@.L@*@H.ZX#BH"I:#M^ YZ$Y*D_BD-XE.[I/C9#^93Y:3_.0_ M>4[ZD_KD*>@/ H0.P4#87J@S!R'?4$\HA'4#>+=.R5:.WWCW'TV$>%(Z!*BA"%.V!/^A$'A M4%@4'H5)X5+8%.8-:L!4*!4^!%4A8($5 A9;(6#A%0(6CD!8.!:6A6;!6<@P MJ(5LX4/@%CX$<.'$-Q<^!'4A ' 7TEMZ(5_H%P*&@B%A:!@BAC'<8M@8/H:1 MX618&5Z&F>%FV!G^%8 :"@:DH:F(6JH&K*&KB%L*!O2AK8A;J@;\H:^(7 H M'#8$Q*&^$@>FH?HH7K('KJ' M\"$ (!_J#?7A?9@?R@W\H6WW'P:( V*!>" FB MB@_@@1H@38H6H6ER(&>*& MV"%^B"'BB%@BGH@IXHK8(KZ(,>*,V#C>B#GBCM@C_HA;XI>87(*)RF68N%P^ ME\YE=-E<3I?,974)75*76N*86"8ZBJ:BI\@FNHFVHIPH!=")JN*HN"R6BH&B MIP@JJHK)HJO8*)Z)W>6@F"H>BN5EJT@J5[BEVEBI#A? M5HKUI;+X*E8/LB*M"%X>)[BBKG@R]HJ_(JHC+!*+QJ)KTEXRBLVBO'@RJHM/ M2;V(+185+>-EP 1\B^$B&C N1F?FHLDX!Z",ZZ+*:"^RC/#B%J=BLI@=IHOY M8;Z+^>++V"_^BP$C8,'H%8P,8>0$$2B,Z ,"\#,&C%(T) L:8-'J, M4.; ^#%6!$_C0Q4U1@0:YHK)85*+-N:]&&/JF#'CS%@S_I@XHY#Y$!"9@(61 MZ3 F!4/CD@D B(T1@Y.I,4:95X24>114F2.C=?00! !3(W%$'%F-#Q76F$XL M"&@!U^@U'E530-B83,!_9>,Q@3:JC6RCVP@WRHUTXU]Q-R(6>B/?Z#<"CH(C MX6@X(H[+) # .#8$-B( \#@2EY(CY6@Y8HYU@0%Q-R G*/G"#J*CJ2CZ8@Z MJHZLH^L(.\J.M*/MB#OJCKRC[P@\"H_$H_&(/-X-_\#RR$R>C^L#]$C07 KG M(WF70.8QWJ/VB!%VCQCA'^,]!C+>X_AH.92/"P5KD#Y>$NOC)3%,7A+OH^40 M/TZ/]*/E8#]ZC_FCY; _>H_^H^4 0'J/ Z3E (AA#@BD];A )I -9 +Y0":0 M$60".4%BA!4D1GA!8H09)$:X06*$'21&^$%BA"$D1CA"8H0E)$9X0F*$*21& MN$)BA"VD$MG+G(\Q)$8X0UJ/-21&>$-BA#DD1KA#8H0])$8X40*14R%K,$1: M#D7D)7%$7A))Y"6Q1)*<]-\3V45.D;B(%8E%:I&; 0/01:(%7V2M5%XL &.D M6Q $F)'E!1JYTZV1B,5LX--9#'&D&4 &3 -VY$,0-BP">B1=T$<6"'\D !!( M#I(402&)@#T$I,-M=#KD%N02).:)%1O#A;IT4L Q .:I""NJ%]D#10 +3 #3 MD%D0-O@(9P,\D1G4( K@0HX !,0UZ!Y7DV^ &9)P*6&0R>D&<;"0 ,GH7G^(!X@@BI)^,Y6UH L" '<&19 ' 5E7'S9X17O I? Z?Q&?Q:7P>G\AG\JE\+I_,9_/I?#Z?!A4 end \SOURCE_END_BIG_LONG_STRING cat SOURCE_FILE | uncompress -c | tar xf - unalias rm rm -f SOURCE_FILE exit ( 0 ) From owner-ibis Thu Mar 28 08:53:15 1996 Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by vhdl.vhdl.org (8.7.3/8.7.3) with SMTP id IAA04248 for ; Thu, 28 Mar 1996 08:53:14 -0800 (PST) Message-Id: <199603281653.IAA04248@vhdl.vhdl.org> Received: from BTVLABVM by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 9529; Thu, 28 Mar 96 11:44:02 EST Date: Thu, 28 Mar 96 11:44:10 EST From: "Douglas W. Stout (446-6232)" To: ibis@vhdl.org Subject: help help