From owner-ibis Wed Jul 5 09:21:05 2000 Received: from gatekeep.ti.com (gatekeep.ti.com [192.94.94.61]) by server.eda.org (8.8.5/8.8.3) with ESMTP id JAA21406 for ; Wed, 5 Jul 2000 09:21:05 -0700 (PDT) Received: from dlep6.itg.ti.com ([157.170.188.9]) by gatekeep.ti.com (8.10.1/8.10.1) with ESMTP id e65GIML28898 for ; Wed, 5 Jul 2000 11:18:22 -0500 (CDT) Received: from dlep6.itg.ti.com (localhost [127.0.0.1]) by dlep6.itg.ti.com (8.9.3/8.9.3) with ESMTP id LAA18090 for ; Wed, 5 Jul 2000 11:18:16 -0500 (CDT) Received: from dlep4.itg.ti.com (dlep4.itg.ti.com [157.170.188.63]) by dlep6.itg.ti.com (8.9.3/8.9.3) with ESMTP id LAA18068 for ; Wed, 5 Jul 2000 11:18:16 -0500 (CDT) Received: from ti.com (lta0460542.sh.sc.ti.com [158.218.201.142]) by dlep4.itg.ti.com (8.9.3/8.9.3) with ESMTP id LAA23653 for ; Wed, 5 Jul 2000 11:18:20 -0500 (CDT) Message-ID: <39635F30.DC32C39D@ti.com> Date: Wed, 05 Jul 2000 11:15:44 -0500 From: Stephen Nolan Organization: Texas Instruments Incorporated X-Sender: "Stephen Nolan" <@dshmail.itg.ti.com> (Unverified) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en,ja,ko MIME-Version: 1.0 To: ibis-users@eda.org Subject: Subtracting clamp curves from pull-up/down curves Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello IBIS gurus, When creating a model for a three-state device, it is necessary to subtract the clamp curves from the pull-up/down curves to avoid double counting, as the EDA tool adds the clamp-curves back in to the pull-up/down curves to obtain the devices output charactersitics in the enabled state. Right so far? The question is this, do you only subtract the corresponding clamp curve from the related pull-up/down curve, or do you subtract BOTH clamp curves from each pull-up/down curve? For example, if I am creating the pull-down curve, do I subtract only the ground-clamp curve, or do I subtract both the power-clamp and ground-clamp curves? Does the EDA tool add only the ground-clamp data back in, or does it add both curves back in? -- Regards, Stephen M. Nolan From owner-ibis Wed Jul 5 09:23:22 2000 Received: from gatekeep.ti.com (gatekeep.ti.com [192.94.94.61]) by server.eda.org (8.8.5/8.8.3) with ESMTP id JAA21414 for ; Wed, 5 Jul 2000 09:23:21 -0700 (PDT) Received: from dlep6.itg.ti.com ([157.170.188.9]) by gatekeep.ti.com (8.10.1/8.10.1) with ESMTP id e65GKcL29831 for ; Wed, 5 Jul 2000 11:20:38 -0500 (CDT) Received: from dlep6.itg.ti.com (localhost [127.0.0.1]) by dlep6.itg.ti.com (8.9.3/8.9.3) with ESMTP id LAA19738 for ; Wed, 5 Jul 2000 11:20:33 -0500 (CDT) Received: from dlep4.itg.ti.com (dlep4.itg.ti.com [157.170.188.63]) by dlep6.itg.ti.com (8.9.3/8.9.3) with ESMTP id LAA19726 for ; Wed, 5 Jul 2000 11:20:32 -0500 (CDT) Received: from ti.com (lta0460542.sh.sc.ti.com [158.218.201.142]) by dlep4.itg.ti.com (8.9.3/8.9.3) with ESMTP id LAA25004 for ; Wed, 5 Jul 2000 11:20:37 -0500 (CDT) Message-ID: <39635FB9.3A79AA0C@ti.com> Date: Wed, 05 Jul 2000 11:18:01 -0500 From: Stephen Nolan Organization: Texas Instruments Incorporated X-Sender: "Stephen Nolan" <@dshmail.itg.ti.com> (Unverified) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en,ja,ko MIME-Version: 1.0 To: ibis-users@eda.org Subject: IBIS 3.2 FET switch support (for EDA tool vendors) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit EDA tool vendors, this question is for you. Does your simulation software COMPLETLY support IBIS 3.2 style FET switch models? If "no" then { Do you partially support them? What is your schedule for full implementation? } Thanks. -- Regards, Stephen M. Nolan From owner-ibis Thu Jul 6 09:49:08 2000 Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by server.eda.org (8.8.5/8.8.3) with ESMTP id JAA26691 for ; Thu, 6 Jul 2000 09:49:07 -0700 (PDT) Received: from SMTP (orsmsxvs02-1.jf.intel.com [192.168.65.201]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.30 2000/06/08 18:25:35 dmccart Exp $) with SMTP id JAA06901 for ; Thu, 6 Jul 2000 09:46:52 -0700 (PDT) Received: from orsmsx29.jf.intel.com ([192.168.70.29]) by 192.168.70.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 06 Jul 2000 16:46:52 0000 (GMT) Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2650.21) id <3LP7GNHQ>; Thu, 6 Jul 2000 09:46:50 -0700 Message-ID: <4575832C8E71D111AC4100A0C96B512706458C66@fmsmsx36.fm.intel.com> From: "Muranyi, Arpad" To: ibis-users@eda.org Subject: RE: Subtracting clamp curves from pull-up/down curves Date: Thu, 6 Jul 2000 09:45:10 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Stephen, Here is how I do it. When the buffer is 3-stated, I do two sweeps. One GND relative, and another one Vcc relative. Notice that these two measurements have the same information in them, they are just referenced differently. I also make two measurements when the buffer is driving (provided it is complementary with both pullup and pulldown). The pulldown curve is swept GND relative, and the pullup is swept Vcc relative. I do all four of these sweeps from -Vcc to 2*Vcc. Because of this, both GND and Vcc clamps will be present in all four of the curves. When I subtract, I do pulldown_sweep - GND_rel_3state_sweep => this will be my [Pulldown] pulldup_sweep - Vcc_rel_3state_sweep => this will be my [Pullup] Then I cut off the power clamp part from the GND_rel_3state_sweep and the ground clamp part from the Vcc_rel_3state_sweep data to avoid double counting the clamp currents. That's all you need to do if you have a simple CMOS buffer. I hope this helps, Arpad Muranyi Intel Corporation ===================================================================== -----Original Message----- From: Stephen Nolan [mailto:s-nolan1@ti.com] Sent: Wednesday, July 05, 2000 9:16 AM To: ibis-users@eda.org Subject: Subtracting clamp curves from pull-up/down curves Hello IBIS gurus, When creating a model for a three-state device, it is necessary to subtract the clamp curves from the pull-up/down curves to avoid double counting, as the EDA tool adds the clamp-curves back in to the pull-up/down curves to obtain the devices output charactersitics in the enabled state. Right so far? The question is this, do you only subtract the corresponding clamp curve from the related pull-up/down curve, or do you subtract BOTH clamp curves from each pull-up/down curve? For example, if I am creating the pull-down curve, do I subtract only the ground-clamp curve, or do I subtract both the power-clamp and ground-clamp curves? Does the EDA tool add only the ground-clamp data back in, or does it add both curves back in? -- Regards, Stephen M. Nolan From owner-ibis Fri Jul 7 05:30:32 2000 Received: from mailgate2.Cadence.COM (mailgate2.Cadence.COM [158.140.2.31]) by server.eda.org (8.8.5/8.8.3) with ESMTP id FAA01199 for ; Fri, 7 Jul 2000 05:30:32 -0700 (PDT) Received: from zip.Cadence.COM (zip.Cadence.COM [158.140.103.36]) by mailgate2.Cadence.COM (8.9.3/8.9.3) with ESMTP id FAA06245 for ; Fri, 7 Jul 2000 05:28:16 -0700 (PDT) Received: from cadence.com (d15814010530 [158.140.105.30]) by zip.Cadence.COM (8.9.3/8.8.5) with ESMTP id IAA20357 for ; Fri, 7 Jul 2000 08:28:08 -0400 (EDT) Message-ID: <3965CCC6.E86F43A9@cadence.com> Date: Fri, 07 Jul 2000 08:27:50 -0400 From: Mike LaBonte Organization: Cadence Design Systems, Inc. X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ibis-users@eda.org Subject: Re: Subtracting clamp curves from pull-up/down curves References: <39635F30.DC32C39D@ti.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Received: By mailgate2.Cadence.COM as FAA06245 at Fri Jul 7 05:28:16 2000 Stephen, Arpad's reply indicates that both clamp curves are indeed subtracted to produce pullup and pulldown curves. I can verify the other side of your question; that simulators (at least Cadence SPECCTRAQuest) re-combine the curves as follows: low state: pulldown + powerclamp + groundclamp high state: pullup + powerclamp + groundclamp So the clamps are never disabled (unless Submodel is used). Mike LaBonte Cadence Stephen Nolan wrote: > > Hello IBIS gurus, > > When creating a model for a three-state device, it is necessary to subtract the > clamp curves from the pull-up/down curves to avoid double counting, as the EDA > tool adds the clamp-curves back in to the pull-up/down curves to obtain the > devices output charactersitics in the enabled state. Right so far? > > The question is this, do you only subtract the corresponding clamp curve from > the related pull-up/down curve, or do you subtract BOTH clamp curves from each > pull-up/down curve? > > For example, if I am creating the pull-down curve, do I subtract only the > ground-clamp curve, or do I subtract both the power-clamp and ground-clamp > curves? Does the EDA tool add only the ground-clamp data back in, or does it add > both curves back in? > > -- > Regards, > Stephen M. Nolan From owner-ibis Fri Jul 7 07:21:07 2000 Received: from geneva.cereva.com (fwuser@ip03.datx.com [209.213.90.252]) by server.eda.org (8.8.5/8.8.3) with ESMTP id HAA01544 for ; Fri, 7 Jul 2000 07:21:05 -0700 (PDT) Message-ID: <3D60630D3600D411896F0090278D4E483CC8C7@spawn.cereva.com> From: "Haller, Robert" To: "'Mike LaBonte'" Cc: ibis-users@eda.org Subject: RE: Subtracting clamp curves from pull-up/down curves Date: Fri, 7 Jul 2000 10:16:56 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Mike, Not trying to play devil's advocate, but I have always wondered why the model maker has to subtract the clamps out, then the software vendor puts the clamps back in ? Why not just have syntax (in IBIS) for a pullup and pulldown model WITH the clamp ? Thus reducing everyone's work ? My old (internal) simulator and models were defined this way (IV curves included clamps) and it seemed a lot easier. We could feed bench data from a curve tracer (or semiconductor analyzer) directly into the model without any math, and when you looked model curves they were intuitive. I know its probably now water over the dam, but I was just wondering.... regards, Bob Cereva Networks 100 Locke Drive Marlboro MA. 01752 Phone: 508-486-9660 X 3365 FAX: 508-486-9661 Email: rhaller@cereva.com -----Original Message----- From: Mike LaBonte [mailto:mikelabonte@cadence.com] Sent: Friday, July 07, 2000 8:28 AM To: ibis-users@eda.org Subject: Re: Subtracting clamp curves from pull-up/down curves Stephen, Arpad's reply indicates that both clamp curves are indeed subtracted to produce pullup and pulldown curves. I can verify the other side of your question; that simulators (at least Cadence SPECCTRAQuest) re-combine the curves as follows: low state: pulldown + powerclamp + groundclamp high state: pullup + powerclamp + groundclamp So the clamps are never disabled (unless Submodel is used). Mike LaBonte Cadence Stephen Nolan wrote: > > Hello IBIS gurus, > > When creating a model for a three-state device, it is necessary to subtract the > clamp curves from the pull-up/down curves to avoid double counting, as the EDA > tool adds the clamp-curves back in to the pull-up/down curves to obtain the > devices output charactersitics in the enabled state. Right so far? > > The question is this, do you only subtract the corresponding clamp curve from > the related pull-up/down curve, or do you subtract BOTH clamp curves from each > pull-up/down curve? > > For example, if I am creating the pull-down curve, do I subtract only the > ground-clamp curve, or do I subtract both the power-clamp and ground-clamp > curves? Does the EDA tool add only the ground-clamp data back in, or does it add > both curves back in? > > -- > Regards, > Stephen M. Nolan From owner-ibis Fri Jul 7 08:10:29 2000 Received: from mailgate2.Cadence.COM (mailgate2.Cadence.COM [158.140.2.31]) by server.eda.org (8.8.5/8.8.3) with ESMTP id IAA01711 for ; Fri, 7 Jul 2000 08:10:28 -0700 (PDT) Received: from gda.Cadence.COM (gda.Cadence.COM [158.140.106.10]) by mailgate2.Cadence.COM (8.9.3/8.9.3) with ESMTP id IAA17509; Fri, 7 Jul 2000 08:08:14 -0700 (PDT) Received: from cadence.com (d158140105215 [158.140.105.215]) by gda.Cadence.COM (8.8.8/8.8.5) with ESMTP id LAA21997; Fri, 7 Jul 2000 11:07:57 -0400 (EDT) Message-ID: <3965F233.B7BDDF02@cadence.com> Date: Fri, 07 Jul 2000 11:07:31 -0400 From: Ian Dodd Organization: Cadence Design Systems, Inc. X-Mailer: Mozilla 4.7 [en]C-CCK-MCD (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Haller, Robert" CC: "'Mike LaBonte'" , ibis-users@eda.org Subject: Re: Subtracting clamp curves from pull-up/down curves References: <3D60630D3600D411896F0090278D4E483CC8C7@spawn.cereva.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Received: By mailgate2.Cadence.COM as IAA17509 at Fri Jul 7 08:08:14 2000 Bob, I think there are two obvious reasons for keeping the clamps separate: 1. It was intended that models be usable for a range of supply voltages with the pull-up and power clamps tracking with the supply voltage and the pull-down and ground clamps tracking with the ground rail. This was also the rational for referencing the former to the supply voltage. 2. Separating the clamps from the pull-up/down allows modeling of high/low/tristate for devices that support these modes. Recent feedback has indicated that the characteristics of many devices change markedly with supply voltage, so using an IBIS model for a supply voltage other than at which it was designed, can give inaccurate results Ian Dodd Cadence Design Systems "Haller, Robert" wrote: > > Mike, > Not trying to play devil's advocate, but I have always wondered > why the model maker has to subtract the clamps out, then the software vendor > > puts the clamps back in ? Why not just have syntax (in IBIS) for a pullup > and pulldown model WITH the clamp ? Thus reducing everyone's work ? > > My old (internal) simulator and models were defined this way (IV curves > included clamps) > and it seemed a lot easier. We could feed bench data from a curve tracer (or > semiconductor analyzer) > directly into the model without any math, and when you looked model curves > they were intuitive. > I know its probably now water over the dam, but I was just wondering.... > > regards, > Bob > > Cereva Networks > 100 Locke Drive > Marlboro MA. 01752 > Phone: 508-486-9660 X 3365 > FAX: 508-486-9661 > Email: rhaller@cereva.com > > -----Original Message----- > From: Mike LaBonte [mailto:mikelabonte@cadence.com] > Sent: Friday, July 07, 2000 8:28 AM > To: ibis-users@eda.org > Subject: Re: Subtracting clamp curves from pull-up/down curves > > Stephen, > > Arpad's reply indicates that both clamp curves are indeed subtracted > to produce pullup and pulldown curves. I can verify the other side of > your question; that simulators (at least Cadence SPECCTRAQuest) > re-combine the curves as follows: > > low state: pulldown + powerclamp + groundclamp > high state: pullup + powerclamp + groundclamp > > So the clamps are never disabled (unless Submodel is used). > > Mike LaBonte > Cadence > > Stephen Nolan wrote: > > > > Hello IBIS gurus, > > > > When creating a model for a three-state device, it is necessary to > subtract the > > clamp curves from the pull-up/down curves to avoid double counting, as the > EDA > > tool adds the clamp-curves back in to the pull-up/down curves to obtain > the > > devices output charactersitics in the enabled state. Right so far? > > > > The question is this, do you only subtract the corresponding clamp curve > from > > the related pull-up/down curve, or do you subtract BOTH clamp curves from > each > > pull-up/down curve? > > > > For example, if I am creating the pull-down curve, do I subtract only the > > ground-clamp curve, or do I subtract both the power-clamp and ground-clamp > > curves? Does the EDA tool add only the ground-clamp data back in, or does > it add > > both curves back in? > > > > -- > > Regards, > > Stephen M. Nolan From owner-ibis Fri Jul 7 08:56:17 2000 Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by server.eda.org (8.8.5/8.8.3) with ESMTP id IAA01892 for ; Fri, 7 Jul 2000 08:56:16 -0700 (PDT) Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.30 2000/06/08 18:25:35 dmccart Exp $) with SMTP id PAA05576 for ; Fri, 7 Jul 2000 15:54:57 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 07 Jul 2000 15:54:03 0000 (GMT) Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 7 Jul 2000 08:54:01 -0700 Message-ID: <4575832C8E71D111AC4100A0C96B512706458C69@fmsmsx36.fm.intel.com> From: "Muranyi, Arpad" To: ibis-users@eda.org Subject: RE: Subtracting clamp curves from pull-up/down curves Date: Fri, 7 Jul 2000 08:54:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Bob, Even though Ian is correct, the real reason is TRANSIENT. As it was pointed out earlier, the clamp currents are static, i.e. they are not changing while the buffer is 3-stated, driving high or low. Now, think how do you go from a 3-stated condition to driving low, for example. You need to add something to the always present clamp currents to get to the IV curve that is the SUM of the clamps and the pulldown device. However, you have to add this extra driving current gradually, governed by either the ramp, or Vt curve. It is fairly easy to scale the difference curve during this transition time while adding it to the constant clamp curves. If you, say, made a model with a clamp curve, and a SUM curve, as you proposed, you would have to find a way to cross-fade the two during this transition in such a way that the clamping portion would remain constant during that time. I am not sure if you can do that easily. Of course, the fundamental question is how much should the model maker, or the tool do. It would be easier on the model maker to just generate easy IV curves and let the tool do the subtraction and then summation. The same way, it would have been easier to just describe all IV curves in a ground relative manner and let the tool do the conversions. When we wrote the spec I was pushing for the difference curves and the Vcc relative pullup and power clamp curves to make sure that the tools use them correctly. The neat thing about Vcc relative IV curve is that they lend themselves to be used directly (easily) in situations when power and ground bounce, return path, and power delivery are of interest. These are big buzzwords in some circles today, yet many simulators are still not able to deal with them correctly, BECAUSE they are ground referenced for everything, even the pullup IV curves. (Can you imagine a pullup transistor, who's current comes from the ground pin?) Another reason I was pushing for these types of IV curves was that I had a behavioral model in HSPICE using controlled sources and it was easier to use them if the IV curves were in this form. I felt that if it was easier to do it that way in HSPICE with the controlled sources, it should also be easier in other tools. In retrospect I feel that yes, we could have made it easier on the model maker. We would have been able to avoid all these questions and confusions. But, I believe we would have had even more and bigger "tool differences", opening the door for endless arguments and explanations on which tool is doing things right or wrong. Which one would you have preferred? I honestly don't know which situation would have been better. I hope this helps to clarify your questions. Arpad ========================================================================= -----Original Message----- From: Ian Dodd [mailto:idodd@cadence.com] Sent: Friday, July 07, 2000 8:08 AM To: Haller, Robert Cc: 'Mike LaBonte'; ibis-users@eda.org Subject: Re: Subtracting clamp curves from pull-up/down curves Bob, I think there are two obvious reasons for keeping the clamps separate: 1. It was intended that models be usable for a range of supply voltages with the pull-up and power clamps tracking with the supply voltage and the pull-down and ground clamps tracking with the ground rail. This was also the rational for referencing the former to the supply voltage. 2. Separating the clamps from the pull-up/down allows modeling of high/low/tristate for devices that support these modes. Recent feedback has indicated that the characteristics of many devices change markedly with supply voltage, so using an IBIS model for a supply voltage other than at which it was designed, can give inaccurate results Ian Dodd Cadence Design Systems "Haller, Robert" wrote: > > Mike, > Not trying to play devil's advocate, but I have always wondered > why the model maker has to subtract the clamps out, then the software vendor > > puts the clamps back in ? Why not just have syntax (in IBIS) for a pullup > and pulldown model WITH the clamp ? Thus reducing everyone's work ? > > My old (internal) simulator and models were defined this way (IV curves > included clamps) > and it seemed a lot easier. We could feed bench data from a curve tracer (or > semiconductor analyzer) > directly into the model without any math, and when you looked model curves > they were intuitive. > I know its probably now water over the dam, but I was just wondering.... > > regards, > Bob > > Cereva Networks > 100 Locke Drive > Marlboro MA. 01752 > Phone: 508-486-9660 X 3365 > FAX: 508-486-9661 > Email: rhaller@cereva.com > > -----Original Message----- > From: Mike LaBonte [mailto:mikelabonte@cadence.com] > Sent: Friday, July 07, 2000 8:28 AM > To: ibis-users@eda.org > Subject: Re: Subtracting clamp curves from pull-up/down curves > > Stephen, > > Arpad's reply indicates that both clamp curves are indeed subtracted > to produce pullup and pulldown curves. I can verify the other side of > your question; that simulators (at least Cadence SPECCTRAQuest) > re-combine the curves as follows: > > low state: pulldown + powerclamp + groundclamp > high state: pullup + powerclamp + groundclamp > > So the clamps are never disabled (unless Submodel is used). > > Mike LaBonte > Cadence > > Stephen Nolan wrote: > > > > Hello IBIS gurus, > > > > When creating a model for a three-state device, it is necessary to > subtract the > > clamp curves from the pull-up/down curves to avoid double counting, as the > EDA > > tool adds the clamp-curves back in to the pull-up/down curves to obtain > the > > devices output charactersitics in the enabled state. Right so far? > > > > The question is this, do you only subtract the corresponding clamp curve > from > > the related pull-up/down curve, or do you subtract BOTH clamp curves from > each > > pull-up/down curve? > > > > For example, if I am creating the pull-down curve, do I subtract only the > > ground-clamp curve, or do I subtract both the power-clamp and ground-clamp > > curves? Does the EDA tool add only the ground-clamp data back in, or does > it add > > both curves back in? > > > > -- > > Regards, > > Stephen M. Nolan From owner-ibis Fri Jul 7 12:43:42 2000 Received: from mailgate.Cadence.COM (mailgate.Cadence.COM [158.140.2.1]) by server.eda.org (8.8.5/8.8.3) with ESMTP id MAA02501 for ; Fri, 7 Jul 2000 12:43:42 -0700 (PDT) Received: from gda.Cadence.COM (gda.Cadence.COM [158.140.106.10]) by mailgate.Cadence.COM (8.9.3/8.9.3) with ESMTP id MAA06881; Fri, 7 Jul 2000 12:41:25 -0700 (PDT) Received: from pc-toddw3 (d158140105159 [158.140.105.159]) by gda.Cadence.COM (8.8.8/8.8.5) with ESMTP id PAA04741; Fri, 7 Jul 2000 15:41:23 -0400 (EDT) Message-Id: <4.2.0.58.20000707153102.0146e460@gda.cadence.com> X-Sender: toddw@gda.cadence.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 07 Jul 2000 15:31:52 -0400 To: Ian Dodd , "Haller, Robert" From: Todd Westerhoff Subject: Re: Subtracting clamp curves from pull-up/down curves Cc: "'Mike LaBonte'" , ibis-users@eda.org In-Reply-To: <3965F233.B7BDDF02@cadence.com> References: <3D60630D3600D411896F0090278D4E483CC8C7@spawn.cereva.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_3491200==_.ALT" X-Received: By mailgate.Cadence.COM as MAA06881 at Fri Jul 7 12:41:25 2000 --=====================_3491200==_.ALT Content-Type: text/plain; charset="us-ascii" My $0.02: >2. Separating the clamps from the pull-up/down allows modeling of >high/low/tristate for devices that support these modes. Is the right answer. Thanks, Ian! Todd. Todd Westerhoff Product Marketing Director | High Speed Systems Design | Performance Engineering Cadence Design Systems | 270 Billerica Road | Chelmsford, MA 01824 ph: (978) 262-6327 fx: (978) 446-6798 email: toddw@cadence.com internal information website: http://www-ma.cadence.com/~toddw --=====================_3491200==_.ALT Content-Type: text/html; charset="us-ascii" My $0.02:

2. Separating the clamps from the pull-up/down allows modeling of
high/low/tristate for devices that support these modes.

Is the right answer.

Thanks, Ian!

Todd.



   Todd Westerhoff
   Product Marketing Director | High Speed Systems Design | Performance Engineering
   Cadence Design Systems | 270 Billerica Road | Chelmsford, MA  01824
  
   ph: (978) 262-6327
   fx: (978) 446-6798
   email: toddw@cadence.com
   internal information website: http://www-ma.cadence.com/~toddw --=====================_3491200==_.ALT-- From owner-ibis Fri Jul 7 12:57:08 2000 Received: from mailgate.Cadence.COM (mailgate.Cadence.COM [158.140.2.1]) by server.eda.org (8.8.5/8.8.3) with ESMTP id MAA02570 for ; Fri, 7 Jul 2000 12:57:07 -0700 (PDT) Received: from mailhub.Cadence.COM (mailhub.Cadence.COM [158.140.128.33]) by mailgate.Cadence.COM (8.9.3/8.9.3) with ESMTP id MAA08048; Fri, 7 Jul 2000 12:54:53 -0700 (PDT) Received: from pc-donaldt (sj6-lras-245035 [158.140.245.35]) by mailhub.Cadence.COM (8.9.3+Sun/8.8.5) with SMTP id MAA01818; Fri, 7 Jul 2000 12:54:52 -0700 (PDT) Message-Id: <3.0.3.32.20000707125432.00a39a00@eudora1.cadence.com> X-Sender: donaldt@eudora1.cadence.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 07 Jul 2000 12:54:32 -0700 To: "Haller, Robert" , Ian Dodd From: Donald Telian Subject: Re: Subtracting clamp curves from pull-up/down curves Cc: "'Mike LaBonte'" , ibis-users@eda.org In-Reply-To: <3965F233.B7BDDF02@cadence.com> References: <3D60630D3600D411896F0090278D4E483CC8C7@spawn.cereva.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Received: By mailgate.Cadence.COM as MAA08048 at Fri Jul 7 12:54:53 2000 Bob, Perhaps I can provide some background. We knew we had to support models of devices in tri-state, so that required the implementation of a standalone (not embedded in the output curves) clamp section in IBIS. If it was embedded, the EDA tool builder would not have had enough data to figure out exactly how to remove the tri-state clamp from the output characteristic. Given that we had to have a clamp curve, the choice then was whether or not to have the same curve embedded in the output curve too. The decision on this was based on our view at the time of how an IBIS "template" or "macro" circuit would be built. Our view was that the circuit would have separate circuit elements for both "driver" and "clamp" primarily because one of them had to have the ability to be turned "off" (for tri-state). (And actually, if you read closely, we did allow provision for an output only device to have the embedding.) So two curves were required, and we decided to NOT have overlap in the clamp data. That way the data could just be directly applied to the macro circuit without anyone mucking with it. Stepping back and looking at it, either the model maker or the EDA tool would have to do the subtraction in a typical macro implementation. I guess we opted to put the burden on the model maker. In hindsight, this may have required 100 companies to have to learn the process rather than 10. What we have now is simply convention. But this is the history, as I recall it. Donald T. CADENCE At 11:07 AM 07/07/2000 -0400, Ian Dodd wrote: >Bob, > >I think there are two obvious reasons for keeping the clamps separate: > >1. It was intended that models be usable for a range of supply voltages >with the pull-up and power clamps tracking with the supply voltage >and the pull-down and ground clamps tracking with the ground rail. >This was also the rational for referencing the former to the supply voltage. > >2. Separating the clamps from the pull-up/down allows modeling of >high/low/tristate >for devices that support these modes. > >Recent feedback has indicated that the characteristics of many devices change >markedly with supply voltage, so using an IBIS model for a supply voltage >other than at which it was designed, can give inaccurate results > >Ian Dodd >Cadence Design Systems > > > > >"Haller, Robert" wrote: >> >> Mike, >> Not trying to play devil's advocate, but I have always wondered >> why the model maker has to subtract the clamps out, then the software vendor >> >> puts the clamps back in ? Why not just have syntax (in IBIS) for a pullup >> and pulldown model WITH the clamp ? Thus reducing everyone's work ? >> >> My old (internal) simulator and models were defined this way (IV curves >> included clamps) >> and it seemed a lot easier. We could feed bench data from a curve tracer (or >> semiconductor analyzer) >> directly into the model without any math, and when you looked model curves >> they were intuitive. >> I know its probably now water over the dam, but I was just wondering.... >> >> regards, >> Bob >> >> Cereva Networks >> 100 Locke Drive >> Marlboro MA. 01752 >> Phone: 508-486-9660 X 3365 >> FAX: 508-486-9661 >> Email: rhaller@cereva.com >> >> -----Original Message----- >> From: Mike LaBonte [mailto:mikelabonte@cadence.com] >> Sent: Friday, July 07, 2000 8:28 AM >> To: ibis-users@eda.org >> Subject: Re: Subtracting clamp curves from pull-up/down curves >> >> Stephen, >> >> Arpad's reply indicates that both clamp curves are indeed subtracted >> to produce pullup and pulldown curves. I can verify the other side of >> your question; that simulators (at least Cadence SPECCTRAQuest) >> re-combine the curves as follows: >> >> low state: pulldown + powerclamp + groundclamp >> high state: pullup + powerclamp + groundclamp >> >> So the clamps are never disabled (unless Submodel is used). >> >> Mike LaBonte >> Cadence >> >> Stephen Nolan wrote: >> > >> > Hello IBIS gurus, >> > >> > When creating a model for a three-state device, it is necessary to >> subtract the >> > clamp curves from the pull-up/down curves to avoid double counting, as the >> EDA >> > tool adds the clamp-curves back in to the pull-up/down curves to obtain >> the >> > devices output charactersitics in the enabled state. Right so far? >> > >> > The question is this, do you only subtract the corresponding clamp curve >> from >> > the related pull-up/down curve, or do you subtract BOTH clamp curves from >> each >> > pull-up/down curve? >> > >> > For example, if I am creating the pull-down curve, do I subtract only the >> > ground-clamp curve, or do I subtract both the power-clamp and ground-clamp >> > curves? Does the EDA tool add only the ground-clamp data back in, or does >> it add >> > both curves back in? >> > >> > -- >> > Regards, >> > Stephen M. Nolan > > Donald Telian PCB Systems Division Cadence Design Systems phone: 408-944-7791 donaldt@cadence.com From owner-ibis Fri Jul 7 13:24:55 2000 Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by server.eda.org (8.8.5/8.8.3) with ESMTP id NAA02707 for ; Fri, 7 Jul 2000 13:24:55 -0700 (PDT) Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.30 2000/06/08 18:25:35 dmccart Exp $) with SMTP id UAA10439 for ; Fri, 7 Jul 2000 20:23:36 GMT Received: from fmsmsx18.intel.com ([132.233.48.18]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 07 Jul 2000 20:22:41 0000 (GMT) Received: by fmsmsx18.fm.intel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 7 Jul 2000 13:22:40 -0700 Message-ID: <4575832C8E71D111AC4100A0C96B512706458C6B@fmsmsx36.fm.intel.com> From: "Muranyi, Arpad" To: ibis-users@eda.org Subject: RE: Subtracting clamp curves from pull-up/down curves Date: Fri, 7 Jul 2000 13:22:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFE851.18E7089E" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFE851.18E7089E Content-Type: text/plain; charset="windows-1252" Todd, This is true, but we could have also decided to give curves on "as measured" bases. For 3-statable buffers then a model would consist of a 3-stated curve, a Driving_Low curve, and a Driving_High curve. Note that the clamps are present in each of these, and if nothing is done about it, double or triple counting could happen. This was one of the items we worried about and wanted to prevent. Don gave another good summary on the history, and why and how this subtract stuff came about. Arpad ========================================================== -----Original Message----- From: Todd Westerhoff [mailto:toddw@cadence.com] Sent: Friday, July 07, 2000 12:32 PM To: Ian Dodd; Haller, Robert Cc: 'Mike LaBonte'; ibis-users@eda.org Subject: Re: Subtracting clamp curves from pull-up/down curves My $0.02: 2. Separating the clamps from the pull-up/down allows modeling of high/low/tristate for devices that support these modes. Is the right answer. Thanks, Ian! Todd. Todd Westerhoff Product Marketing Director | High Speed Systems Design | Performance Engineering Cadence Design Systems | 270 Billerica Road | Chelmsford, MA 01824 ph: (978) 262-6327 fx: (978) 446-6798 email: toddw@cadence.com internal information website: http://www-ma.cadence.com/~toddw ------_=_NextPart_001_01BFE851.18E7089E Content-Type: text/html; charset="windows-1252"
Todd,
 
This is true, but we could have also decided to give curves
on "as measured" bases.  For 3-statable buffers then a model
would consist of a 3-stated curve, a Driving_Low curve, and
a Driving_High curve.  Note that the clamps are present in
each of these, and if nothing is done about it, double or
triple counting could happen.  This was one of the items
we worried about and wanted to prevent.
 
Don gave another good summary on the history, and why and how
this subtract stuff came about.
 
Arpad
==========================================================
 
 
 
-----Original Message-----
From: Todd Westerhoff [mailto:toddw@cadence.com]
Sent: Friday, July 07, 2000 12:32 PM
To: Ian Dodd; Haller, Robert
Cc: 'Mike LaBonte'; ibis-users@eda.org
Subject: Re: Subtracting clamp curves from pull-up/down curves

My $0.02:

2. Separating the clamps from the pull-up/down allows modeling of
high/low/tristate for devices that support these modes.

Is the right answer.

Thanks, Ian!

Todd.



   Todd Westerhoff
   Product Marketing Director | High Speed Systems Design | Performance Engineering
   Cadence Design Systems | 270 Billerica Road | Chelmsford, MA  01824
  
   ph: (978) 262-6327
   fx: (978) 446-6798
   email: toddw@cadence.com
   internal information website: http://www-ma.cadence.com/~toddw ------_=_NextPart_001_01BFE851.18E7089E-- From owner-ibis Sun Jul 9 10:48:28 2000 Received: from spiff.al.dynip.com (root@209-63-189-86.sea.jps.net [209.63.189.86]) by server.eda.org (8.8.5/8.8.3) with ESMTP id KAA09475 for ; Sun, 9 Jul 2000 10:48:27 -0700 (PDT) Received: from spiff.al.dynip.com (al@localhost [127.0.0.1]) by spiff.al.dynip.com (8.9.3/8.9.3) with SMTP id KAA08861; Sun, 9 Jul 2000 10:47:10 -0700 From: Al Davis To: Stephen Nolan , ibis-users@eda.org Subject: Re: Subtracting clamp curves from pull-up/down curves Date: Sun, 9 Jul 2000 00:15:09 -0700 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain References: <39635F30.DC32C39D@ti.com> In-Reply-To: <39635F30.DC32C39D@ti.com> MIME-Version: 1.0 Message-Id: <00070900410302.01089@spiff.al.dynip.com> Content-Transfer-Encoding: 8bit As everyone else said, subtract them both. But there is more to it than that. I have a comment and a question. The comment ..... When you subtract, remember to consider the accuracy of the measurements. In the usual case, in the region where the clamp is strong, the things you are subtracting are nearly equal and large, producing a result near zero. In most models, the resulting pullup/pulldown in this region is ALL NOISE. Those models that look like they have a negative resistance region there are WRONG. The literature says that it doesn't matter because they are added back by the simulator, but that is not the whole story. You are better off leaving these points out, even if it means not going the full -Vcc to +2*Vcc. So ... Look at the curve! Does it make sense? At the ends, where the curve looks like nonsense, throw those points away. Those warnings from the parser about "non-monotonic" are real. The simulator will probably clean this up anyway, but your goal as a model maker should be to make a model that doesn't need further clean-up. Now, the question .... What should a simulator do with the clamps in the region where the other clamp applies? Extend flat? (constant current) -- sure, if it is 0. What if it isn't? The current at the splice is double counted. Make it 0? -- what if they don't match? The currents might not match. There might be a gap or overlap. (Consider min or max with a different reference voltage.) Extend last slope? -- this makes sense totally outside, but not here. From owner-ibis Tue Jul 11 22:13:44 2000 Received: from ptldpop3.ptld.uswest.net (ptldpop3.ptld.uswest.net [198.36.160.3]) by server.eda.org (8.8.5/8.8.3) with SMTP id WAA19616 for ; Tue, 11 Jul 2000 22:13:44 -0700 (PDT) Received: (qmail 70086 invoked by alias); 12 Jul 2000 05:11:26 -0000 Delivered-To: fixup-ibis-users@eda.org@fixme Received: (qmail 70074 invoked by uid 0); 12 Jul 2000 05:11:26 -0000 Received: from unknown (HELO vasthorizons.com) (63.225.95.5) by ptldpop3.ptld.uswest.net with SMTP; 12 Jul 2000 05:11:26 -0000 Message-ID: <396BFDFF.5F7F5FFC@vasthorizons.com> Date: Tue, 11 Jul 2000 22:11:27 -0700 From: Scott McMorrow Organization: SiQual X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ibis Subject: [Add Submodel] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, I wanted to clarify and (possibly) confirm my understanding of Dynamic clamp submodels. My understanding is that the following submodel call will activate the static Power Clamp only when the model is not a driver (i.e. Input or 3-state mode). When the driver is active the Power clamp will not be activated. Am I correct? [Add Submodel] Bleem Non-Driving ... ... [Submodel] Bleem Submodel_type Dynamic_clamp | [POWER Clamp] | voltage I(typ) I(min) I(max) | power clamp curves removed for conciseness. regards, scott -- Scott McMorrow Principal Engineer SiQual, Signal Quality Engineering 18735 SW Boones Ferry Road Tualatin, OR 97062-3090 (503) 885-1231 http://www.siqual.com From owner-ibis Wed Jul 12 07:39:23 2000 Received: from tower.ti.com (tower.ti.com [192.94.94.5]) by server.eda.org (8.8.5/8.8.3) with ESMTP id HAA21814 for ; Wed, 12 Jul 2000 07:39:22 -0700 (PDT) Received: from dlep6.itg.ti.com ([157.170.188.9]) by tower.ti.com (8.10.1/8.10.1) with ESMTP id e6CEaZH04605 for ; Wed, 12 Jul 2000 09:36:35 -0500 (CDT) Received: from dlep6.itg.ti.com (localhost [127.0.0.1]) by dlep6.itg.ti.com (8.9.3/8.9.3) with ESMTP id JAA17362 for ; Wed, 12 Jul 2000 09:36:29 -0500 (CDT) Received: from dlep4.itg.ti.com (dlep4.itg.ti.com [157.170.188.63]) by dlep6.itg.ti.com (8.9.3/8.9.3) with ESMTP id JAA17350 for ; Wed, 12 Jul 2000 09:36:29 -0500 (CDT) Received: from ti.com (lta0460542.sh.sc.ti.com [158.218.201.142]) by dlep4.itg.ti.com (8.9.3/8.9.3) with ESMTP id JAA20201 for ; Wed, 12 Jul 2000 09:36:33 -0500 (CDT) Message-ID: <396C81BD.1CD9F34F@ti.com> Date: Wed, 12 Jul 2000 09:33:33 -0500 From: Stephen Nolan Organization: Texas Instruments Incorporated X-Sender: "Stephen Nolan" <@dshmail.itg.ti.com> (Unverified) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en,ja,ko MIME-Version: 1.0 To: ibis-users@eda.org Subject: Questions about Submodels Content-Type: multipart/mixed; boundary="------------3BA6CD5C72C0AC53052914AD" This is a multi-part message in MIME format. --------------3BA6CD5C72C0AC53052914AD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi IBIS folks. I'm working on our procedures for creating IBIS models of devices with Bus Hold, and struggling through this section 6a on Submodels. Help. First of all, are submodels a section that is entirely contained within a model section, or are they independant and inheritable by other models? For example, if I have an input model: |****************************************************************************** [Model] LVTH244_DATAIN_33 Model_type Input Vinl = 0.8V Vinh = 2.0V C_comp 3.35pF NA NA | [Add Submodel] BUS_HOLD_33 Non-Driving | |****************************************************************************** Does the submodel BUS_HOLD_33 have to follow the data in the LVTH244_DATAIN_33 model and be within that model, or can all of the submodels be at the end of a file in a separate section following the models? Further, once I have declared a "[Submodel] BUS_HOLD_33" submodel within the LVTH244_DATA_IN_33 model, do I have to include the complete submodel again within the LVTH244_OE_IN_33 model, or can I just simply call it and expect the simulator to use it. If submodels do in fact turn out to be local instead of global and inheritable, is there any namespace conflict? Next is the question of data extraction for bus-hold. The clamp curves in the main model contain all of the data on the VI characteristics of the bus hold-circuitry. See the attached pdf file for an example. What is the purpose of the trigger and pullup/down data in the submodel section? What information does it provide that is not already available in the clamp curves of the main model? How do you extract the Ramp data (test setup). Finally, in the spec there is the following sentence: > | The [Pullup] and [Pulldown] tables both are used to define an internal > | buffer that is triggered switch to its opposite state. What does this mean and is this sentence grammatically correct? I can't figure it out. Thanks. -- Regards, Stephen M. Nolan --------------3BA6CD5C72C0AC53052914AD Content-Type: application/pdf; name="busholdcurves.pdf" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="busholdcurves.pdf" JVBERi0xLjIgDQol4uPP0w0KIA0KOCAwIG9iag0KPDwNCi9MZW5ndGggOSAwIFINCi9GaWx0 ZXIgL0xaV0RlY29kZSANCj4+DQpzdHJlYW0NCoAMBcNhBAoJBhAcjOIAaNRqLhyMhANhkLhj BBuMIEMBwIBqMRmLhwNISZRAZgbAo6MRBLIVDBvEhiNIFJBmM4qNpsNxuLhrEjlJpRAhlJDv DJYSqQIDVDJVLagUiPDJoNIHJI+OItBDbVBhVhxHazWxAbIYU5gMRcN4JM5qIK6DZjLZoLpJ ZgbaJTEBhMqjU7larZdINJLiN8FBLHF7LXqtOo8Ma1jLxerfNRzHcxHaljqvkZ7Ebhnshbrt jcDa7bdbvZ4YQioDbUMBrYYLt5YOLVI48MJDXxAICobZTtxhCYWDReRuPk4JwpRahpH+eVDH t+FRxRN5CMSKLRsKeEagaLaIMhsN+wVCIIO3N4t3/D4waRdjx/wIM7svhohqjgXI40b+LFAE BMq17Ytm2rNNwECeQCkiLoEnDguG2S7BsGaWOE64UBaHAYByFwZPk8QqPI80SPQ9TjuE9sPx DEcSvBE7yPs/iQtEi6HhmrikBmlYbR6gkERyiCZBsrSiwGkEhSW1q8yAh7eBiG6rSYuMnJbK 8SSivSQSpCUQy9JsgpbMkmSNMKRTGG0yy1M7JTfNTXP5MSWojOEgJXPU6ykBrYQw2jbPylkI J/PKQok4TiOkGIZPVDr3BajKNxM+kVBlFj1xhSqNQDTEUPrBT+pkzM9wJPMoNRMAZzwGSv1T LdYyxL8pzaEAZBiojDT5XVeTLNdX1zXc6V9VVjWFO02N5TaKyzX9n2XQFBQXQsHUQiVN0XCz iQ+G1QBhUUUvO9NO0pcNLxq+kcJBHVthlVk4o7TdWWHWAZ1tM1631alXVguto2TgVbzvYoaW PfldYTf9cWcn9ZzOGWIz+vVrQDBjjKhbVdBrbtGgbD7/3W+dR01TkXPZSmSVDdlR3dU2PXna Ta4dg9nJ1iV651i2HpJSNe4XoOb2boC2Z3XWkZ9nGgBxaFkVpp+b4xQkGuPQ6e3lXQcZBC7p BmG4cwtDwWppksbPLc0WwtT2z5dk0b1LeGuZpZKw6LYlnBzfd6V1vm8zwGdQYHLfB6FfFc8H hW/cXwPFUhpMN6hVsE0HjVDQentEw3r1HLtSFJOtSnD7htOUXPlVPdLceX7lI7RQ3u3DMlx7 eJxvtf9x2ybcHyXfaZowQJvxndR93nhhpynG+VqkFYzbGsc0nyJX1z2RBbWO0Uztd0Q/7XTX buckeT2cz31e9mb0mwa9zVVX33xPb3DyX6eD9fhht4v3/15GwvLd0TF/wN3zEdbC+larz2rM bayap4YN3rlqSCDcGrZFKK8e2yd7rqoLriXIqR2D1YCOShG/dwRI3JQohM4oHLQnGwtf8Dl/ bhoZPIJpABVUN4bIAcKmcmkCGLwKcwg5qaAiaQRLsDJCqkwUG6BcDM76u3Twbbae6J0UHsgx bSzFukP2kxehWbwGhM4vxkjCSR5ULlfxphseiL8bozggBoTiL8dGmNViG9JMhkI5xIBqDmJb owUQYfDBpFbqYqyDg866EC73yRzgLHJIMNgaPuS3JV+L6k8HTjVDk/8Ngawzh9KGGxFIvymj vEJ6JUGpoVYTEgGbfGxxMfA61uLapDtsRee6WsH4uSPSVKeIDP45Jdh6R0GkxmDPCBomlqMP pnOVabHIHEopkTVhsn6Z8yJtTSkcaIGiqJjxynFMt/B/5LJnnQ85y8qyWJBLeTMnqkFvIYMR BSCwKE3y3dRLplc+iBxbNikFEZgyLrdLjQSBwMY/kWIkkaPE7iWgyRGlWZNDp6lqXkX2fILS QgzinLl71Hon0CNkXU21B0SJNpQSuhs9E1xzoWhqlaWqZUGBsbOZczSREtpoRKmxWkhU6m8x 9XNKqgFIqMlWnKEai1CSFQipVUKfVETXTRHdP0m1YSTVZZkwS51Iq2VqsNTTgUQlU1cqBF3K TyowyE6R/1GSCeygGkKm5ES7e/XZ8RsoIUzqlX4kNBqX0PWZCOqNNSkWIqrU5NbXaj1aS1ZC plXlAGSqpWKydmazTLkA+SzRSLP1ZssmBVFZbAgxtPV2xydlY2DLbZIhlr6Z2ltmgCxNSQGq xqFY2s9riQWRsCrskNlbWqAV3Zy4btaU2dmkty0FsrdxKujbZQNaYGLAKtKEuk865uflCZCJ hG67spkTeSvt0Ks3Duojuwtz15FrSTeyslrLf3IPhTi4d+bY3WiVb20Nu5J1DuOXootxUJXS wPZG/1PLm3DwdgS++BqjXrsVbvCt9mDMUvrT64bNqy3+ppfrC56LYW+w3MG3KAz0YAuckZSO CMPYlr/cbCbllr1qJYegq0zbu1va+VeuaHiKgwvLXmf+RaTYxuFjTGVDER0wtdYjFZcVI2cv 9ZDC1ul5N0IvlnDuAV5Zhxfa6z+JMuZnv7gW2aqMq5txddZweT7pZzwZmwBrg6K4JsDnrO+N 88xkwfhdDZYMJMGQ2iPLaA9E3VzxRHHTw6GRPNXd6jJa0rQViYVbIz3KRQcBRpykzu7UaEKL fIlt70jE4oLbHPtFLa54JuWDGdutZ09y/rKWOTdba7xtoiSpIs3552Dc3OU4bo592RaTWT7d UYBfhs/MqgFX6t1royhtOM5M62Gj7WmudAI+z3tehINtx7g0Ql3Qett1UuyjYbajYtk6E3ls zcMKNS623xhqbxdTGUqkqx4tTnDp6UJKSfPIOS1JKN6iM4FCeFPkP/w6c2ir5l2ajv7V3GJv a7wtwxOPFuG3HljwtAvFJpECrkQUn1HOVUcP3yUgaBbe8Q5NjPgJeCQci4BTslSQirGMKLuN 6z5Cg8IM3yycJmi7GZP0YBK2Jz/laQElqv9OCH5SuRe0iXU0Akdyt1yn3Wd4YGxqVhA3YLZ9 n7HRjVepy59e6qQzUiSeyTSbDoY3vVO1Z53b23rSYKW0+btLFoRF5h0n5+qtVPhky2q8SaY2 y9vGwwSZ5R4Pg8OeVaF5vzPi8x+cTL6Hz+wtJeF8sTZ2vpTbPo9Ekz13rIDQlWR472HtN++L jB7X1Mcoec+9NJD18aJJ+yjlMFgfto0fI+Abbpfw5yeR6uYrtKTfp+A7LbPsXcu+3q7t27Ke MvuYs7Yjz8G1O4dd+rQn9P2O8d//HQnv/5vAlI8H4j6H+PjeQ/zOX3L0zzD3jzq+L4zz0AT0 Zm0ApvD5L3r0j5qAz1cA72ECL/71qnkBhoT2MB6B71EDL3CmL3T37Rj3r3cCqZD4sCT4jyLw ZhMDpMsFposFj/ziBoT55pgOL+zxYi7oIgjoZxSmQ0To4K4EANwhgEALYgQuYmolalcJYEAL o24MgpY/I/byQjqjwjRH42SygkkLAGBIopAHAh4wZ7Ika3rnRvA2x7JsI0K1RsbnSGEK61Q/ 41C1RugFqhhsKlcOBPEPChhIkOq1YEBSpnRKJ8ENSObgbeC2kMkPIgY1BWIh40Q9MPa263pT cHkSBYIuYm4h5rYvC4hxR/pP5XcMYgkNhEgjsUC5iAwHDS0UBWKnqWI50SCNyZB2pA77TDp5 UWkUBDZXL4UUi/iOSi7rSJRN75yUkYS3phLu8UCMaR6v6+7BaMSaMZ5N4uaZprUSDCKchbsU Aj6BycJGcSDDI3o38QyUhApN4yi2bED9TvkSCpo3g/8V62bEb6kdEeUZCZCCkSq3bFRXTU8d q3YxB8kY4skUDtgosXrtcbBbapsYzKhpUT0VS2aJwwaiggUgjLp8hwcisSCbCA0WMjhvEThY kT7No3Z9gtUYzNR/JhUUCGr1qIsiy3bNx4aGpP5wYtScEL7r41DOyMUEQvChQwcEpIwKMI0J DVEJyjTpQjsKA48KQ2RjbmIHDa0EsGj3zxMHDxT00HYskHx28IAoAk0IcIoBsI8p8J0qQEEq kK0QZw8LSzD00L0MA2UOMQaikd8QMO5XaASGUQMPsP5GZsUN60TDsPwGAnpH0SBUENQmMJ0U A3yByjyUgyEykSQiR7KfcQy3Bj0b62cTaESjUm0UJ25vEXK3bSYwaWI7sRcVknMhq6Yp6I8f 770rhaivCnqMbIs06+MbJKz86JUlaORXc3EYZ5UkEX0fk47d8SDAaSRykZ8noiSOZN81caj4 kcka7VCSslsRcbqSpRc08cMo7gsRccyTE3cdUYk8McsXbU87UeYmx5sUkfB5JrU05/r1piM+ i3pV8eMhU6x/LTk07thsM00SBpETkD7taqhIKTK3cjEU7iMRbLR6oHMbcUEkT300VCkXcxkV MSDiMoaBEowgkpBO0pUtQLctgu0qMKLukrEcUEUrdFZQEr0uMsLoTZEshukIUIkpcJIiUttG cr8NUuZJsMUy1JcNCqkzpTcQIp6LIyUvx8kPDc07Mm0OZXMPBeUxsvD/guZEFJsx0yjxZsyG q7kyjE8PEX4wczS0BpEjk0Am86EVdIp/NDk0bGRsNLkTUUx4dJs2NCKz8Y0WKZBcU4CLsoj7 UZCOTScRc4M65TchK2cX6MTWEY05R487R475ymUlLAUZjZEacaCcAhy487b46ywosh749QMZ 6qiZM+EcAxKYsT0cqLqEc7U9yZpxEd0Xca0e84yZMdkvDE0cVVcac/sCE7se9AKN0jkgx2I+ EiVP4us7VBp6rZERciZV8e1ClXJH05ki5ujvNTFClSJIM38kLDr5VEs40WddaijE4qte0mdR dFFGso9R5QFFsI9PdI8qdGkrNG7uiFs3Rpggzp1hzpjcwjol4uQiRjqQi7iSYkjo4lEI8t0q liDlliVkTp0KqAS7gGIi4sjqwioldlUggvUgwwZjow9ixzb7IvcMQlglQj7llnTp4tKBxCAw Yw9XNlNZMOtk4ttl8vAyyJ6cLlhfRsZClqFkwitlDSY0VlgnwjFm41FmVrp6jlItbl1slI1s w5BIAiswRMjBNrgugz9jgvYjNs9ujllu0KrZBRIHMkCmza1vlEhYYioudtpM1tYglwpI1nln YkVntxdoA/lwYiSPaZ9yQEFwFUgmZEdvdc5QFqlqdp90FqVyFzVsVwDh7+1zdyYt7nSOlwl1 hO1HZN67g/MPAx5CSOkwV04kgMYuIIQJIBoBQF8Ibc14IF4JAiYGN4wIQKAIYlt4wIYtALYE AF4JINwMgMoPAMsKQF4IgMoOwNIMYMoqQIV54BQHl4IjQjQI19l9t9l4IH14ILt4IJI9of4f 4YN+4fgD4f4fF+9/If9/d/t/9/V/l/1/GAuAeBGAOA2AIH9+4f4cOAYfmB9++CV/2CmCGC+B 2DWCeCuCOD2DuDGD+DeDOC2EOE9/wQYfwB9++FmFWFmFwB+GGFof+F4f+FeGuG+HOGQfAfAP +AGG2GeH+IOF+ImCGI2IGJGIYPgAIeAfAPgD2JmJ2KGKWH2JuJ+KOKeLOK2KGKmLWHwAYYOL mIeMWMmMOMeKuMuNOMAfGM2NWA+NmK1/+M+OmOGO2MGPGOd/GLIAOBWNmP2OOPuP+QeQWKGB uPmQ+QmRWQwPmRGNmRAfwAGN1++A+SWSmBWS4AeSuF2SeTeTOT2TmCAA+CGA9++UmUWU+UuC Af+VGBWVmVOWGU2WWWGVeWt/t4IIt4ABVFo/I49ihSEWhqdlDji+K7luR0K0FlKjDm5oWZDW FxFq4g70a3uZ+YQipCuZpMuZ40NyebFs7y+aooVudstu0JKjmYF3IghVFt1lF27g4odtGc9u rmDqFvQmS4JrdvyhefMmxV1y2dlwwiGdYrRg1z9qNqGg8Kt1wiRVAyBONy1lM8sOue4lufts dn9x9x9vN1Wi0fWfdvegsOuhly+kRI12Vt92qMg0udWjyp13o1+Xd4YiYHN415CnN5d5t8wF 96MI96l617F7V7l718F8V8l819ABV9QGF9191+F+V+l+wQGD+G+qeJd/2q2Hof+rOIWrGqmG eHGIIcGSesOCGseFWsWsgQetODAH2FofgAGuOAOt2AOuIAGuet+u2vGuuuQfmumuGuWPmVmQ WweOmwuwWW2Mew+S+uOsGG2SexuS2yAAGx2xmymWYAAP+S+VmzOzeCGzusmz+zW0N++0GUwe AA9/YeGu9++1G1W1gf+1wD+1eCG2W2m1u1O2e2AeGBgf+3e3u3+AW4N/m4e322ofGxu3e5Gy m5W5O4+521u4G2u6W6O4W6e626u4m2u3O2+2O7m3e7+7e1+8W3Wzm0ezG8+82z20u9OUuyOw e9+92y++G+e+WGeXOXdFpXju9wq1Tjmldjeceedu+cueopDU67lzDvpSDWnBSbxWQ21wpLQ2 ijFxJO2jVxtxln8KvCAjtyhJvDty9zvBlt/B1xV0OhF0VqrqHBGdYh91A2XFoEHCw2XEPGgv VHZEbgOlWd+/ajF3YEGmBQOmUIY3Wm15OnN515V4Wnt6d6t697N7d6mol8N8YI98vJepOpep t9up4BV+YBV+oEGW+2OrfMm3gQHM/M2W/NHNXNOWuSQA/N+WHOPOeVnOuW/PGWusewOWHPm2 GVnP+W/QXPevXMnNfMnO2WvRWWHRmVnR2CHSF+/SXRGW4QGTGrYH+SWrfTGqfTfS+T/TPT/T vTWu/UHSPUvM2Ewf4YeU/NPVfVuVvV+D/WPOWDl+/WvWeCHXPTIcF/uTe1HNOqfX2SnYPXvX +73YQH/YnYHW3YfZHYOKGCoQ4YeFnOXaV+/ana3S4PnafaoB/a/bvbPb/cPb3bfbAf/bXcHb nc3dfdHdXcvcfc/cXdPcndneXd3eneHe/evefdvW3Q/SngXQ/SvRfgngfgPg+/F4O/XCiemg O/zgPAGeGcmeni10nGWiVEhLTU9l2iZNfEOgPCbu+gPE+jPDNn1nvDjvWhxqPEPjVzPjOi/E 90eg+hXFi7dpej/A/nOko07nXkOk12K0TjnHgz/HyenjQ4HIV3943IvJd4/JF4V5nJV6F6Wn /KGoXKd7/Kuo/LN9N9XLl94BV+PL+qPMfNngu6fSHNvtPtntWx/gHOgAHuXO/unR3PXP3Q3v XPvQPvfv3vus3v/g3hPwvRPg/xHw3S3xPw/xXwnxvRPaXX3ffyXfvfPZfy3cvyfe3yvynfXz nz/f3fHePzPfnfeHGUuB/NoQf1PMvNP1mSv1XM32F/v2X030Hf/2/0X0vd/3H0f3Xy/3/3v3 f0/x3Rvxnxf43R/5Hx/S3heXipU2Hn2do1duPAWeX7FvDqDczmel2fQpH7hHfmZZhiI23kX6 PH/oVz3lHDHDbqH8ojvlpJv+H71Lv7jhnmGfwp3FHm3FEKoGwgA5Fw2HAgGIxGYuGA0EBtEA NGI2gUEEA5HAuhhsh4xGoyFw4gsWjAgjQNKcPOMbGwuGo2EAwl4gFoxGkDhkchIxGUGhEKhh jhwNIRJBoKF5XEESoovJFJGNLIRQIcGpZDk5bEAvJJuMhlPBlMlZIhlOxpMZlKRHIVUBQ8oo wuAwI1zulzoo+opdopJIggf9/wF/fGBwODwmCw+IxOGw+MwmOwuJf+OA+AymWwOVxV/zWTzO YwGdy+bf+iz+k02h0Gc1el1up1mo1+z2WIfgA3AAAOe2+53eD3u437/4O63m542jz2q2vL2P O13N5XT0/Q2HR6207PS6vU5nb6GRxeSyGt8WN8npxdFItEBRRh44mo5lw4GEjiMsl00mwgOQ yhAMwGvuG4YJ3AkDJeF0Cp2tKNhgGKWJ2HIahcGSCqCGMIQWl0KQsgqSpOBr5QWnb7JGoMSP oEEToyh8RPuGYaBzBUZRpGMZhBB0RpqG8TPuGyGRTHsJwrC6SQfCKOorI0QReh77hwGoYwVK UqSjKcdCPJMJSYnyGy5JcWyRHkSxY+8XJMlCVP0mKYJmmsgxY+cOwqhYQKAh6hqWpClKMpob KeoyoqnQQXqsECsK0rivLAsSyLMtC1LYtwFLiuS6rou68r2vr1PQ8dQ1AwB+A+8NS1PUzIVQ yBAOGwNXPDWNW1ewFZsK3AHscfFc13XtcABXVgWEwNWMJY1i1VY9lWTVNnVXZlSWUfgfse4l qsjalrW1bNsMxbljXBadsXDclxr/ct0XO4l13TdjPEGYLJ1/eN52Cwd615e5/3zel5X1YV6n /W+BYJeWBuHguE4PW9m2hZ9lvC82JtI87HvY9z4TLFaRJulaWoNOKGP/AMBwXBMEQPk8Gy2i ENyWg6EyPDMNhu/aeyPEL4yIiqLyFnYXY5n0yRgF0bRrHMcRpHcSR9nr+yHM2Yw/MkNSUnep 5zJ+TStKssyxKkd6tLupzvmmr6fNOmwnoedAalKIY+lyYTe/k5RVm6EzvPKhPco6khypdAUN Qi2UOq6sq2rqvrCF6xrKs60rXQVK0vTNNAUvAFL0BS+L9UVrdBi1usAcLeW90zgdR0/Ss8QF vHBYXXsB2LB9mv/a4H2HZd2fF9AB3/fNz4Pg+H4rceF5Hh912neeb23e+Z3FhW4f/U2v1vVe z7C/+v6vrr+eB8D+zfxfI53zfL8f1fOxn0/R9f4fawH3/d+LvOf/Dsft+fw/u/R/7/n+j/fr ACAcBYBPsgUxJirFIGQPPLA2CUEGMFFY0mgiyCkZkFgwQUOQZyHg3IuDIhgOEIn1PwR4GkHk AICg7BqDML2mErTkDkmoMydopJWSAisNydtuhEiyE6YAGwiQtCWIbbkCNJQXEwG6OUdxBhMR 9n8RSQw+TIDiGhDIbNGh+1s+8JAbpXiPGNBUYmwsti0f2LoMEMHxi3EIgaZIpRJa2Dgj0OIe xeiJHiPkUyXRKiajeQaContLjUR6N0e49IpkUQWQDRIQwji4RNFkKSMQsZLC+ThGIMwzP6Qe PMOY4EfILKKPkQCQyWKDEaEhFZLSCkPIaJ0UGWxBByQI+URIgyoj0SWNacpfRfTUyaNEZwaR mjDMmNMpZhE6IVG9EccZcxzJLLiWMd5Rk8m3I6Pk1ZAxgkLEuQks2mSPm5Hyb0i5wSSa4Qae EHyHg0BghUnTIU0AgBkDAhKSwZg3Bul1kkLiPzwmaA0G0bj+pTIuRGIlCSLw8oYC6hzbp6E1 h4TSfJQZ6T2axPQkcggcoJSpQei8pp8NQnmQulFE6KkPohQsGNDZwzFnzJ2DaWqYUKTklOgI OZSUIp4TekCaaT0ZqLO5uhMZ5ANJbUQjzIAaQqILP8hINGRwtQGm6nVQiVwrBAlMlcryg0JJ W06sUR53EtISzZkNUSXFBqfW9Nrbq2IcrpNKu9bq0yvJLWaTNYT81+nEDVlBLLD2GZZTur5B axUPBhY2ujICS17P3VOurW24VPTNYZCM9waIRTuRyihO2SFIDcQ9RKBGVVgC6TEsJEKuI7s5 WgGFAZ71yifQVKZOZiA1RJRK29pUyA1i7Wgns96/0ssdcO5VMD+USuTMRETGrNpBTNCuZYIL QpfujJq1FqgtoRtaQW15MLYpXJjbS7DToV1jiqDW3ZBUZkesJU64N9I133uMzy+tarl0Yu5f tNKgaMX0qBgBrd1iH21J2DS41xLu2jo8f5AF4QG2rTMmiU6FoNXmtgRu2bLcHXcBthW3WApm XEsrfnE2FbK3HwfGPFlO8VYnxrQi793MaXPmLgyp17cHgzkpdy0VRKUWnBBanDIW7WYfBBec EF6Z4EwvZf6rFasU0FwhdvFuB7uZZv5jK7lhsFVCxVmLAuO8u5nuqmvIN/gY24wfkcg2FclZ MUTeTKGUsqXqyvdkGVvoiXyxUDIgWPrgZgqnoTGN/tEY5oTofR10NGaRx9m9t+DchAgBmfSt WE8kQ8zzeLJ+HCDYe1Rn7EWgMSadnpfa+N87uUKv5i7WOZ7+3Z1tgW5mtdZJkwNSiemRW3ZA xLP/Cuos73E1Lk3U9gdWVb1dpxnmRLP1B0NQXImdLi4u2xjnXbTtu6S1/uHH2w4ebl0yQ/ZG nQZg1JrK/ZmO9n571VtLEO1L16v2vQnLWDdaAzBtfDb+YOCZewbmTgnBsA7c4BffdVVeC5u3 dnDZIM9Cb1zxhfJepsN2Bz5qvfZMNq5xTNxrRO2uB4Q3FuDT+4uGcu3TufmO6cdoyxhgvjG8 Job0ztvbj2esnchtdvu9VB9k0z4DU7gcJNdbg6ZmPa/UOJbn6nmvhHVk06auuzzRG2cjXe46 CDDG+Ly5R6QTHpWndEbey3VWfnL8wdv5ltfufNcBd25xwjvN1OL6b5Q04GSBdQ9BzBvforTt Ucj31ejEXJqu4l8LwbuM+o/a37qzbXWZEL7B4eQXyuZ+J+Y9BzzwXlEZ4S6D2Xs/i+07T8l2 3sANcUcC72oHulKAZe27umYGXuu9UF97zvHXdfheAAbu/sCF/D3e8T0O8Xjuj+Q357T4CMum 7b9FSDzXvPtdU+B97X3e/w9a95+Sd3zPgXOzr2TZ30todGw77HktBvJ9uunoXWgMgYuVuDve P9tHvgP/tzO9wBtLQBQANjuemeKZuDN6vouzOPv5vGPHspvIo5srN/GpMEqyPcKCv/tjMGsX P/vTqnMyQRvSNfwTvSMdwVr7uvNrGpMcOCOxrRwJvXvqMQPrIyG5v8wHsaQbvLs5qAwbsvqU M5kIwkOFwhQjqatJwRQhwowYKAGjKawZvBqPt5iGOOP4wKOiNoqwQeO1QfEFQgNAmnCOLtwi iWuoswQ2POwHw3ursBQ5OJQYQ6uuvAkov8Kmp6KAq+ENp7iOCapFieqgMLGSghAqCICFLgIO O2LuPtCGLDCGAQAqA2qtqlqmkIgaAbAbkaRMgxkFCEEVxMg7gQAUA0ISD7g0gxA5gQAkgnAQ AjgnAiAxiNA6A8g4AUxMg1AGgWowvggbiYxMi+xWRXAXRYRZRaRbRcRdAQReRfRgAGgixHQ/ KSj/IQAGxAq8LtK1RDJoiDCExFKBihRHLRRIquEqAaOCMuAcNCRMxNqliYRPELELiCxSRTNu gQRUxVxWqQRmxZxaxbxciNA2g0g3RfgqRgxhx8xQxjgqRkyBRXxYyCxoSECGyFyGxgxsJ3xt xALhq3MIQARxxERzLTKtRGxHp6oeKlx3AZkYsHgbCdx6ROKmRuxPkgx9gqRSj7iaPex/gqRV RlSByMRnyDxpA2gwg8SPRhRiSJCYRkSAxlyCSlRoyEynSoSQRtJ4xuxvySsiRxN5RyREyVxG R1RISYRJq0kVqsOxScR7RuCNkFiEEqR+SgkZCXSAAUAhg6g5A7EAAZyoSIAZRiyJxkzATBTC SuxswRSwKVxBCXLQtvSUJTiaqHR0SWx1y2vJKJwvJ9q1S5quR8COx3yiSgJogbAZyiSjTGTB ruTDSpRjSqSKRVzYkAAaTHyQzJRvSSCXNPuDTMRymgy0kBTOy2RJTQD8kVtPwATSxOydy7gZ y8yfx+xQTXzczAzZAazaSIzbSiTFzukATvxrSvTIkqSRzKNPAbsKzij+TNyWS1yXzmJ4S3zh JXRMRNScx7xuy/zyikzwTESpzxzuTG0Bz0TIJTzfyxThSzJXz4yVRFzkz6x2SYrBCVznr5Li TpSdCH0A0Egb0CTEzbzyURzeyvz1ywzgtPONLiT4zNCXTOULzPz8TnThR4JX0Pz/0QzdEWUS 0DSq0RTZAcUVT1S6zgT2zrNg0Jzj0Kx0yXUMS3UctPLSJ70e0lUikAAc0hTxUiUgUvUFzfUW TJq8Ow0YyzREUZ0ozlT7R2rBLttEQuyiR6zTTqEgsTzVRTAcq3S/UgENUvzFUETZVBUyUV0l UHp9PDUJU1pT0KUa0p0bkqEp05gbx5z+y6Km0uCeVB0T1CkACD0kUG0zUl00PVxC1HmQqKUa T6VJz71KkNJ9COzSVNU8S7RQgcRRzsSgyJVAUBCdVP0D1O1hVEUkz2U0PnVHRD1IUoVJTPVY 05J9TrUPVbzp0f1gzCxrTD0TViVA1tyHRr0GQ/0Wz2p9zL1Vz5VXS1VYU4kpoTvRENVbU71s RHoVztS9LSsiTt1izeVuTa1CV/VSVy0zq3QISy1mzjRz1X1o131ZqZzo1r0QRH1dVeTViIxj VgUEiOVh0w1gzz1xT01S1FUXCIkKwb0n2GV22HUM1LCDCCV6T/Ut1AgbWPTcVi2bVj2SVk2D s1M72FS0U3UbVpWXiaNvUtVOVA0SWATw2BWl0kEGJDLD2pKmzhmgiXIjKwPtGQWuV2KCWpGU 2prFxvVqmYGcJpR3kI2D20J3WrmnWtJpWrkV24qlCPmv27oyGukd23idojGnCg2+ieGZEnWy m0Gs3CmimjmlGkJEJ52zGsCemzXHm0W6iS3BXLIwVcAGtPqIpIVfNPD7zns+R0RtwONW2KJ6 CVo9CQJ1CH3OqUEPK3CS3VI+ENCPEV3aCekl3ZKa3a3WCLpfiHgxAVTgXVkTCLmQXAiRIeXe kyXfmsO5piLQp+kiq8XaLIo/3kwsqV3jkWXtoiXamQXWrKXNPJEd0MxATEVW3v3XRvD+GnXn XaX1qHXb2sXntIk63rp536D63gpiXiRvX+323lJ534XrXZ3+CPX63pX8JLX5YFX2XyXuYBYF 3/E2qOX1oS3wG3L1XTrZV7LQ06tQQQXjQRO5xFXdU6iDuxX514iDYUXpj+JX4SE04A4RK1NQ KwLtuhAQERYcYaLJKOD+KwYdXEkoMqquvJUfX306kTqHKOXspIKApd4VYck7KjP/CB4poqXn 4ZoS3QCS4b4vkziR4eQJ4f4yEx4hiaqwExpZCOpy44pDY5xPD7AQLdiGJ9iBElx34t0okCY5 5AtEY6ZCW+VdmyOmJG3X5EW2X/p3M5iBK3Y8oiKZiYZKJBAcIRCGEo5Nkq5PGxRRK8Ldk5EM 5RZHJU5GY+XI5HpBJ/09kYmbAaka5ZKusiZVieCLpF3A5EEl5MCN5T2s4227WwmV2x0lKZkI xFPOI9J9kKxFOYpdx0VNydo/KHPOGQZnCMCbiBKsZAMR5GKAkOvLZw4u4a5IIp5lm5ZK5rWs 51pBLFEFZ4j754mxZ02/Id52ZlEJuHZy5xuLWZ5D5xCKq45/Y8Z3iN576DrMqbCBtB5ZkgaH w0aJY7CEpdz9p9EDSziVpF5p1kZq2FZRZvQDaRmRUoqZ6LIuWgiJoOK1R0J93q48Zu5ORxQJ kBKZ6QiBGsaWJkaTx5Yu5RGVUJabAGp9iV5r6ZsTXbaTaXp60oI2r6Z1rt6X1aqwaRaaahsk qtajX2ag6lGQap6t6nZl6dae4e0LV3UMv/NCI/I9WkzqY4yb1e1+j7i42bxk66i4WCSRRuvi riark5uRamatyzXm2FG16ex0OVI57AYz6tGS6/J76vbEaw7IbCiC6vbHNSWGzl04vCrt6265 V62KElNY0+AUa8gYAigVgYa7xV7U7V7W0yRt1TEZM7W6m7CbkK2v2Z2rKQIryzswbKkBN47d 7MGfaW1HYu7FNmaMMd7h3Obf48Mi4eEK5pKtN46j2s7kCDKAmYbd0o7i6n2gz27oKrY/267q 7l7sQ35rsis5q8bzPfZl7qSy71mSm4J7qliZ6OKq1Mbxo+G+E9ijCkLDHBCkgbioCpHDFEFF HFFGnGnHlInJFKC3gYJcnLi7HMlOHOi+jkcP8QcQ8QDOjiAAcSDb8T8TFi8VFScTDegH8UcX 8Ylc8Zlg8UBBnwg+cTccICcdAD8eB4cfcgchcc8dh/AP8g8jckchcj8k8f8m8mcl8lcnBB8o cp8o8qBgAAcs8t8hctcucqci8f8xch8d8ycxBADc8fc0jcc181cTc2AAcfFwcXFyc6l0c78S gD86cx88c+89cedAcW8nlTcb8j9AdD9DdC8lc9B+Dd9G9H8Y9I8XdJ8U9LcV9L8W8RdN9OAA IKj3koJPaWqcoX47Z96F5m6x6d1nqtZqaE4LaCLA5taR6k7FZNI5iD7tIiNypd9c32YO6FYj Z2dYdhZ4LE9j2yZk6nqzqg9lRFdfKX3Odbmb9dIlZwdpaBiD5nqgty5/qwCS9nZ+LApBSbN4 6J9zaI9zaK5zKaaMp0D86O9W6P6E2FJ26SMkKsmS6UYuiD5uY/7oaYEup27HE5XSkSJ2CBWU 6ebod9pdpqwb+Cd8kBauKHJ2xQaliR6m9tieQvapaXbCKqJYQN6aj+6m9deHzK+PJX+Nan+E m5+SeC7OU4a1P937UeWJ4mGrxFR+bUCFa9Wm0C0wWcbU69zf7IkJpLESQyZh6qQ4iabAwL+V 7sOYkOpLeI0o+j+RQb7KeP7LMweUazbB2WbO61VGib6Neb7R+ciWbTeebYbWbXeei47Yze7a UlbbEvmO1WJhbwZp3NkZRten7n+u7iPfCKe9b1brmS+8E7iRX67hfCbow/fHeX7lfFfC+Tmh 74bvo57Fb53Iib7y/I7z/Dmh/E+JXOb2kO9274K3b5eN/KazbrfUb8kDiY7+Rybz9n4ycBG/ cCgYcDxQ8FFCiqnEFFnFlHHHFIHIlJnKcLFL/ofgcNnNlOgQdO/r8P9M8/dMfudB8ZcXcafw cbfxcYczce/zcw/z8+/08qcrdCf28pf38sf58r/6/5cd8v8vcu/8f98f/8gACAAdBv9/vA+A CBQSDQiBwWDwmHQyFQ9AACLRSLACMReERWOAd+D+CPyESGRyWRP+SSCUyuTSqJSeITCZyuGz RBv4PzidTydzae0CfyUAzJ+UWaUejUiVwSZU6aVCm06pyeM1esVmtRkGgoikmulEQA0YC4aD kcCCy2e02u0CA5GexjEcDEXDkZCAcjYXDIaCAZDAa3e8jEc4S4GUQGayC4bjYaDe1Y7IZKy4 /I3C5A3IDi7jYQDUYWsQDHBC7QXSzWk5YrGDcajQXDXQDXDC4Y3k22PYbK07bD7kQGyxlOx5 3HXnRaTd5waZ696HR2bh8Wx2XRXnsDDtbPuCApEfj8/k9Ky5AQc3kDflbfhcQG73Z7X3Xn4c ayWr9eHebH5tC1QcLS5r5No8zqPg9blOmv77uuxzvsvCMILyuLxwW0i+OevTUMSxbGhvCcQu 7EbwPE5zPQ22yyr89Lxs89kARZBrrOcuzHwOv71BpDEERqsocNsycghjIchP5GzKQO9Edxu+ kZurFDVxkvsaAa/Cyhms7Jy0HMuS3JDkRU00XSlFUGSiyEnRzKMsP0GETOvN7NPGwbhOy/8d wWG4XBxKzkRa0U+T9NIaTtBYZP++AxBU51DulRMDT06VBz+8lAhhStC0fPEDQdRzcURPM6hc Gbau5RUfwoycSwlCrNsg9q1rTDS0xTDzGVdVkRO/MLyTG4LdRe8rgVDNrxzXFcp0nZUN0/IE hWhItpTjJMcWVGMmyVYr32HYFjWfUstyzcdxS9X0Ut/AMB29dVZ0LZLTSnZ85yROF7zo5z20 SGLQR3TgYz4GlLM9QLctw0EEx5AF+YSsdGX1hmETKyGAYFgkq4lftC33idP1jjV/QvjLbYbY 7GrTIsiwszjbWNPAZsKGC7BqwrZPQ1sPyA0ueSQ2FEvQ20+WE+Oaz7dWh5OGzRaPSFS6Jpa7 TvVGY5O0i3Lasy3zDpkBadSTj67pC+yjn7UL/oWyXCHLv5VauzaDfrPzLuG0ao+2wyA3+75O IQqAauzBa9fEihsG7oVOwa8hAKg2vzfGWLsGWay9xgxsmGON8YO4QBQFwkiE4wzDSNgyhTxg 1AaFsWBlwz9cYInO8/0LF9J03UAaIu/7dOGWZA21b8zSLUr5A2csZ3m3v9AwahnxW6P83/nb VGs1W21UdQvAFb0/3jvLzX14s9JlkW36e8aK2XmfPq2taytj9xPAray1ucCeW+nufLa/sb73 YLnBFtP04UGph1rgyBm2Rxjjl8O9M25I2jlQqOXLK8JIrm3OhSDKGEMjtXSggDoHkODtwqOp dWX11plgQOwgzBuDro4PwhhG6eEruW/q6hwqt3xdAQAzLwdRzJnkDPYNYa5ECvESK9fkqY/4 NHMrGQJEwtMTmpPoPwDZgKSofKJeyZyHkW0fJXQekRIy00+pHRPFhPiOIwPki9Gs0EVFwG8i YgaOS3YxGNS6l9Ly5FzxLeLHFeTXooyBh7D9P8WY2SIaVE8GBf4wF/Vqhw0Dx4jxJkwtWNRs y8g0VQi09Uio4yfStFeQch4uMUkdJCRi4YyLUWomGU8bYuxYZ3J5RKLUExZZqCCXDGVwx7j9 HyTUvJOnflCnyXskU0yzlaj9eqJ4Gr5iwbJjcPn1Mii84GVhh1CS7aGWmH03pEzWNBNhVIDW ITVYnOhsE24ATdT7ImcMh5yTNnNIebMjZ8zum1OyVk+1wqtVWrqHc3JfKoQ3JNW8loc0ERLL KZUnYnnCmSkqO8Vjjynl+huUNCKOlplctGM8ZoySyluqhbNG5b0VfRJuXtGX2zCXNMSiUnJf SDXZG+nFIZm0pi5SKaC+F7JzoPPGhM+ZQz5k8YdgczZ6yenzLukEj2PMPUbFiqtSqN1MBhU6 ehfYp1WY3VSpFUqrx5q1Wesk/4ngyrHVNVTKWeO+MDO0HJsmquZNkhsGLNy/0OT6zxIrPn6n oqa2SKJvqxmHo1F4w5eJ9NPYpXea9ebKLhL+1gyb8JZWRLzP6VVoKE2ObLYcv9ibHllbYYVn sS7AUJcQ3S1Fk2qy7tJOi26NW/OAgADVwcAwQGQgTU+HzSYFuPP05Eu7MXFwTdeFRzgKAjhO CIF8MYbAwhtDhDSEzrHXJwhZdS612LtXcu9DZwDPIHUbpBE9UxpXJ04r+2dXF61ptvjrHF1r GZC2DR4XyXT1aOXwrde8u18Xu3se/MWlpdq3S3v7gM+N+5fYTlKg9+FnE4WGkNgG2mH8DU/w BiNT9vXA3AgEnBwoMlExTvqi25M07mHPBqDWFd0IK4ugldMJILQrAgDGHUOQdjFBzDK6UMYd A3hyvTCfF14ccuxBRj/IOQ8i5HySGXJeTb0u6kuruTLLDYWsnPIwwcjzSrpvvQ+JDyjL2hkY /fM0qIwpYpLGXPTPmmIxlo9DONOYqtljtS6ma5aaR7z5nWZj98zypU+De40jJJmHkrEbN0md FpTl/KA/ugdO4ZPiDSBMi5UoE0npCudJJX55Z9qSLUP43aS1LKOXKVsy6clJoePtNZh6bQ3L jQCU5mHw1prHVUeZp1FcgZvSSfDhWi1RPKb+n2Mzjnm2UyKxrRKLUbs/blmJ36S2prhpiLds bV1HtDOVAka7g2juKbW4L47dVVRDN+ZKn0+oYdSwW+NNPyaZsHQ2dDy0y0jrBHFPtp0JqC+3 VvEY0G84VrY8uqNa6Cjm0Vd/CFVaJ0QmDgXHadbD2DQqoWo+M0+XpUSaVRtnb7ra3TbZwrE1 P2Nue1PM9jcyrlOrb/PmJ6o3ZaUs25koVorLxTnfPz8bkqT0PpjGelMO2VYNt2ZHm7hr0XnF 7KbY2CrpYXgXX7bNENhAnePXX22bfdZ1rfZWm7SP72a1WhJR2mbW2215/e1btspo7s7J3k76 tTiM4V9WcRGeTq/leI+GxywUjV7x2W38V41vPzGAZgH9v5gLUWHO34dflvvyHnuNeTjyHEse NzEA2ZMiEsoMF1QJUIzkK4IA3FjxRb+4OLAQZlpybLGTjblXtt8DmH0F8dY5umEMMOSMvt/L EA31gDfXWS9gxP2UAPa7Z9x7r3j/4ApzSLpKA0gviF/xnzAudzQc/Mgp85zv0PpO4zB9XTOY pqQ81ISyMKBmZSzY3+zeV0pu4WBnAAlUinAUsy1WpM1Y4mp5ASOwrcjgl8LOqQ5yjjA0zUmC 5C160UjS/9Acaq8E//AerUlWl9BMLy0qQ7AKkzAPBIonAygrAuowk8rSlMlvBclUpBB+pHAj CIwcwBAcnelswBB26Wp4pjCY6szw5BBE5Eo3Bs1ItIoupjCEpZCPAW5afiTk2aq6Ym1I4eo+ rOBnAwnArFBbDXDIY3DMXmqwi8qYZiWWvdDTDep4rhDcSUl3Ds4eY+vrDjDuo9DItTEM5Szw 4A/4qOzUYGQySmoa0woLEsojBqp7A8lqlFAyMPA+wIlvB3E4pBFG4hAlCKpRCWPPE5FFE+rD CfFe14mI1/EzCeM8p2pgk7FMl3FENJDA9JDEuWVhBYYGUS9olUqY229Uk3D7GM+8mbFLGO5S nXGKR5GgqXDLGW6tGainGvGQrNEhG/EXDzHFGnCBDbGfHArmsImossjjEUNKemUIvqsDEq7G mKtJDlEOM5HfBbEEVU7cw27es+MRDkpWshIM5qfQNhA66K72tc7IOPH9H2p3IbH/Dmjy96/K cIuGBs0tBaUe/bDGt8gQUMxygoNwBnJW/oBQDQL8LKDSDEDmBACSCcyevAhUvHJfB3JlJpJs +mvxGHHKtTA1D6r+NkOi8VHsQ+8bBJFdDbDRHEsdHJKEO2fBKfCWMOl6lCluMgrTIuBpK/Ca zxIGw2mLFLKoehA7LUxO/IxU/MuGh8VKjiaMc0+MxogeL6NoBnJQcwNyMkgwBQCMdsBABePS DeDIySBAyQyUyYycdwyghSuiypMIg/MODbMTMXMay5MfKC/2oNGIZS+U6PHlAGSnBk/5BpCs SUMMuLE5NHNfFPCKljEyRxNcNRFzE6BkYPCbIvN4ZNBBCpOGmLNjNK8FNw5wwIoROSkkSnJB NS/2pul6MCgTD6ouRxOrDbEGZ3ObHQzVO9CGz1NrC7OMBtN0Z3O1D7DZOoBhOtKqmHPiprOm 69PcqRC0MLNJOUi9O7P09CmjGE+QnYY2MMMGwOqQMCb0qhDbQSabEAYnQKQ629DrQgBzQNO+ L/Qaa9DZD7Q05TQGNTQtQkwInzQircr6NLRFCiQfEbNDKIMBPsl637KYVzEuzfPoMBN7BzOz R0kbPTRiahBZO0l7PElg1dKyLTO0RxK6sHOArTF1RzOC4/BCptFs68ieslPxRggTSJPLS2px GAWrLzReMCefGyY3N4XfQ5SSNOpfSFTaSjGqoRTKsVDgNBTTIzG7RgefHDQzThEHTnThDRQ7 T/HY6yVhH9QiviBjHmL/KWza6w77ISslUUn/UTRE9VLK7gfe7io2tJRMtGMRTwwpN+Xkwozw tbHaTDUuMGvjORUxRWAbI3LhI6BscMbIMMYK/ZLw/dJLVsxwcscxPc+YumDQX6xcYGBdJ8BB JwhQylJ3WOL8NlWXKC8LGJTmYOtS4fUektKcbDS468BknqPU63OzXFO3FDSbWzQxSizuLmwY 8tFVSSYOjdCVSTXPPXW+pwxcnqs0Lew4k063OpXOzVXJXBXakTPTXXLct9I4uEixSucULTJH KGt8LpGRWCgqT9WIc7MsMUBGBjWayjJ0CpMrMLZBM+9HZUfgh3P7OsNKUMbIfrGROjRsVeo2 ZS9cl7UZNOQ3ZrEbAQNTZ1SDZyMHS66u4lFTNtaEMHSXNZNu0k86aKNTajVOQfCnSrZwNLaH LXa3aMserXPBa5Bg0uZ1Zs/5RwX7VbR2eJbXR86xa5KlUda5SKzzPJP5bhaawi6waXLpQXZ3 b7UzavSpFrNZcAUfS0BjbpS9cVa+atQA+O/7RKBqT5PPXZWObnTWNK+2OjQfQJcpNzTiqzEJ aFcrN1OZc5G4izKPdSnxQhdBctEHcndNGSiBdhPhbPRcnhPBb6NBRnUhRaVXbTarE5AwYC/X beZTd7cveXbraTCNeUMGUJSYZTeJb+MLetOFFpPnSsNK0klVBtbVRHbxejfGTc5dQC/7dRXH Tte8eHQXdZX7ReX7fk6Bd3UdVvOvfaYDffc1fpXRfvc3fqlNfXKjDzfjgAzxHwrtBxa2YvHl elUc7DHvVVBJU/dAqePVUTgw9COo9Es9gsMRcVdolDU+PZBVIvf5BVVQ75IlH7gbhHOO9Rhj P2PxVm9+Z5VsaSX7AXYo+QclV/L8grWHJbWM9hWlWVJnWZMjJzMoc7iNWRWniUyfXo+VL6Ba YOOihYLsBwslYzJaCYCsCoCRWiYGC/KBiZWdZIypjDjHjKBpjPJu/wd2vZfUqReO05W3gnKb jqa5YOLoMPVdX1Nvi7b9O46xajH5bDUdkTKq8qiVcZajIRXszXkDG5YEMLkLcEMbLNX/YDj/ kKotX1Z3kaxJeqr7KrhuxXhy8SBu6Lh8XyckLoNBYyNwOfV2unY8BABGBlZFMmvFZLY7ZPl7 jnk5X/ZWLfZbbzDar+efZmiKZ0TfBjGI1ul9POPKr+4y9tRo+OQ6lkTXLEzYlCk7muWcVU8t KuSHLQoxmvkmie4WBugTFBaml9njA2wJnIRhSCk7hO5TLDn7ceXuL7U6i9nzDxnpnDIylNoN IRLDnatXdyh02cv6OicOSmBlFkiJeBANeEfkv6RjotH4PYL5oqzZedFQbfo+LzotobpUL0aT A5peeo6vaxcKPjooNBpDIsQNp08JHazJowWMBwNILsqfW4iMPZFwLTRFPBdCSgktnjAsBBqH g8Yyvqa9qhqCOFqpQJqcYzqzqVqngaShqvmhRrgW2dDuOjqpQznlgkvs7FgqjoUSRjrYtoUT rXF/IDU3r4sNroLzqo1nDuRjRFXznpsLdxVSbdr8bnrs8FrsU++u+zBe9iOnGQNtm2Q89y93 VlLfhw/OwsBxPexygZV7i4xugk/nMECcCoLsByDXKC+rskMG+1sq9m++9uMVs2/HYbVouFni L4artFDblguYSCgLiFJbtZtdthmK+rWsN4dbpkuMxZj2eRj7o9b1umi7pHu3p8jNXjuySUBz hJuju0eFhQiGYOt26vk6gEZ9ulvJhlsPgfsi9btpso+5sttxKZt3s7t7s++DpwNKOmaruLL1 I/lo+bMEg0DsDSDmDSDeDdtiLHtm9fttGhsw/Bt0/Fv+xTwDpHmxwKuftLJIwhi1wWukhbwd whwlwoZRp+M2k8L5GQNylSMCwhe8pwksk9gjHktJxw2zqeiMBsUzdDxtqqRbE7x4BhxoZSxc YnyCUJyGQ/x62zyQY3rJAwktlVLiYHxyNyM9LvxLYrqKkeufJSMNvJJaBuBeNyBfQSTgBwB1 LEB1DUBACCCbl9WfmCBRzbzfzjqnzoBtzsMlzzM/mkkrmoYzowxfZhm1w3mjoENBm+SV0aVH oKMAh+U9nOQnnQsH0rOyh/dP0tvkjxN/1NbAOF0vN068L3Qc9RowL5Q2qGMnowLSll1dfe8F 0v05BX10sH151GkbmqgRzA83Ggod0TnXOyBmwSrc692dkN06O70/1xBITX2MQ7DR2aL5N8QM gR29VjYgMB2l2h3Lvw7x3QMRGBoH2uo32j2fa721k33J203n3B3N2JqsruRjmyox2S0x2X1C NSrvkU8T4Ndx0/2t2Z4K0D254LYl3UNz4lEGML37n2vkzS3N4jnu2Vml1umL4uXfOR4T2Ivl 4fhn4wfbeCRLqANCL8OpJWaBUcrBo3Bno6LGrQaDWTGQOarQa8NiNlHWjyBuWT5ju4OV6RNn PHSON56OtiQIWT565T52bR6pFnPlBH50qt55sz5/66bR6W2N6hXdxhUON4N+v6aqZjlRa3Bj gpsWROp8NiZN7Br+NDGvLIN5AwZruC7R7V7+7br4s4Z976v63H77706t7p8WfbsVUl8btcaJ 7p7XIZ8P8FYZw/lWZUh+RiebgbwO/ecm/jiENwNNY4BQCuDkDSDoMUDcDf9dJoDQDKNaBDz3 jWc79X9b9f9iDL9n9qDL9vmLuhpv7y7ZB2iHutKsWrvQeYgLTqcAYON/+gsf6MW3WTBPuj+P hXXfvBkgPj6mn36kW3+qSj+cNr/NX9U5veRP/QNCuAfsLmYOeZ+zIZ/F+7w89985wEbmNiBu IALhkIBAVDaDRgIITCTkZxADRiLhoOBkMYIVDHCoudxAKCcbzoZTmOhTBTUDRaMIEMhsN41B SJHY/IZHJSpJyKVIQLhxCp5Pp7DYeNBoMhcM4GNxwLhvAxmMxcMYGMqMMKCZRAZp2ORhA5VX K8LrAICkR6HRRdVhBSrENhAbbPVZ6MRhERgNBAbKGNxrErxdLteL0DSncaPSaWObdcAbRKNS BBdJVPcGNL5fsiMMneYfKrxnp9eLLD8LjcvRMzm8Zlr7qLZTc5jbRatfA8HpdZAtTP9Xl8Rb djjrTPbZitjpYXGqFsoiOL/dbTeKfPM/ArwcqxWtyNuJS4nPhleKpP+xWdlcrXS/CIOnzvB1 +zzOp6et7xB46v5iFOojXo0iyiBuo63Bw1q8IKg4XiMhMBIGgqtKquq3IKjIUCeIwjJsk6Ut 0hKYI7C8MpMBqcogyLlIcxoZrmzQXBqtwZhyFy3BiGiJBA8qtIsiyEtG00BRoGK+oG3sBPcG MhN026hhnAQbxpFsXrfJkWJVKUlxNHkXK6sizRVJ0oNVJkwMjJLbL3IEyyG47OokHKes9N6N R8y00yRGzjSLGbdyvMamTDFy3Sw/aILSGocTg/4QBpGMZxYqEHIMhCNIZFMFISpYYwmKkdIE GwYBmi8KiGOo5DmN45Q0lCVKolqXiomIUVJU1UVVEqFp/SqHhtJCBO6piksC+70RynYay4r9 kS2gcfV5YTisXXderuzNhMG7jHoGwDozYBtnV8+k82k/sqp/a6KMO3bKM60M5y80tsXSyTeV 3dDINq2Nv2pfEsXitV5p6xl/V+41r2mvFoW65NdW8uif23faIye+1i3jKS2O/VjxKM/KtX1h D1YRiS3Y1HD414za2PXkr8ZM/SdMnRAc0pE4bPXAtHIvBIjIspdEIvToYybmcKI6IY3jcMw0 jPUoy1tmFc6ioMUomGz63wG0ZKlYbh5crTQbBG86Bwt2EtXslq24wYa7ZAe02pLGq6uxNosb sj64A2O2L6GdAXWrdlLHZNmXeh+97dvLGcPvr6Ngyu0X40nDbbrfE8mvut4Tx+y7phWaOWia +4niC8ay+eS2Lw/OIlOD65bYuqvo9fTPd1D49DP/ZOq9fXvjQj+5pAAcoHnDUQQBtLrW3UH0 KGau1DotWWcjaOisFo6BAMdSjskVVQ4/0PhR63se0OXuDnp8sxQobFa7ecpBpGTURrG9ix3d 3DBovoa21M0pgNBq/p3KSE1txByX1I6UW6vxasv+BS3X7pWS4nSA583LGNgqkd/za4BP8TUk pyRO34uthG/iAEHX+p4brAF/a2oHmVgyc9KygoQu/UMz85LwmQmZUgzpSZyTlvJUyptoINC6 qiPAVQGr1AUBJBaFYEALwQPje8qwlhLkPKwI7E6KEUoqIjVuw9E5yzYFSKM6UpYNi/oCg8sU G7IzIqNeGCA7hPHWnrftEZGZfzxu7jW7mNy2jxqajoz6O58DzRvgHINkjeEyLFhsDBQ6iSEs 9WyZEGUQ4fMLRwikiINFNEWejEwIIbQ4BlOw+hEb34rqvVjKWU8qX0kqay62WpPpbugjkQMG oMZNGeJ6DIvsc3YS7BBAEqCNHTGomA15bwMEZOMl7L91h95hkDmKjKOc0yozKm0WE76xZaJy nHLZOSzZoJ7gCjYtTAp0nunW11uMxpuF4NXHqQk9Vuqfa1LxRie53TRLdMhPbcY9F4m4z+e8 tKES+jswonkvSgUSMnRJOk9KHRqf+oyb8xyiTyV3OmgdHy1L9nS1ugjjKAlRl5Q5n5laDzHp c385BR34k+BnTclVOWZp0pjL2ftG6fz/hpM+oNBKirwpFR4qB7qV0DocYJJlHZ9JYJUDdZVW Cw1ak6YYnr/FhKaKhHMGRKpCOwn+tSsC4KxGYBijI7kzqr1Zro4SkLVjvwBeBO5qxsK9QgMJ V6Y5FVwT3KhWqwkmaIIFS1YyiZFqfMcsGRGD097JV/TPM+vFX5QWAprTynFOqbU9S8p+zdHi vt1tNNWtdiqYWXsTTRNpc4xtUfitx/hUH5ttg8klxk4oxWQtKXdQMx1GrUncjar9x6pWBNkz 6wdup7FnRlYi6VEDqwlTiT2n10Lcs5nvd65i+biJSBreOqxYkuP3nQja8yK16TPvdQMGV16Y XevqZhQZ/IbyURODRXluAZICWo8eThy5PxqJ69EqJRYlkFI4CgNB4SVBpDEHMEASQnAgCOE4 IgYy9BtDCHiKpK1XRZVjhOPWFsMYaw5h7EBb8RyzRnOTGs5mplDklSywbfEYXzMid5jpO5bz llxOdL1HGczxnbVMsU/p2WyMbcRn7/MfUbx3SiYTbr02OorY2i2ScqVfy3AvMdHsonBUbXHJ mUqd2itBm+0mTs2T/qdnTMmVzK5nytlyENc6t11q7lPAlCMBrgtOkDIegCfVc0YnRoSLpeAz TWavSLE7zwFhDEZq2ZEGsBx1oWwen7F0UojmC4WOtO6j0lljVembASgKhB7WFmbP5w1xnMxu kdaU5OBpbWcvND2u1UT9/mpKrM0R9gdqjDp8yZmqasGGorzlQYmZXSNitqu52xWa+mQjYhiB Vrvb1g9wbS2odPa5Q9s3L2tUWUG5X+bgbjs7b+0d2Gg3nNW9OjimaCdBtO3GlDMWntPcDf3C YJ5J15P4o0hNgO5gDw+pOxbloGyxunjGXdTZe1Ol3i1xi+1x2lq8tEhNsbBo9xSiGcbR2h11 rLVtf458R17xvkOsDUbJOTstz7VOBVqb7N2je9qPSfubzLbXQ+Uah4G1bpoDdxaE6f0TS28r O873YpC5fUN4dBoR0zivVOhde4yuC8/ZsuonIs6BGurLFX5t6jajVwLaapS/zPk8C0m8S72t 3mWmNh6g13obZGf0b3bNDkjrfEtD2V8bpjv5le+608n4gsd7Mk+Vn8RHmqftaeDODpe+nh7n SRkm8FRZ+Ll7lwNz9NqSCnxIizhEGWJVWxYIurH28YD+InYZEZzGUF01lRsd9+ndT4wR5BUa dQNUZJEpCjKeH0LPY6uVZxGxkNpfDzQulLEEVl/NiN9n76UtpfmbZ9G8lcJj/W1sm27SblEz o/c2xztT/vmQz3+qj7/iGq/iSSHBRQogpa8wyx5ZSTZgh4/qab2gqIGIlzCCLaJ57J7YrANg MIMQMovQMoMgNIOhWqVaKzE73cCqKB8p7gvMDcDoEED8EMEYm5EhqB1sGzQZb6xR5wiKuIHB ARypzq4BwS9QsIsZZpg49g6Dz5hpYQpBmJfJN5G8Jyh5fpXsHUJT6UJhcEKajRa8KI6SsqPY 2JsK7L5peEL49kMKjRgUNEHZnJg0Jo6CuJfsKKQkLi6Zb0OpGELBfMJENyObnh9ZhozcKZn8 Hx04+pisKKjUNyZhvCuDIZj8JJ4EQ52sRJk5hwnsNwsI9at5nKSC/g/ySqOhxh5y05455JBp oAnZshVzBgqgoqUjDEEIEANKVUGZ76VwjoIMWZ7EWx9L5g5ZXgp0MIvBnCuL5KRBHT4D5prL RQ9jgixUNhASOYp5IbKRb5icKcPEYcNI0D8L4D8cI6OEO5/8bJGEaJv8ZxnMaxcC9L+a7UZo HMZ8dq5BXcecdkYsPsckfS/ZQsAa/wixXjukMCw5A8Bb2B5BBYECTR5g/prJ6AjAnwyTB4Kj CIKAOoNgNgMgN4O4NzGQOgND3CVrFAjsjEjUjkj0kEkT30VgoEl8YUNsOSr5O0II+JwYn0Ic Iy0sPUSbJ8c0nsQpv4vhGEMKl6EKWsKUPkNg70b0MQwcokp0LrxEMo0BZsmUHjwkqMN0OcpE rEn4xkrcPkQJhkdcasoyr4pYtR2w80pMOw6CXhIyPyZ0swp0uA+0TyuJYoOJycn5mzoirAlQ tSXqpqRAK4EEj4BqG0URE4prz0u0U5SUVMBRr4ngG0V0iSK0WMCgFEXkWsX0W4nAnQKIh8vi ACa6OjlkwJrswg+Y8sw8xMxb1Ux0dgGEyJnZBkykVky8CczIlczci0XcXsWs0MGgBs0h9Uss oMfQGsuQyMgiZz5kq8akYg0EpjokbaCEcJY6u0PM6kqUbkfEasdI2Mrc8kd7G0eMq6TU7MsJ KU7JLE0xtqOcv6Qk1cwbSI9018xAh71EAkUarDUgpEgyTchI/oG7SkCCaAG0isi8jINgOoOE lZ9M5E+U1E+pspFs/Ewpl02E/sAT1KHItbsENNAj16ICTwgVBEiojMwQxVBsk1B9CNCcls5B HkQQ7ivBxopxqw4w8YtR+wn07lIThZersxs1Izoh0k8q/JxlJZfpu5kDX9JKGRcwh4poqFJx Fpv7xTnpwoBtLBxFLZ/9MJxhyJbxu8+wpZxyENMJytMcsK/JzJzpc9I9OjP8hI7k1FJbvquM tgrVMJ1ZjJ1yyRitNJ1Y9dPqQ8uhnCOZlUuZ3pl8VhmT1RrK08Y7BZSR+7tpSxnkhih55iWh Q8g9FqJgIoPEEKWcl8spY5G4qT6gvFH0J64FIcnCCU7tBjcpoUwTwlXNJVVpgtK7AFV1YDsd Xwv55xrpgVVov9VtNlMFYdZqq6zJXAz8M1YVHRIVadMlaKTFWBfNVqQlV4+ZLAG9YdcVZ0LN czs1XakBb1cJGlZKktPFFBXa26OdbQ4B9o2FP9aBqyjVcaRp3kHkuleFbxt1fcTkZRb1e6QS gQ+ywgt0UFSYHBmdEUy6TRoTkaTYttTIjJDgqw90zgEoEAIgMoOwNIMIOgNJpE4qMMeE9JOU YVhtg5xh9tHw5thZXBRNmbK7ChYAzKBqYIiJrdWhwJZVIZZqARrdn5cVhj7wlg9EqCXozFqN dxeCARxlpq1VrItwllnM8tqg1Fr9chdhsFa9MFsQ8TALO9tLpA+6PVZ6NVqFuL+Ntw3Vslto vh4FrZfNpYqaPVYK50Blhj81qyBzVdftvZnNn9Qdgc1xk9v9uBkoulxMS8tqj5n9n5lZ11sF iZmNitStBhbg8KvpSIg9ogukiNFotIitGAFAJoMINYrAFwJIIQwppQNhp0ltndHFro+8y8MV yprqwlosm78dW0cS0tyQljTtXt5ko9u9sd6NrFn14KhVe1n0Q7dd6Q8V7aotaqEw0txd6ZMk 91t95sp97LHl9Mqa51xYqd79Mlqgqd68dV5l+xz1etwqh6TJFlyyPA+NxauN9NSFz1yNqF4N cU2xqOANzFw2BVgQ8WA9SV0FixRUy6ZI+4psMR44uxY9Ugn1kJok4N2F2V2gJoKQPArINN3V VSWi2pccLaPRKRGpGw2F4qbF49WqMUcZbinJMULRahvsx9sJGDAMQEpEK0TSPVXuJY9jAMrt tOI8rN/QgVmK7i0uJ+IC4s9zH6GafeLeJt+eL9K1wdPMTOKGIpGpNdfsSWLhf6j442N2NOOF Rawk/R30GtSli500UtYZKTAwsQp5SNj8wR+MiLCIId3QMIOQEAOYMY7AMoN2F5PdTlexci4x OzSJamHKuV5GHt5ZYS885xgSzqtRQ44Fqb7aXmVNwVrGTOUg+eU2WOVNZ4vmVj99Ndag8GLF tGXBdL/FoE92XOWSoqNWUdPpbuYEweW1dSAM1jvo9xa+U7sM50skHGMeYQ4z2R3NxWaC95AR xhlmChj2auTTHmbpieN2bTvpreclyGCqO10OPrlipFjhAo9bBgu6QkzmRYMuRoEAFwKgJoKG Fl3VlxmFVebIow9Yy1f4v4qV4lomHQ81W8nNpFIthggeh6h+U2jhOWVZdKEpfotGhxJ+j1e2 hovB+JMmkQyGlrblszxOX+aGmEfBieYmkelF9yNWjmni5t8eaAtWmOnNK+oYnujt6OnxRelF 6ls13yOCEpJCyWb7IGjuA2eOc2n9dmiVRZiqzpiejqQmeGPOeRRGemDAG7UgiYoyjWDylmfs 3wzUHyJgKWgAMmg93cGZW+hcYSOo6V4Kvy6o8VWZk6OsO14Np1jE7ESq5oppAQ1BFea8pGwG KFHq1Wy2yagtK7Q+yUQ98GUEIdpNL+yAzGzZuu02yWwSzOxmxN02ZbYY9m0FMm2RvuzBfOxG I+3GbGv87+zaeBGWddy9QDQ6uO26aueFiWw89l4I9b624eBxjwlsn+5Fzlx+5es+PmDBu8Rm Dg2GuBGIHN1ZV7CIIIOsEWStnhFKfht25A2BT4++w0tqk9Hm3ClZre4C5sy9h+/SfadMUuxS 1XABGG2ha+P3ApNIwd8JHtL+/m922hgXBGy9oBa++vClZ5eB02/PCJXfDe+2VT6bHm5GV+qE soqyh+/xT9oGNx023e5NzpPZivC+6x0tbeN3FBn/GtiFglz+eeC8UZmzcpJoo28FTTf7AaJA FGu4MgOQMIO+9UQQpspu94qZNMtGT+Hm0ejXKc7HAW2s9mx2I22eyl97aGwO++zvKnA2o/BO zmM9s5H3LvNGYfNvDFu3OfClp0rfL+3pFO00avMTaEte4lMDaG151051xTQ8au52rO7IrU01 cyyRJtXiOI3TbNDs/kxWPetNACtI6W7905QprI4xooFAInJ3KFGvE3GRFJF7ohF7jHUqCyne iorU+cuJ0VDPS1fvWCfN0YgfWkS26U08n/WRDpvGMB1Ls0v50oHNb5hxKR1M1GDg40++r4+P X4t1DCOnaERHYvXM1LolygzfZjonZxMrmbSK3/bU1E5vXfdW6Nhe6iuPdJks1vSCAHZrlhXv eaZ3cXbvfDSPfV3phhF7rlHZRZGyQlH7Re0WjM7vhBblJHfdAlJ6kOyI55ayEPiaxXivjxcs dTgR+dMfBZdvBspHklKtXvlfhRtYG1AlM6pUVSC5T8VRzRw3mPilO/OEQRF6yVJdzPbO+kZ5 jGO9QvbXnZfaHfoZinpSyVR9iHpO7XTxE85rIFTFjjeOEIFAKAOQNINwOjGju7QZGuiiTCM9 4D44uaNnW4iGJouaYwlmG9hSZz4WSyPsvCR75azpyqRntfFnQpGsJ6M3ciRyQGPUf9EJRSYR zoqUhshF/aITokhwiQp9jx6oN4NgOk4qVkEx8IK3zfzp9IgIDQplbmRzdHJlYW0NCmVuZG9i ag0KOSAwIG9iag0KMjE1MDANCmVuZG9iag0KNCAwIG9iag0KPDwNCi9UeXBlIC9QYWdlDQov UGFyZW50IDUgMCBSDQovUmVzb3VyY2VzIDw8DQovRm9udCA8PA0KL0YwIDYgMCBSIA0KL0Yx IDEwIDAgUiANCj4+DQovUHJvY1NldCAyIDAgUg0KPj4NCi9Db250ZW50cyA4IDAgUg0KPj4N CmVuZG9iag0KMTMgMCBvYmoNCjw8DQovTGVuZ3RoIDE0IDAgUg0KL0ZpbHRlciAvTFpXRGVj b2RlIA0KPj4NCnN0cmVhbQ0KgAwFw2EECgkGEByM4gBozgg2GQuGMEGgzFw5GQgGoxiw4GkJ MogMwNgQ3GEZksngouk0ZhUMhwgGcYF0fGQ4Fw1ggxnA0HEgkUkFwyj53hgxEBKo4gNUMlMo lkqp4gKRHhg2Gk5igxGMSjJtq9Zn40rleEBshhTpwuHEbldtpECuFUq0NrddGNfsNaEFkvEZ tANtVCGY0HMrwuHgWJul7nV9GNyn9gBtYvkziMfwODmOYmogymWn+ezVptc/pFIl92mQ5rIz jIyG0Dj4xrNYoEjuQg1ONysR3A0GA5oegq8RHFj4fFzdrj8Cw0/6A5n9VmEU5d63+0vvZs+m oQ5lW963b4IwnA5gmh4EfmevwHgzuuF2w43b5Ot+HfwUMIQqIa4i8ta2b1BAEAqCIkiCwY1Y XiMGAQJwicDiokauhsG4bhnCoxwZBCjBQOg8jgFMEDUBoWoEokPwSEERRJEwqRQIsAN7CLVp ivz6oIm6+Ns7g5JDC7eQY8rLMeGjZKGj7QrEvslxY5oGxunKVPLHUoyaxyKS0/jBum6SaupI y6yRLr1y4yCupjKcdLKmMnLZNceS+hg4uuECIIkiiLIwjSOLYj8hBAK4QDc/0ABnCKyI/BEF QjSKEoWBqIhmGYap/BEPBQIYwjmMsZRpAAozvPM9woiqLoyjaO0GkNDUQBr/0q4gbq3R0EwX STV0tTFNCpTlPVBUQGxqBtSqElqV2Wqccz6xbYpwx6eJqn9CN0qKoWbbTfTOvrDBcGEtsrJ4 aXDcc7KEua5LddqkSwil0XJb9zuJdMpsWwzEX3fTDyOrMkp9Oc5STRb6vi/rWIraL7tEvuDv tfM5t7Z+IMyn8ltxIFXqC3byTM9twBusz2LYsYaZJAeJufMcxOi30dZTkrju5c+VYTMCLvHI sj5Fc7Zvzkzgtha11R1oqfYc5Cx6Sn8pxvSc83soeM2mnbb47Ii429gKKMtCk5LHsCCahIqB BrK66x1smHa8vu25ZMkwzLNQaBtPztXrcKb6PeTib7sVwcBp7wKnw9u4sGIcotc4QR9aie2v IdlKlbqp4AvgZLzPm3TnzaIwpid2LZd3S3htce85sM1dBzuJsZf1+X/M2382rs/4KnfGJq0u FJjxfG3pJ/g97dWPyLxQchrOuNNrrLc3XIvUZq3HNxXemmceyMmeOz+6bpePt+xpbuev7uJv EjOQeqmzI/LjflzrN3d+ZOOavzxf7bLw2XJWzBujyiLLSTmYVcTk2POXgUstxQNXmA1gI5Fo y2HKrbcsstzK1AblZRY4IGMG30P9dJCMtz4oPwceGj+ECUn+uxPqv2F7tE1Qnc8tSBxOWcp5 BjDeCDnjUQ8hy9JiqlHgA1ZI455xvHoQUeQ9Q8xtQbqWb09qD8UnvMtgA/6E0UWEPwihFZ9L PInJ7Y3Fw9EXjeRGeM/SNMR3ssnjbGt/sWY6Jkga8xvqPjRlZjPExBhCGLN3JxFFx7JDOqCe ipIhCRyLEUQ2uJeiri+yPXw/1tJUJLlvZjI4iy6TQyNknJ13xnJHHIYdKBlMpjAyKKGmQ8pg 28EDknKaT8spBNGjZLdpUtSPNwckuqWKOouGTKuRZtkg4gzHJY3qVANpkPeW5NElTFgby/cg TuX8TIFwXbUmoHLJG9JPm+cyETpoSROJjOOcJfJ1PehdO9fcGSCHqIumlcpfJqy4PkQSfMuy 9k/n64VhUTWpGsBwdBx5s2NxLcpQRnx3H5OBfwT+iNAmdRYbnFp1IIKKxoo7GF9bPWQ0QeZJ 59qEqERsoOZ9kx+aVyjVMaxVCfVVqAkkoRWKiUqMkXSDiUSFVIR/oK6EGTjEOovCcFR3Aa1i rHWSnimToaaJ/VbIinCh6dETTnT6SFQFdoNUpUSoym6kVKIvUxE6xlSFLa4xaccSCIrUoYUF qJ5VMo/c4fYyldzUV5iClWTMJq/H3rutSwbcmXtzN9YUnbnIz17avRyNzfrJPGsgnOt9MAG1 QJjTNiFNaqy9qurJWiBSdgwIFGdR9X0cKUK6DgjAN6jgoCkGUOwaQ5hpDeG6pta7NqnqlZ+q igbRKwqwrNABs5CGRtSsCoKvLXFstjbO2tt7c27t6sgp0f5ZMWqLKYGUhiCU3obdwgkjJZVF ZxKeRF6izMTky2hyx1aN3uQHLVHs42Vz7cfPRoUxb03+oFKyot9DwSxvy0GYhlZQXfL5GzBx j5eE2JoY9KcwcExwlqTHB1Fk84dvZfmVV/AZAzQxIVOsfIEG6vMt7BpDnO4TcfjB0UlnLXxT m+LEps3WYMvTjR/jv0eqYprfjGbzE/yru5gU30sMX5ImZj9NmQZSYzyneyXuJcr4XmNkPKF7 MOYmllhDMU9sEZWzHfwvJJTY3iL7AeROLb0E7BlHjBcsZel5zs97HGOMDGsz01XEJvM66CjZ oGk2Ps6Uld9gSVxdcnSy0RJHSQMjoYe0BpZo2Ms1z6YVhjQmjMwZ0zZZTTshMjaniCbvVic2 LKLQwxnNy1UDTafUSvW5AtbviNgZLUZMtNH5jZr07mG7x6aNxKt7+yyPyvwAZ3ZGlDOgw1jZ TWBA87yg2vM6YBFkB7ENxLXb+1Ka7D3I7nZ949z6rqFq/YOspZPkgpmfa7jnyOL2w9HaZXc2 yI3k5SzhD7gqquHeRQtx1aF4UuhxSRqXjKLNm0pBAbQGoPQjOBCqFyhg1Q5WS1NRSkIgReEE OYIA0h05MHO7NT7gOd4Iqy4jHac3ISoRLhdQuHEZ4g0bifFUIAg4wgjjWdeOrBJWScHPIQqI h5JyblFuOV1srAnnYhNqFPPSC5SutIzcKXz3S00eRG+tmLilYjOvOxZ3ZF17Q0c6MwAW92vI miYyHu01ZraFCOwbApSeDgKeuBt5ptVa41pEAAtc4gY2EprVyKoKhgsgNajkCLy47kQKAoB1 DYGwOocDQBhDoGjqNv6o8u8FaHmXCPDqB50DLxiuvHGr8hDvyZXvLdLRf5nzfnfP+h9GpHSV BTOnCc04R7ZZptZ+pF1QGzuG9Z7Id87a3zd8mh+h9TbmSkV9v0fgf6+1fraCMK2jKnVPiYSK vA/nX5/ymV1F9H6v6au/jTnsP4md/of3ePu2Il4/qE/qiocCVkWN5v1CZPiD7HyHNvCCgvhr mr+iWCDnuo/NWPhP/LlICD7N3pEuzNcMbpujWAZgcGSJek5D7QRQSO8LxwRpZQTOdQWMgvgD nsmi9wTwYHPQTgbQMPpwdndCZQdJlpgMVCZQbk5IziHLTQeJ6wcOdQgEDF8v+OqQWMsrIt/i glvwkGjQFMToKDOwgEWI9QBmtPSDOiTM4HOLloBigOZlaDJLYOcMZv5ouJCOekHikCcD8uhO agbAckDKyAUAiA5Awg7vfsWmLCdHmHHFVNuHuD7QuiCIjHmFbrPtuQrCRgbjiNuREHjN7vyN 9RIAbI8LhCoQCHKLOjMxKDURPRHugCIkDRFkxRSigxMN8k9mWkWHuMVvSlUvBRLDKkJuBDPi yoeqqiYt5mSKqAbxJLGwIwxHoxaNuRbRnKqiCN5xgPAHOiyxJxfEMqarPHyRqHoiAg0KZW5k c3RyZWFtDQplbmRvYmoNCjE0IDAgb2JqDQoyNjc3DQplbmRvYmoNCjEyIDAgb2JqDQo8PA0K L1R5cGUgL1BhZ2UNCi9QYXJlbnQgNSAwIFINCi9SZXNvdXJjZXMgPDwNCi9Gb250IDw8DQov RjAgNiAwIFIgDQovRjEgMTAgMCBSIA0KPj4NCi9Qcm9jU2V0IDIgMCBSDQo+Pg0KL0NvbnRl bnRzIDEzIDAgUg0KPj4NCmVuZG9iag0KNiAwIG9iag0KPDwNCi9UeXBlIC9Gb250DQovU3Vi dHlwZSAvVHJ1ZVR5cGUNCi9OYW1lIC9GMA0KL0Jhc2VGb250IC9OZXdzR290aGljTVQsQm9s ZA0KL0ZpcnN0Q2hhciAzMQ0KL0xhc3RDaGFyIDI1NQ0KL1dpZHRocyBbIDc1MCAzMTMgMzY1 IDQ3OSA2NjcgNjc3IDkzOCA3ODEgMjQwIDM2NSAzNjUgNDY5IDY2NyAzMTMgMzY1IDMxMyAN CjU4MyA2MjUgNjI1IDYyNSA2MjUgNjI1IDYyNSA2MjUgNjI1IDYyNSA2MjUgMzY1IDM2NSA2 NjcgNjY3IDY2NyANCjQ2OSA5NzkgNjc3IDcxOSA2ODggNzQwIDYzNSA1ODMgNzUwIDc1MCAz NDQgNTQyIDcwOCA1NzMgODg1IDc4MSANCjc1MCA2OTggNzUwIDY5OCA2NTYgNjM1IDc2MCA2 MjUgODg1IDY3NyA2MjUgNjI1IDM2NSA1ODMgMzY1IDU4MyANCjUwMCAzMzMgNTYzIDYxNSA1 MzEgNjE1IDU3MyAzNDQgNTczIDU5NCAzMjMgMzIzIDU3MyAzMzMgOTE3IDU5NCANCjU3MyA2 MTUgNjA0IDQyNyA1MzEgMzY1IDU5NCA1MDAgNzYwIDUwMCA1MjEgNDkwIDM4NSA1ODMgMzg1 IDY1NiANCjc1MCA3NTAgNzUwIDMxMyA1NjMgNTczIDkzOCA1MjEgNTIxIDMzMyAxNDI3IDY1 NiAzMDIgOTc5IDc1MCA3NTAgDQo3NTAgNzUwIDMxMyAzMTMgNTczIDU3MyAzNTQgNTAwIDEw MDAgMzMzIDEwMDAgNTMxIDMwMiA5MjcgNzUwIDc1MCANCjYyNSAzMTMgMzY1IDQ2OSA2MjUg Njk4IDYyNSA1ODMgNTIxIDMzMyA3NDAgMzc1IDUyMSA2NjcgMzY1IDc0MCANCjUwMCAzOTYg NjY3IDMxMyAzMTMgMzMzIDYxNSA1NTIgMzEzIDMzMyAzMTMgMzc1IDUyMSA5MzggOTM4IDkz OCANCjQ2OSA2NzcgNjc3IDY3NyA2NzcgNjc3IDY3NyA5MzggNjg4IDYzNSA2MzUgNjM1IDYz NSAzNDQgMzQ0IDM0NCANCjM0NCA3NDAgNzgxIDc1MCA3NTAgNzUwIDc1MCA3NTAgNjY3IDc1 MCA3NjAgNzYwIDc2MCA3NjAgNjI1IDY5OCANCjU5NCA1NjMgNTYzIDU2MyA1NjMgNTYzIDU2 MyA5MTcgNTMxIDU3MyA1NzMgNTczIDU3MyAzMjMgMzIzIDMyMyANCjMyMyA1NzMgNTk0IDU3 MyA1NzMgNTczIDU3MyA1NzMgNjY3IDU3MyA1OTQgNTk0IDU5NCA1OTQgNTIxIDYxNSANCjUy MSBdDQovRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZw0KL0ZvbnREZXNjcmlwdG9yIDcgMCBS DQo+Pg0KZW5kb2JqDQo3IDAgb2JqDQo8PA0KL1R5cGUgL0ZvbnREZXNjcmlwdG9yDQovRm9u dE5hbWUgL05ld3NHb3RoaWNNVCxCb2xkDQovRmxhZ3MgMTY0MTYNCi9Gb250QkJveCBbIC0y NTAgLTIzNSAxNzY1IDk3MSBdDQovTWlzc2luZ1dpZHRoIDc5NA0KL1N0ZW1WIDI0MA0KL1N0 ZW1IIDI0MA0KL0l0YWxpY0FuZ2xlIDANCi9DYXBIZWlnaHQgOTcxDQovWEhlaWdodCA2NzkN Ci9Bc2NlbnQgOTcxDQovRGVzY2VudCAyMzUNCi9MZWFkaW5nIDIwNg0KL01heFdpZHRoIDE0 NzENCi9BdmdXaWR0aCA1MjkNCj4+DQplbmRvYmoNCjEwIDAgb2JqDQo8PA0KL1R5cGUgL0Zv bnQNCi9TdWJ0eXBlIC9UcnVlVHlwZQ0KL05hbWUgL0YxDQovQmFzZUZvbnQgL05ld3NHb3Ro aWNNVA0KL0ZpcnN0Q2hhciAzMQ0KL0xhc3RDaGFyIDI1NQ0KL1dpZHRocyBbIDc1MCAzMTMg MzEzIDI4MSA2NjcgNjI1IDkzOCA3MjkgMjE5IDM2NSAzNjUgNDY5IDY2NyAzMTMgMzEzIDMx MyANCjUzMSA2MjUgNjI1IDYyNSA2MjUgNjI1IDYyNSA2MjUgNjI1IDYyNSA2MjUgMzEzIDMx MyA2NjcgNjY3IDY2NyANCjQxNyAxMDEwIDYzNSA3MDggNjc3IDcyOSA2MjUgNTczIDcxOSA3 NDAgMzIzIDUwMCA2NjcgNTczIDg4NSA3NjAgDQo3MjkgNjc3IDcyOSA2NzcgNjQ2IDYxNSA3 NDAgNjI1IDg4NSA2MzUgNjA0IDYxNSAzNjUgNTMxIDM2NSA2NTYgDQo1MDAgMzMzIDU2MyA2 MTUgNTMxIDYxNSA1NDIgMzIzIDU3MyA1OTQgMjgxIDI3MSA1NDIgMjgxIDkzOCA1OTQgDQo1 NzMgNjE1IDYxNSA0MDYgNTEwIDM2NSA1OTQgNDc5IDcyOSA1MDAgNTEwIDUyMSAzMzMgNTMx IDMzMyA2NTYgDQo3NTAgNzUwIDc1MCAzMTMgNTUyIDQ2OSA5MzggNTIxIDUyMSAzMzMgMTM5 NiA2NDYgMjYwIDk1OCA3NTAgNzUwIA0KNzUwIDc1MCAzMTMgMzEzIDQ2OSA0NjkgMzU0IDUw MCAxMDAwIDMzMyAxMDAwIDUxMCAyNjAgOTI3IDc1MCA3NTAgDQo2MDQgMzEzIDMxMyA0Njkg NjI1IDY4OCA2MDQgNTMxIDUyMSAzMzMgNzQwIDM3NSA0NjkgNjY3IDMxMyA3NDAgDQo1MDAg Mzk2IDY2NyAzMTMgMzEzIDMzMyA1NTIgNjQ2IDI2MCAzMzMgMzEzIDM3NSA0NjkgOTM4IDkz OCA5MzggDQo0MTcgNjM1IDYzNSA2MzUgNjM1IDYzNSA2MzUgOTE3IDY3NyA2MjUgNjI1IDYy NSA2MjUgMzIzIDMyMyAzMjMgDQozMjMgNzI5IDc2MCA3MjkgNzI5IDcyOSA3MjkgNzI5IDY2 NyA3MjkgNzQwIDc0MCA3NDAgNzQwIDYwNCA2NzcgDQo2NDYgNTYzIDU2MyA1NjMgNTYzIDU2 MyA1NjMgOTA2IDUzMSA1NDIgNTQyIDU0MiA1NDIgMjgxIDI4MSAyODEgDQoyODEgNTczIDU5 NCA1NzMgNTczIDU3MyA1NzMgNTczIDY2NyA1NzMgNTk0IDU5NCA1OTQgNTk0IDUxMCA2MTUg DQo1MTAgXQ0KL0VuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcNCi9Gb250RGVzY3JpcHRvciAx MSAwIFINCj4+DQplbmRvYmoNCjExIDAgb2JqDQo8PA0KL1R5cGUgL0ZvbnREZXNjcmlwdG9y DQovRm9udE5hbWUgL05ld3NHb3RoaWNNVA0KL0ZsYWdzIDMyDQovRm9udEJCb3ggWyAtMjUw IC0yMTYgMTU1NiA5NzMgXQ0KL01pc3NpbmdXaWR0aCA2NDkNCi9TdGVtViA3OQ0KL1N0ZW1I IDc5DQovSXRhbGljQW5nbGUgMA0KL0NhcEhlaWdodCA5NzMNCi9YSGVpZ2h0IDY4MQ0KL0Fz Y2VudCA5NzMNCi9EZXNjZW50IDIxNg0KL0xlYWRpbmcgMTg5DQovTWF4V2lkdGggMTI5Nw0K L0F2Z1dpZHRoIDQzMg0KPj4NCmVuZG9iag0KMiAwIG9iag0KWyAvUERGIC9UZXh0IC9JbWFn ZUIgL0ltYWdlSSAgXQ0KZW5kb2JqDQo1IDAgb2JqDQo8PA0KL0tpZHMgWzQgMCBSIDEyIDAg UiBdDQovQ291bnQgMg0KL1R5cGUgL1BhZ2VzDQovTWVkaWFCb3ggWyAwIDAgNzkyIDYxMiBd DQo+Pg0KZW5kb2JqDQoxIDAgb2JqDQo8PA0KL0NyZWF0b3IgKExhYnZpZXcgRG9jdW1lbnQp DQovQ3JlYXRpb25EYXRlIChXZWRuZXNkYXksIEp1bHkgMTIsIDIwMDAgODo0Njo1MiBBTSkN Ci9UaXRsZSAoRG9jdW1lbnQpDQovQXV0aG9yIChVbmtub3duKQ0KL1Byb2R1Y2VyIChBY3Jv YmF0IFBERldyaXRlciAzLjAyIGZvciBXaW5kb3dzKQ0KL0tleXdvcmRzICgpDQovU3ViamVj dCAoKQ0KPj4NCmVuZG9iag0KMyAwIG9iag0KPDwNCi9QYWdlcyA1IDAgUg0KL1R5cGUgL0Nh dGFsb2cNCi9EZWZhdWx0R3JheSAxNSAwIFINCi9EZWZhdWx0UkdCICAxNiAwIFINCj4+DQpl bmRvYmoNCjE1IDAgb2JqDQpbL0NhbEdyYXkNCjw8DQovV2hpdGVQb2ludCBbMC45NTA1IDEg MS4wODkxIF0NCi9HYW1tYSAwLjI0NjggDQo+Pg0KXQ0KZW5kb2JqDQoxNiAwIG9iag0KWy9D YWxSR0INCjw8DQovV2hpdGVQb2ludCBbMC45NTA1IDEgMS4wODkxIF0NCi9HYW1tYSBbMC4y NDY4IDAuMjQ2OCAwLjI0NjggXQ0KL01hdHJpeCBbMC40MzYxIDAuMjIyNSAwLjAxMzkgMC4z ODUxIDAuNzE2OSAwLjA5NzEgMC4xNDMxIDAuMDYwNiAwLjcxNDEgXQ0KPj4NCl0NCmVuZG9i ag0KeHJlZg0KMCAxNw0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDI3NjYyIDAwMDAwIG4N CjAwMDAwMjc1MTMgMDAwMDAgbg0KMDAwMDAyNzg4MiAwMDAwMCBuDQowMDAwMDIxNjI3IDAw MDAwIG4NCjAwMDAwMjc1NjMgMDAwMDAgbg0KMDAwMDAyNDcwMiAwMDAwMCBuDQowMDAwMDI1 ODI2IDAwMDAwIG4NCjAwMDAwMDAwMjEgMDAwMDAgbg0KMDAwMDAyMTYwMyAwMDAwMCBuDQow MDAwMDI2MTEzIDAwMDAwIG4NCjAwMDAwMjcyMzUgMDAwMDAgbg0KMDAwMDAyNDU1NiAwMDAw MCBuDQowMDAwMDIxNzcxIDAwMDAwIG4NCjAwMDAwMjQ1MzIgMDAwMDAgbg0KMDAwMDAyNzk3 OSAwMDAwMCBuDQowMDAwMDI4MDY3IDAwMDAwIG4NCnRyYWlsZXINCjw8DQovU2l6ZSAxNw0K L1Jvb3QgMyAwIFINCi9JbmZvIDEgMCBSDQovSUQgWzxkYWZiNDNmNTQxMzVlMDdmMjhkMjI0 MTFjYWMxYTQ5ZT48ZGFmYjQzZjU0MTM1ZTA3ZjI4ZDIyNDExY2FjMWE0OWU+XQ0KPj4NCnN0 YXJ0eHJlZg0KMjgyNDUNCiUlRU9GDQo= --------------3BA6CD5C72C0AC53052914AD-- From owner-ibis Wed Jul 12 09:42:23 2000 Received: from gateway.sequent.com (gateway.sequent.com [192.148.1.10]) by server.eda.org (8.8.5/8.8.3) with ESMTP id JAA22322 for ; Wed, 12 Jul 2000 09:42:23 -0700 (PDT) Received: from chaos.sequent.com (chaos.sequent.com [138.95.19.10]) by gateway.sequent.com (8.9.3/8.8.5) with ESMTP id JAA28706 for ; Wed, 12 Jul 2000 09:39:36 -0700 (PDT) Received: by chaos.sequent.com with Internet Mail Service (5.5.2651.58) id <3T28WJTB>; Wed, 12 Jul 2000 09:39:35 -0700 Message-ID: <0593FCC88F76D2118B4400E029249BD907E5A703@wingnut.sequent.com> From: "Le, Dat (dle)" To: ibis-users@eda.org Cc: "Le, Dat (dle)" Subject: How to create AGTL+ Hspice behavioral model Date: Wed, 12 Jul 2000 09:39:43 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain All, For preliminary SI investigation work, it might be beneficial to run simulations with Hspice behavioral like I-V lookup tables, rather than Hspice model itself. I'm interested to hear suggestions on how to generate a behavioral Hspice AGTL+ I/O buffer. Thanks in advance. Dat Le ***************************************** Signal Integrity Engineer IBM Webservers (formerly Sequent) dtle@us.ibm.com (503)578-3412 ***************************************** From owner-ibis Mon Jul 17 13:05:57 2000 Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by server.eda.org (8.8.5/8.8.3) with ESMTP id NAA10025 for ; Mon, 17 Jul 2000 13:05:56 -0700 (PDT) Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.30 2000/06/08 18:25:35 dmccart Exp $) with SMTP id UAA25346; Mon, 17 Jul 2000 20:04:26 GMT Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 17 Jul 2000 20:03:30 0000 (GMT) Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 17 Jul 2000 13:03:29 -0700 Message-ID: <4575832C8E71D111AC4100A0C96B512706458C9B@fmsmsx36.fm.intel.com> From: "Muranyi, Arpad" To: "'Le, Dat (dle)'" , ibis-users@eda.org Subject: RE: How to create AGTL+ Hspice behavioral model Date: Mon, 17 Jul 2000 13:03:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Did you try the B-element with IBIS models? Arpad Muranyi Intel Corporation ============================================= -----Original Message----- From: Le, Dat (dle) [mailto:dle@sequent.com] Sent: Wednesday, July 12, 2000 9:40 AM To: ibis-users@eda.org Cc: Le, Dat (dle) Subject: How to create AGTL+ Hspice behavioral model All, For preliminary SI investigation work, it might be beneficial to run simulations with Hspice behavioral like I-V lookup tables, rather than Hspice model itself. I'm interested to hear suggestions on how to generate a behavioral Hspice AGTL+ I/O buffer. Thanks in advance. Dat Le ***************************************** Signal Integrity Engineer IBM Webservers (formerly Sequent) dtle@us.ibm.com (503)578-3412 ***************************************** From owner-ibis Wed Jul 19 06:13:35 2000 Received: from tower.ti.com (tower.ti.com [192.94.94.5]) by server.eda.org (8.8.5/8.8.3) with ESMTP id GAA17689 for ; Wed, 19 Jul 2000 06:13:34 -0700 (PDT) Received: from dlep6.itg.ti.com ([157.170.188.9]) by tower.ti.com (8.10.2/8.10.1) with ESMTP id e6JDAin00370 for ; Wed, 19 Jul 2000 08:10:44 -0500 (CDT) Received: from dlep6.itg.ti.com (localhost [127.0.0.1]) by dlep6.itg.ti.com (8.9.3/8.9.3) with ESMTP id IAA15592 for ; Wed, 19 Jul 2000 08:10:39 -0500 (CDT) Received: from dlep4.itg.ti.com (dlep4.itg.ti.com [157.170.188.63]) by dlep6.itg.ti.com (8.9.3/8.9.3) with ESMTP id IAA15586 for ; Wed, 19 Jul 2000 08:10:39 -0500 (CDT) Received: from ti.com (lta0460542.sh.sc.ti.com [158.218.201.142]) by dlep4.itg.ti.com (8.9.3/8.9.3) with ESMTP id IAA05034 for ; Wed, 19 Jul 2000 08:10:43 -0500 (CDT) Message-ID: <3975A8DD.C4A6F243@ti.com> Date: Wed, 19 Jul 2000 08:10:53 -0500 From: Stephen Nolan Organization: Texas Instruments Incorporated X-Sender: "Stephen Nolan" <@dshmail.itg.ti.com> (Unverified) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en,ja,ko MIME-Version: 1.0 To: ibis-users@eda.org Subject: IBIS question - 100 points in a table Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit IBIS gurus, another puzzling question: In IBIS 3.2 spec, the 100 points limit is worded as follows: | All four columns are required under these keywords. However, | data is only required in the typical column. If minimum | and/or maximum current values are not available, the reserved | word "NA" must be used. "NA" can be used for currents in the | typical column, but numeric values MUST be specified for the | first and last voltage points on any I-V table. Each I-V | table must have at least 2, but not more than 100, voltage | points. When doing the best-100 points data-reduction algorithm, the data points that are included should have the highest density around the areas of inflection in the curves. However the inflection points for each of the three curves (typ, min, max) might not be coincident on the x axis. So the way I read this, if you have reduced the data to the best 100 points for each curve, the x axis points may not be coincident for y axis data points on each of the three curves. Therefore you will likely have several rows with data points in only one of the three columns and NA in the other two. Example: | V Ityp Imin Imax -5 DATA DATA DATA |The first line must always have data -4.9 DATA NA NA |in all three columns. ... -4.5 NA DATA NA ... -4.1 NA NA DATA ... 10 DATA DATA DATA |Last line must have data in all 3. Now the question is in the interpretation of the line "Each I-V table must have at least 2, but not more than 100, voltage points." Does this mean that each aggregate table can only have a maximum of 100 rows of data (100 x axis points)? Or does this mean that each column in the table can contain a maximum of 100 y axis points? If the former, then you might end up with less than 33 useable data points in any one of the three columns. If the latter, then you would have a full 100 data points in each column, but the aggregate table would almost assuredly contain more than 100 rows. Thanks. -- Regards, Stephen M. Nolan From owner-ibis Wed Jul 19 06:33:05 2000 Received: from gatekeep.ti.com (gatekeep.ti.com [192.94.94.61]) by server.eda.org (8.8.5/8.8.3) with ESMTP id GAA17805 for ; Wed, 19 Jul 2000 06:33:05 -0700 (PDT) Received: from dlep7.itg.ti.com ([157.170.134.103]) by gatekeep.ti.com (8.10.2/8.10.1) with ESMTP id e6JDUEH10323 for ; Wed, 19 Jul 2000 08:30:14 -0500 (CDT) Received: from dlep7.itg.ti.com (localhost [127.0.0.1]) by dlep7.itg.ti.com (8.9.3/8.9.3) with ESMTP id IAA20837 for ; Wed, 19 Jul 2000 08:30:06 -0500 (CDT) Received: from dlep4.itg.ti.com (dlep4.itg.ti.com [157.170.188.63]) by dlep7.itg.ti.com (8.9.3/8.9.3) with ESMTP id IAA20828 for ; Wed, 19 Jul 2000 08:30:06 -0500 (CDT) Received: from ti.com (lta0460542.sh.sc.ti.com [158.218.201.142]) by dlep4.itg.ti.com (8.9.3/8.9.3) with ESMTP id IAA16602 for ; Wed, 19 Jul 2000 08:30:12 -0500 (CDT) Message-ID: <3975AD6E.4CECC060@ti.com> Date: Wed, 19 Jul 2000 08:30:22 -0500 From: Stephen Nolan Organization: Texas Instruments Incorporated X-Sender: "Stephen Nolan" <@dshmail.itg.ti.com> (Unverified) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en,ja,ko MIME-Version: 1.0 To: ibis-users@eda.org Subject: Series MOSFET model Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit IBIS experts, please help with another question. When making an IBIS model of a FET switch, the IBIS spec calls for the following model: | The model is: | | Table Current | -------> | + Vds - | Pin 1 Pin 2 | <---| |---> + | d |_____| - s | --+-- Vgs Vs | | g + | - | | Vg = [Voltage Range] = Vcc | Vgs = Table Voltage = Vtable = Vcc - Vs | Ids = Table Current for a given Vcc and Vds The table voltage that is reported is Vgs, the voltage difference between pin 2 (in this example) and the gate voltage (usually Vcc). This is an entirely adequate model for n-FET only series switches, however several FET switch devices use a full transmission-gate (n-FET in parallel with p-FET). When the switch is enabled [On] the gate of the n-FET is usually at Vcc and the gate of the p-FET is usually at ground. GND | o ===== | | p-FET --| |-- | | ----+-| |-+---- |_____| n-FET --+-- | Vcc The question, obviously is "Which Vgs do I report in the table?" -- Regards, Stephen M. Nolan From owner-ibis Wed Jul 19 08:05:22 2000 Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by server.eda.org (8.8.5/8.8.3) with ESMTP id IAA18302 for ; Wed, 19 Jul 2000 08:05:17 -0700 (PDT) Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.30 2000/06/08 18:25:35 dmccart Exp $) with SMTP id PAA19124; Wed, 19 Jul 2000 15:03:51 GMT Received: from fmsmsx17.intel.com ([132.233.48.17]) by 132.233.48.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 19 Jul 2000 15:02:54 0000 (GMT) Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Wed, 19 Jul 2000 08:02:53 -0700 Message-ID: <10C8636AE359D4119118009027AE9987098BB3@FMSMSX34> From: "Muranyi, Arpad" To: "'Stephen Nolan'" , ibis-users@eda.org Subject: RE: IBIS question - 100 points in a table Date: Wed, 19 Jul 2000 08:02:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Stephen, This is exactly the same question I asked many years ago. The specification does not say anything about it. When I brought it up in the Open Forum Teleconference, I believe the answer was that to be safe we should count the X-axis numbers. That is what my program (Ibis Center) does. However, I agree, that this way we may only get 33 points in the Y-axis in the worst case, and I agree we should allow 100 points in the Y-axis. However, the parser does not allow that, even though in my opinion it is still legal according to the spec. That is why I have my algorithm written so that with the flip of an internal constant I can count Y-axis numbers. We did address this issue recently, when the 100 points limitation came up again. As a minimum, I would suggest that we should count Y-axis numbers, but some also suggested that we should eliminate this all together. Arpad Muranyi Intel Corporation =============================================================== -----Original Message----- From: Stephen Nolan [mailto:s-nolan1@ti.com] Sent: Wednesday, July 19, 2000 6:11 AM To: ibis-users@eda.org Subject: IBIS question - 100 points in a table IBIS gurus, another puzzling question: In IBIS 3.2 spec, the 100 points limit is worded as follows: | All four columns are required under these keywords. However, | data is only required in the typical column. If minimum | and/or maximum current values are not available, the reserved | word "NA" must be used. "NA" can be used for currents in the | typical column, but numeric values MUST be specified for the | first and last voltage points on any I-V table. Each I-V | table must have at least 2, but not more than 100, voltage | points. When doing the best-100 points data-reduction algorithm, the data points that are included should have the highest density around the areas of inflection in the curves. However the inflection points for each of the three curves (typ, min, max) might not be coincident on the x axis. So the way I read this, if you have reduced the data to the best 100 points for each curve, the x axis points may not be coincident for y axis data points on each of the three curves. Therefore you will likely have several rows with data points in only one of the three columns and NA in the other two. Example: | V Ityp Imin Imax -5 DATA DATA DATA |The first line must always have data -4.9 DATA NA NA |in all three columns. ... -4.5 NA DATA NA ... -4.1 NA NA DATA ... 10 DATA DATA DATA |Last line must have data in all 3. Now the question is in the interpretation of the line "Each I-V table must have at least 2, but not more than 100, voltage points." Does this mean that each aggregate table can only have a maximum of 100 rows of data (100 x axis points)? Or does this mean that each column in the table can contain a maximum of 100 y axis points? If the former, then you might end up with less than 33 useable data points in any one of the three columns. If the latter, then you would have a full 100 data points in each column, but the aggregate table would almost assuredly contain more than 100 rows. Thanks. -- Regards, Stephen M. Nolan From owner-ibis Wed Jul 19 14:30:58 2000 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id OAA19564 for ; Wed, 19 Jul 2000 14:30:57 -0700 (PDT) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id OAA09088; Wed, 19 Jul 2000 14:28:08 -0700 (PDT) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id OAA24269; Wed, 19 Jul 2000 14:28:07 -0700 (PDT) Sender: bob_ross@mentorg.com Message-ID: <39761D65.100FC390@mentor.com> Date: Wed, 19 Jul 2000 14:28:05 -0700 From: Bob Ross X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Scott McMorrow CC: ibis Subject: Re: [Add Submodel] References: <396BFDFF.5F7F5FFC@vasthorizons.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Scott: You are correct. Bob Ross Mentor Graphics Scott McMorrow wrote: > > All, > > I wanted to clarify and (possibly) confirm my understanding > of Dynamic clamp submodels. > > My understanding is that the following submodel call will > activate the static Power Clamp only when the model is not a > driver (i.e. Input or 3-state mode). When the driver is active > the Power clamp will not be activated. > > Am I correct? > > [Add Submodel] > Bleem Non-Driving > ... > ... > > [Submodel] Bleem > Submodel_type Dynamic_clamp > | > [POWER Clamp] > | voltage I(typ) I(min) I(max) > | > power clamp curves removed for conciseness. > > regards, > > scott > -- > Scott McMorrow > Principal Engineer > SiQual, Signal Quality Engineering > 18735 SW Boones Ferry Road > Tualatin, OR 97062-3090 > (503) 885-1231 > http://www.siqual.com From owner-ibis Thu Jul 20 13:46:25 2000 Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by server.eda.org (8.8.5/8.8.3) with ESMTP id NAA23631 for ; Thu, 20 Jul 2000 13:46:25 -0700 (PDT) Received: by ztxmail04.ztx.compaq.com (Postfix, from userid 12345) id A12981741; Thu, 20 Jul 2000 15:43:34 -0500 (CDT) Received: from exctay-gh02.tay.cpqcorp.net (exctay-gh02.tay.cpqcorp.net [16.103.129.52]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 6456915CA; Thu, 20 Jul 2000 15:43:34 -0500 (CDT) Received: by exctay-gh02.tay.cpqcorp.net with Internet Mail Service (5.5.2650.21) id <3XNZ6A0R>; Thu, 20 Jul 2000 16:43:33 -0400 Message-ID: <212CC57E84B8D111AD780000F84AA049094840DB@mroexc2.tay.dec.com> From: "Ingraham, Andrew" To: "'Al Davis'" Cc: ibis-users@eda.org Subject: RE: Subtracting clamp curves from pull-up/down curves Date: Thu, 20 Jul 2000 16:43:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain From a few weeks ago.... Regarding "the comment": >When you subtract, remember to consider the accuracy of the >measurements. In the usual case, in the region where the clamp is >strong, the things you are subtracting are nearly equal and large, >producing a result near zero. In most models, the >resulting pullup/pulldown in this region is ALL NOISE. Those models >that look like they have a negative resistance region there are >WRONG. The literature says that it doesn't matter because they are >added back by the simulator, but that is not the whole story. You are >better off leaving these points out, even if it means not going the >full -Vcc to +2*Vcc. > >So ... >Look at the curve! Does it make sense? At the ends, where the curve >looks like nonsense, throw those points away. Those warnings from >the parser about "non-monotonic" are real. I don't entirely agree, or maybe I don't see your point. Non-monotonicity only matters for the total current, after the individual tables have been summed together again. If the total current is monotonic, but one of the component curves isn't, it shouldn't really matter, should it? Unless the simulator uses the non-monotonic curve by itself somehow. But you know more about simulators than I do, so maybe you know something I don't. OTOH, I doubt it hurts to smooth out (not LEAVE out!) those points, as long as they really are "noise" and insignificant compared to the stronger clamp current. Regarding "the question": >What should a simulator do with the clamps in the region where the >other clamp applies? > >Extend flat? (constant current) -- sure, if it is 0. What if it >isn't? The current at the splice is double counted. > >Make it 0? -- what if they don't match? The currents might not >match. There might be a gap or overlap. (Consider min or max with a >different reference voltage.) > >Extend last slope? -- this makes sense totally outside, but not here. Yes, this has bothered me for a while. Personally, I think that all four curves ... Pullup, Pulldown, and both Clamps ... should be defined in all IBIS models for I/O (pin) voltages over the range from GND-POWER to POWER+POWER ... the whole works. This would force model makers into thinking about how to cut (and how the simulator will splice) their two clamp currents. The clamp tables might be zero over half or more of this range, but far better to have it specified that way in the IBIS data sheet, than to leave it up to chance, or to what the simulator happens to do with a truncated table. The mere fact that a table ends anywhere between GND-POWER and POWER+POWER, is very troubling. What if the current hasn't fallen smoothly to zero where the table ends? Regards, Andy From owner-ibis Thu Jul 20 13:58:06 2000 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id NAA23676 for ; Thu, 20 Jul 2000 13:58:06 -0700 (PDT) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id NAA15657; Thu, 20 Jul 2000 13:55:14 -0700 (PDT) Received: from orwtomda by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id NAA27668; Thu, 20 Jul 2000 13:55:13 -0700 (PDT) Reply-To: From: "Tom Dagostino" To: "'Ingraham, Andrew'" , "'Al Davis'" Cc: Subject: RE: Subtracting clamp curves from pull-up/down curves Date: Thu, 20 Jul 2000 13:55:05 -0700 Message-ID: <001d01bff28c$c86293b0$83532293@wv.mentorg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <212CC57E84B8D111AD780000F84AA049094840DB@mroexc2.tay.dec.com> I have a curiosity question. What are the equations that describe the current in the drain of a FET when Vds is negative for the n channel device or Vds is positive for the p channel device? I would like to know what the drain current is, not the current in the diode. I don't believe some of the equations I have seen. Tom Dagostino IBIS and Tau Modeling Manager BSD Mentor Graphics Corp. 503-685-1613 tom_dagostino@mentor.com -----Original Message----- From: Ingraham, Andrew [mailto:Andrew.Ingraham@compaq.com] Sent: Thursday, July 20, 2000 1:43 PM To: 'Al Davis' Cc: ibis-users@eda.org Subject: RE: Subtracting clamp curves from pull-up/down curves >From a few weeks ago.... Regarding "the comment": >When you subtract, remember to consider the accuracy of the >measurements. In the usual case, in the region where the clamp is >strong, the things you are subtracting are nearly equal and large, >producing a result near zero. In most models, the >resulting pullup/pulldown in this region is ALL NOISE. Those models >that look like they have a negative resistance region there are >WRONG. The literature says that it doesn't matter because they are >added back by the simulator, but that is not the whole story. You are >better off leaving these points out, even if it means not going the >full -Vcc to +2*Vcc. > >So ... >Look at the curve! Does it make sense? At the ends, where the curve >looks like nonsense, throw those points away. Those warnings from >the parser about "non-monotonic" are real. I don't entirely agree, or maybe I don't see your point. Non-monotonicity only matters for the total current, after the individual tables have been summed together again. If the total current is monotonic, but one of the component curves isn't, it shouldn't really matter, should it? Unless the simulator uses the non-monotonic curve by itself somehow. But you know more about simulators than I do, so maybe you know something I don't. OTOH, I doubt it hurts to smooth out (not LEAVE out!) those points, as long as they really are "noise" and insignificant compared to the stronger clamp current. Regarding "the question": >What should a simulator do with the clamps in the region where the >other clamp applies? > >Extend flat? (constant current) -- sure, if it is 0. What if it >isn't? The current at the splice is double counted. > >Make it 0? -- what if they don't match? The currents might not >match. There might be a gap or overlap. (Consider min or max with a >different reference voltage.) > >Extend last slope? -- this makes sense totally outside, but not here. Yes, this has bothered me for a while. Personally, I think that all four curves ... Pullup, Pulldown, and both Clamps ... should be defined in all IBIS models for I/O (pin) voltages over the range from GND-POWER to POWER+POWER ... the whole works. This would force model makers into thinking about how to cut (and how the simulator will splice) their two clamp currents. The clamp tables might be zero over half or more of this range, but far better to have it specified that way in the IBIS data sheet, than to leave it up to chance, or to what the simulator happens to do with a truncated table. The mere fact that a table ends anywhere between GND-POWER and POWER+POWER, is very troubling. What if the current hasn't fallen smoothly to zero where the table ends? Regards, Andy From owner-ibis Thu Jul 20 14:25:58 2000 Received: from gw-nl4.philips.com (gw-nl4.philips.com [192.68.44.36]) by server.eda.org (8.8.5/8.8.3) with ESMTP id OAA23734 for ; Thu, 20 Jul 2000 14:25:57 -0700 (PDT) From: mike.magdaluyo@philips.com Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id XAA13119 for ; Thu, 20 Jul 2000 23:23:35 +0200 (MEST) (envelope-from mike.magdaluyo@philips.com) Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com via mwrap (4.0a) id xma013117; Thu, 20 Jul 00 23:23:35 +0200 Received: from AMLMS01.DIAMOND.PHILIPS.COM (amlms01sv1.diamond.philips.com [161.88.79.213]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id XAA20217 for ; Thu, 20 Jul 2000 23:23:34 +0200 (MET DST) Received: by AMLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via AMEC id 0056910006140733; Thu, 20 Jul 2000 16:21:45 -0500 To: Subject: Ver. 3.2 and Ver. 2.1 Models Message-ID: <0056910006140733000002L132*@MHS> Date: Thu, 20 Jul 2000 16:21:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 07/20/00 16:22:49" Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by server.eda.org id OAA23735 To Model Users and EDA Vendors: Philips Semiconductors offers numerous standard logic Ver. 2.1 IBIS models. We are planning to start generating Ver. 3.2 models but would like your feedback on an issue. We are trying assess how many people have capability to run Ver 3.2 models and who can use only Ver 2.1 models. Due to the number of logic families and products we have, we want to avoid maintaining 2 sets of libraries per product family for both versions, but we need to see that our customers' needs are met too. Your comments would be greatly appreciated. Mike Magdaluyo Logic Products Group Philips Semiconductors (408) 991-2642 From owner-ibis Thu Jul 20 16:26:52 2000 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id QAA24103 for ; Thu, 20 Jul 2000 16:26:51 -0700 (PDT) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id QAA28163; Thu, 20 Jul 2000 16:24:00 -0700 (PDT) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id QAA22660; Thu, 20 Jul 2000 16:23:58 -0700 (PDT) Sender: bob_ross@mentorg.com Message-ID: <39778A0E.9C09D7BE@mentor.com> Date: Thu, 20 Jul 2000 16:23:58 -0700 From: Bob Ross X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: mike.magdaluyo@philips.com CC: ibis-users@eda.org Subject: Re: Ver. 3.2 and Ver. 2.1 Models References: <0056910006140733000002L132*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mike: I would use and supply Version 3.2 models only when Version 3.2 features are needed to accurately describe the part. Otherwise, I would still supply Version 2.1 models. Bob Ross Mentor Graphics mike.magdaluyo@philips.com wrote: > > To Model Users and EDA Vendors: > > Philips Semiconductors offers numerous standard logic Ver. 2.1 IBIS models. We are planning to start generating Ver. 3.2 models but would like your feedback on an issue. We are trying assess how many people have capability to run Ver 3.2 models and who > can use only Ver 2.1 models. Due to the number of logic families and products we have, we want to avoid maintaining 2 sets of libraries per product family for both versions, but we need to see that our customers' needs are met too. Your comments would > be greatly appreciated. > > Mike Magdaluyo > > Logic Products Group > Philips Semiconductors > (408) 991-2642 From owner-ibis Thu Jul 20 16:48:24 2000 Received: from pop.nwlink.com (pop.nwlink.com [209.20.130.39]) by server.eda.org (8.8.5/8.8.3) with ESMTP id QAA24136 for ; Thu, 20 Jul 2000 16:48:23 -0700 (PDT) Received: from ip210.c246.blk1.bel.nwlink.com (ip210.c246.blk1.bel.nwlink.com [209.20.246.210]) by pop.nwlink.com (8.9.3/8.9.3) with SMTP id QAA17843; Thu, 20 Jul 2000 16:46:02 -0700 (PDT) Received: from mail.hyperlynx.com by ip210.c246.blk1.bel.nwlink.com via smtpd (for pop.nwlink.com [209.20.130.39]) with SMTP; 20 Jul 2000 23:45:43 UT Received: from hlgw.hyperlynx.com ([192.168.148.149]) by hazard.hyperlynx.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id QAA23088; Thu, 20 Jul 2000 16:45:55 -0700 Message-ID: <00a101bff2a4$aa461060$9594a8c0@hyperlynx.com> From: "Matthew Flora" To: "Bob Ross" , Cc: Received: from SQUIDGE by hlgw.hyperlynx.com via smtpd (for mail.hyperlynx.com [192.168.149.2]) with SMTP; 20 Jul 2000 23:45:42 UT References: <0056910006140733000002L132*@MHS> <39778A0E.9C09D7BE@mentor.com> Subject: Re: Ver. 3.2 and Ver. 2.1 Models Date: Thu, 20 Jul 2000 16:45:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Dear Mike Magdaluyo, I concur with Bob Ross, except I would suggest still setting the IBIS_ver keyword to 3.2. If nothing else, that will cause IBISCHK3 to use it's most strict syntax/semantic tests. Best regards, Matthew Flora ----- Original Message ----- From: "Bob Ross" To: Cc: Sent: Thursday, July 20, 2000 4:23 PM Subject: Re: Ver. 3.2 and Ver. 2.1 Models > Mike: > > I would use and supply Version 3.2 models only when Version 3.2 features > are needed to accurately describe the part. Otherwise, I would still > supply Version 2.1 models. > > Bob Ross > Mentor Graphics > > mike.magdaluyo@philips.com wrote: > > > > To Model Users and EDA Vendors: > > > > Philips Semiconductors offers numerous standard logic Ver. 2.1 IBIS models. We are planning to start generating Ver. 3.2 models but would like your feedback on an issue. We are trying assess how many people have capability to run Ver 3.2 models and who > > can use only Ver 2.1 models. Due to the number of logic families and products we have, we want to avoid maintaining 2 sets of libraries per product family for both versions, but we need to see that our customers' needs are met too. Your comments would > > be greatly appreciated. > > > > Mike Magdaluyo > > > > Logic Products Group > > Philips Semiconductors > > (408) 991-2642 > From owner-ibis Thu Jul 20 17:22:19 2000 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id RAA24210 for ; Thu, 20 Jul 2000 17:22:18 -0700 (PDT) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id RAA02049; Thu, 20 Jul 2000 17:19:27 -0700 (PDT) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id RAA00833; Thu, 20 Jul 2000 17:19:24 -0700 (PDT) Sender: bob_ross@mentorg.com Message-ID: <3977970C.507773DD@mentor.com> Date: Thu, 20 Jul 2000 17:19:24 -0700 From: Bob Ross X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Nolan CC: ibis-users@eda.org Subject: Re: Series MOSFET model References: <3975AD6E.4CECC060@ti.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Stephen: At this time, I would pretend that this is still an n-FET device and use Vgs based on the "Vcc" node. However, the setup and measurements would be for both the n-FET and p-FET devices in parallel. Bob Ross Mentor Graphics Stephen Nolan wrote: > > IBIS experts, please help with another question. When making an IBIS model of a > FET switch, the IBIS spec calls for the following model: > > | The model is: > | > | Table Current > | -------> > | + Vds - > | Pin 1 Pin 2 > | <---| |---> + > | d |_____| - s > | --+-- Vgs Vs > | | g + > | - > | > | Vg = [Voltage Range] = Vcc > | Vgs = Table Voltage = Vtable = Vcc - Vs > | Ids = Table Current for a given Vcc and Vds > > The table voltage that is reported is Vgs, the voltage difference between pin 2 > (in this example) and the gate voltage (usually Vcc). This is an entirely > adequate model for n-FET only series switches, however several FET switch > devices use a full transmission-gate (n-FET in parallel with p-FET). When the > switch is enabled [On] the gate of the n-FET is usually at Vcc and the gate of > the p-FET is usually at ground. > > GND > | > o > ===== > | | p-FET > --| |-- > | | > ----+-| |-+---- > |_____| n-FET > --+-- > | > Vcc > > The question, obviously is "Which Vgs do I report in the table?" > > -- > Regards, > Stephen M. Nolan From owner-ibis Thu Jul 20 18:02:50 2000 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id SAA24264 for ; Thu, 20 Jul 2000 18:02:49 -0700 (PDT) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id RAA04377; Thu, 20 Jul 2000 17:59:58 -0700 (PDT) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id RAA05868; Thu, 20 Jul 2000 17:59:55 -0700 (PDT) Sender: bob_ross@mentorg.com Message-ID: <3977A08B.30D37012@mentor.com> Date: Thu, 20 Jul 2000 17:59:55 -0700 From: Bob Ross X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Nolan CC: ibis-users@eda.org Subject: Re: Questions about Submodels References: <396C81BD.1CD9F34F@ti.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Stephen: My responses are in your text. Bob Ross Mentor Graphics Stephen Nolan wrote: > > Hi IBIS folks. I'm working on our procedures for creating IBIS models of devices > with Bus Hold, and struggling through this section 6a on Submodels. Help. > > First of all, are submodels a section that is entirely contained within a model > section, or are they independant and inheritable by other models? For example, > if I have an input model: > > |****************************************************************************** > [Model] LVTH244_DATAIN_33 > Model_type Input > Vinl = 0.8V > Vinh = 2.0V > C_comp 3.35pF NA NA > | > [Add Submodel] > BUS_HOLD_33 Non-Driving > | > |****************************************************************************** > > Does the submodel BUS_HOLD_33 have to follow the data in the LVTH244_DATAIN_33 > model and be within that model, or can all of the submodels be at the end of a > file in a separate section following the models? It can be in a separate section. > > Further, once I have declared a "[Submodel] BUS_HOLD_33" submodel within the > LVTH244_DATA_IN_33 model, do I have to include the complete submodel again > within the LVTH244_OE_IN_33 model, or can I just simply call it and expect the > simulator to use it. If submodels do in fact turn out to be local instead of > global and inheritable, is there any namespace conflict? They are global, so there is no namespace conflict. > > Next is the question of data extraction for bus-hold. The clamp curves in the > main model contain all of the data on the VI characteristics of the bus > hold-circuitry. See the attached pdf file for an example. What is the purpose of > the trigger and pullup/down data in the submodel section? What information does > it provide that is not already available in the clamp curves of the main model? > How do you extract the Ramp data (test setup). The clamp information is in addition to the bus hold operation. The clamp tables should have 0 current in the normal operating regions (between 0 and Vcc). The Bus Hold circuitry which are really weak, triggered flip-flops are what the submodel models. The advantage of the submodel approach is that the dynamic effects of the Bus Hold circuit are simulated. The clamp approach would capture only a static (DC) characteristic and assume instantenous Bus Hold Operation. The Bus_hold operation can also be used for dynamic terminations. That is the main motivation for adding this to IBIS. > > Finally, in the spec there is the following sentence: > > | The [Pullup] and [Pulldown] tables both are used to define an internal > > | buffer that is triggered switch to its opposite state. > What does this mean and is this sentence grammatically correct? I can't figure > it out. It should read: | The [Pullup] and [Pulldown] tables both are used to define an internal | buffer that is triggered "to" switch to its opposite state. > > Thanks. > -- > Regards, > Stephen M. Nolan > > -------------------------------------------------------------------------------- > Name: busholdcurves.pdf > busholdcurves.pdf Type: Portable Document Format (application/pdf) > Encoding: base64 From owner-ibis Thu Jul 20 20:08:50 2000 Received: from gatekeep.ti.com (gatekeep.ti.com [192.94.94.61]) by server.eda.org (8.8.5/8.8.3) with ESMTP id UAA24488 for ; Thu, 20 Jul 2000 20:08:49 -0700 (PDT) Received: from dlep6.itg.ti.com ([157.170.188.9]) by gatekeep.ti.com (8.10.2/8.10.1) with ESMTP id e6L35xH25428; Thu, 20 Jul 2000 22:05:59 -0500 (CDT) Received: from dlep6.itg.ti.com (localhost [127.0.0.1]) by dlep6.itg.ti.com (8.9.3/8.9.3) with ESMTP id WAA20202; Thu, 20 Jul 2000 22:05:54 -0500 (CDT) Received: from dlep4.itg.ti.com (dlep4.itg.ti.com [157.170.188.63]) by dlep6.itg.ti.com (8.9.3/8.9.3) with ESMTP id WAA20193; Thu, 20 Jul 2000 22:05:54 -0500 (CDT) Received: from ti.com ([192.168.149.24]) by dlep4.itg.ti.com (8.9.3/8.9.3) with ESMTP id WAA27277; Thu, 20 Jul 2000 22:05:56 -0500 (CDT) Message-ID: <3977BE17.2662CADF@ti.com> Date: Thu, 20 Jul 2000 22:05:59 -0500 From: Stephen Nolan Organization: Texas Instruments Incorporated X-Sender: "Stephen Nolan" <@dshmail.itg.ti.com> (Unverified) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en,ja,ko MIME-Version: 1.0 To: Bob Ross CC: ibis-users@eda.org Subject: Re: Series MOSFET model References: <3975AD6E.4CECC060@ti.com> <3977970C.507773DD@mentor.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I wonder if this will hold true for all simulators. The currents that you get will be unsolvable if you assume that it is only an nFET and you are seeing the pFET in parallel with it. I'd be afraid on nonconvergance, or simulators giving errors about erroneous currents. The only alternate solution that I could provide is to use [Series current] instead of [Series MOSFET]. Thanks, Bob, for answering my questions. -- Regards, Stephen M. Nolan Bob Ross wrote: > > Stephen: > > At this time, I would pretend that this is still an n-FET > device and use Vgs based on the "Vcc" node. However, the > setup and measurements would be for both the n-FET and p-FET > devices in parallel. > > Bob Ross > Mentor Graphics > > Stephen Nolan wrote: > > > > IBIS experts, please help with another question. When making an IBIS model of a > > FET switch, the IBIS spec calls for the following model: > > > > | The model is: > > | > > | Table Current > > | -------> > > | + Vds - > > | Pin 1 Pin 2 > > | <---| |---> + > > | d |_____| - s > > | --+-- Vgs Vs > > | | g + > > | - > > | > > | Vg = [Voltage Range] = Vcc > > | Vgs = Table Voltage = Vtable = Vcc - Vs > > | Ids = Table Current for a given Vcc and Vds > > > > The table voltage that is reported is Vgs, the voltage difference between pin 2 > > (in this example) and the gate voltage (usually Vcc). This is an entirely > > adequate model for n-FET only series switches, however several FET switch > > devices use a full transmission-gate (n-FET in parallel with p-FET). When the > > switch is enabled [On] the gate of the n-FET is usually at Vcc and the gate of > > the p-FET is usually at ground. > > > > GND > > | > > o > > ===== > > | | p-FET > > --| |-- > > | | > > ----+-| |-+---- > > |_____| n-FET > > --+-- > > | > > Vcc > > > > The question, obviously is "Which Vgs do I report in the table?" > > > > -- > > Regards, > > Stephen M. Nolan From owner-ibis Thu Jul 20 20:26:42 2000 Received: from gatekeep.ti.com (gatekeep.ti.com [192.94.94.61]) by server.eda.org (8.8.5/8.8.3) with ESMTP id UAA24543 for ; Thu, 20 Jul 2000 20:26:41 -0700 (PDT) Received: from dlep8.itg.ti.com ([157.170.134.88]) by gatekeep.ti.com (8.10.2/8.10.1) with ESMTP id e6L3NqH07286; Thu, 20 Jul 2000 22:23:52 -0500 (CDT) Received: from dlep8.itg.ti.com (localhost [127.0.0.1]) by dlep8.itg.ti.com (8.9.3/8.9.3) with ESMTP id WAA07590; Thu, 20 Jul 2000 22:23:28 -0500 (CDT) Received: from dlep4.itg.ti.com (dlep4.itg.ti.com [157.170.188.63]) by dlep8.itg.ti.com (8.9.3/8.9.3) with ESMTP id WAA07584; Thu, 20 Jul 2000 22:23:28 -0500 (CDT) Received: from ti.com ([192.168.149.24]) by dlep4.itg.ti.com (8.9.3/8.9.3) with ESMTP id WAA05580; Thu, 20 Jul 2000 22:23:46 -0500 (CDT) Message-ID: <3977C245.D0EE5A6A@ti.com> Date: Thu, 20 Jul 2000 22:23:49 -0500 From: Stephen Nolan Organization: Texas Instruments Incorporated X-Sender: "Stephen Nolan" <@dshmail.itg.ti.com> (Unverified) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en,ja,ko MIME-Version: 1.0 To: Bob Ross CC: ibis-users@eda.org Subject: Re: Questions about Submodels References: <396C81BD.1CD9F34F@ti.com> <3977A08B.30D37012@mentor.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit So regarding data extraction, are the following statements correct? To get the clamp curves of the top-level model, the bus-hold feedback has to be removed from the input. Then in the submodel: For V_trigger: With the bus-hold output connected to the input, sweep the input voltage from low-to-high, and then from high to low and monitor the current at the voltage source. Where the bi-stable flip-flop (bus-hold circuit) transitions from opposing current to aiding current (passes through zero) is the V_trigger point. For Pulldown: With the bus-hold output disconnected from the input, hold the input low, so that the bus-hold output node is low, and sweep the V/I curve of the bus-hold output. Or alternatively, you may be able to hold the input of the bus-hold driver high (inverter) and the bus-hold output will go low. Then sweep the output VI curve. For Pullup: With the bus-hold output disconnected from the input, hold the input high, so that the bus-hold output node is high, and sweep the V/I curve of the bus-hold output. Or alternatively, you may be able to hold the input of the bus-hold driver low (inverter) and the bus-hold output will go high. Then sweep the output VI curve. For Ramp: With the bus-hold output disconnected from the input, and a load capacitance connected to the output of the bus-hold to simulate the load of the input, ramp the input to read the dV/dt output edge-rates at the output of the bus-hold. Or alternatively, you could leave the bus-hold all hooked up and provide the input stimulus at the input of the bus-hold driver stage. For reference, assuming a buffer device ('244) with bus hold, the input stage looks like this: Bus-hold output /| +------o/ |----+ | \ | | | \| | | |\ | PIN O----------+-----| \o-----+----------->off to rest of circuitry Device input | / Input inverter/buffer |/ -- Regards, Stephen M. Nolan Bob Ross wrote: > > Stephen: > > My responses are in your text. > > Bob Ross > Mentor Graphics > > Stephen Nolan wrote: > > > > Hi IBIS folks. I'm working on our procedures for creating IBIS models of devices > > with Bus Hold, and struggling through this section 6a on Submodels. Help. > > > > First of all, are submodels a section that is entirely contained within a model > > section, or are they independant and inheritable by other models? For example, > > if I have an input model: > > > > |****************************************************************************** > > [Model] LVTH244_DATAIN_33 > > Model_type Input > > Vinl = 0.8V > > Vinh = 2.0V > > C_comp 3.35pF NA NA > > | > > [Add Submodel] > > BUS_HOLD_33 Non-Driving > > | > > |****************************************************************************** > > > > Does the submodel BUS_HOLD_33 have to follow the data in the LVTH244_DATAIN_33 > > model and be within that model, or can all of the submodels be at the end of a > > file in a separate section following the models? > > It can be in a separate section. > > > > > Further, once I have declared a "[Submodel] BUS_HOLD_33" submodel within the > > LVTH244_DATA_IN_33 model, do I have to include the complete submodel again > > within the LVTH244_OE_IN_33 model, or can I just simply call it and expect the > > simulator to use it. If submodels do in fact turn out to be local instead of > > global and inheritable, is there any namespace conflict? > > They are global, so there is no namespace conflict. > > > > > Next is the question of data extraction for bus-hold. The clamp curves in the > > main model contain all of the data on the VI characteristics of the bus > > hold-circuitry. See the attached pdf file for an example. What is the purpose of > > the trigger and pullup/down data in the submodel section? What information does > > it provide that is not already available in the clamp curves of the main model? > > How do you extract the Ramp data (test setup). > > The clamp information is in addition to the bus hold operation. The clamp > tables should have 0 current in the normal operating regions (between 0 and > Vcc). > The Bus Hold circuitry which are really weak, triggered flip-flops are what > the submodel models. The advantage of the submodel approach is that the > dynamic effects of the Bus Hold circuit are simulated. The clamp approach > would capture only a static (DC) characteristic and assume instantenous > Bus Hold Operation. > > The Bus_hold operation can also be used for dynamic terminations. That is > the main motivation for adding this to IBIS. > > > > > Finally, in the spec there is the following sentence: > > > | The [Pullup] and [Pulldown] tables both are used to define an internal > > > | buffer that is triggered switch to its opposite state. > > What does this mean and is this sentence grammatically correct? I can't figure > > it out. > > It should read: > | The [Pullup] and [Pulldown] tables both are used to define an internal > | buffer that is triggered "to" switch to its opposite state. > > > > > Thanks. > > -- > > Regards, > > Stephen M. Nolan > > > > -------------------------------------------------------------------------------- > > Name: busholdcurves.pdf > > busholdcurves.pdf Type: Portable Document Format (application/pdf) > > Encoding: base64 From owner-ibis Fri Jul 21 00:16:36 2000 Received: from oliver.al.dynip.com (root@209-63-189-24.sea.jps.net [209.63.189.24]) by server.eda.org (8.8.5/8.8.3) with ESMTP id AAA25220 for ; Fri, 21 Jul 2000 00:16:32 -0700 (PDT) Received: from localhost (localhost [[UNIX: localhost]]) by oliver.al.dynip.com (8.9.3/8.9.3) id AAA08519 for ibis-users@eda.org; Fri, 21 Jul 2000 00:13:08 -0700 From: Al Davis To: Subject: Re: Ver. 3.2 and Ver. 2.1 Models Date: Thu, 20 Jul 2000 21:04:41 -0700 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain References: <0056910006140733000002L132*@MHS> <39778A0E.9C09D7BE@mentor.com> <00a101bff2a4$aa461060$9594a8c0@hyperlynx.com> In-Reply-To: <00a101bff2a4$aa461060$9594a8c0@hyperlynx.com> MIME-Version: 1.0 Message-Id: <00072021101602.07913@oliver.al.dynip.com> Content-Transfer-Encoding: 8bit Bob Ross wrote: > > I would use and supply Version 3.2 models only when Version 3.2 features > > are needed to accurately describe the part. Otherwise, I would still > > supply Version 2.1 models. On Thu, 20 Jul 2000, Matthew Flora wrote: > I concur with Bob Ross, except I would suggest still setting the IBIS_ver > keyword to 3.2. If nothing else, that will cause IBISCHK3 to use it's most > strict syntax/semantic tests. I suggest setting the IBIS_ver keyword to 2.1 if it is really a 2.1 model. If nothing else, it lets the reader know that it will work on older simulators that only support 2.1. In any case, don't forget to test it. e actually uses the "treat the drain as the source" equivalent. question lies the answer to whether the non-monotonicity matters separately. If you accept that only the sum matters, you are accepting that they cannot be considered separately, or the latter in the above paragraph. Then, why does the documentation show them as separate elements? Why are the names what they are? (which hints toward the two element meaning) Making this assumption means you lose the distinction between the where the other ends connect. Now, what does it mean when the "power clamp reference" and "pullup reference" are different? (another hint toward the two element meaning) > OTOH, I doubt it hurts to smooth out (not LEAVE out!) those points, as long > as they really are "noise" and insignificant compared to the stronger clamp > current. Supplying too many points actually reduces accuracy. For the V/I curves, the derivative is actually more important than the data provided. Consider the following table: 1 2.995 2 2.995 3 2.995 4 2.996 5 2.996 6 2.996 7 2.997 8 2.997 ... you get the idea. This is common toward the ends of a table. What it says is that it acts like a constant current source from 1-3 volts, from 4-6 volts, etc. and has jumps between 3 and 4, and between 6 and 7. Most likely, the real device is nearly flat, but the whole region has a finite slope. It would be better to just give 2 points. From owner-ibis Fri Jul 21 08:45:27 2000 Received: from mailgate.Cadence.COM (mailgate.Cadence.COM [158.140.2.1]) by server.eda.org (8.8.5/8.8.3) with ESMTP id IAA26948 for ; Fri, 21 Jul 2000 08:45:26 -0700 (PDT) Received: from zip.Cadence.COM (zip.Cadence.COM [158.140.103.36]) by mailgate.Cadence.COM (8.9.3/8.9.3) with ESMTP id IAA07409 for ; Fri, 21 Jul 2000 08:41:44 -0700 (PDT) Received: from cadence.com (zip [158.140.103.36]) by zip.Cadence.COM (8.9.3/8.8.5) with ESMTP id LAA26449; Fri, 21 Jul 2000 11:41:43 -0400 (EDT) Sender: mrl@cadence.com Message-ID: <39786F37.CCD0A48D@cadence.com> Date: Fri, 21 Jul 2000 11:41:43 -0400 From: Mike LaBonte Organization: Cadence Design Systems X-Mailer: Mozilla 4.51 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ibis-users@eda.org Subject: Re: Ver. 3.2 and Ver. 2.1 Models References: <0056910006140733000002L132*@MHS> <39778A0E.9C09D7BE@mentor.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Received: By mailgate.Cadence.COM as IAA07409 at Fri Jul 21 08:41:44 2000 Periodically I hear that IC vendors feel pressured by users to provide IBIS 3.2 models. I concur with Bob's point, and would like to suggest that it is primarily up the IC vendor to make this determination on a part-by-part basis. If a part can be modeled with reasonable accuracy using only IBIS 2.1 features, then there may be no reason to utilize IBIS 3.2 features. So when customers ask for 3.2 models, it would be best to ask why. Hopefully the reason is not "because it is the latest IBIS". Mike LaBonte Cadence Design Systems Bob Ross wrote: > > Mike: > > I would use and supply Version 3.2 models only when Version 3.2 features > are needed to accurately describe the part. Otherwise, I would still > supply Version 2.1 models. > > Bob Ross > Mentor Graphics > > mike.magdaluyo@philips.com wrote: > > > > To Model Users and EDA Vendors: > > > > Philips Semiconductors offers numerous standard logic Ver. 2.1 IBIS models. We are planning to start generating Ver. 3.2 models but would like your feedback on an issue. We are trying assess how many people have capability to run Ver 3.2 models and who > > can use only Ver 2.1 models. Due to the number of logic families and products we have, we want to avoid maintaining 2 sets of libraries per product family for both versions, but we need to see that our customers' needs are met too. Your comments would > > be greatly appreciated. > > > > Mike Magdaluyo > > > > Logic Products Group > > Philips Semiconductors > > (408) 991-2642 From owner-ibis Fri Jul 21 09:24:37 2000 Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by server.eda.org (8.8.5/8.8.3) with ESMTP id JAA27049 for ; Fri, 21 Jul 2000 09:24:37 -0700 (PDT) Received: by zmamail04.zma.compaq.com (Postfix, from userid 12345) id 17A228F7; Fri, 21 Jul 2000 12:21:46 -0400 (EDT) Received: from exctay-gh02.tay.cpqcorp.net (exctay-gh02.tay.cpqcorp.net [16.103.129.52]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 1227C910 for ; Fri, 21 Jul 2000 12:21:46 -0400 (EDT) Received: by exctay-gh02.tay.cpqcorp.net with Internet Mail Service (5.5.2650.21) id ; Fri, 21 Jul 2000 12:21:45 -0400 Message-ID: <212CC57E84B8D111AD780000F84AA049094840DE@mroexc2.tay.dec.com> From: "Ingraham, Andrew" To: ibis-users@eda.org Subject: RE: Subtracting clamp curves from pull-up/down curves Date: Fri, 21 Jul 2000 12:21:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Yesterday, I wrote: >OTOH, I doubt it hurts to smooth out (not LEAVE out!) those points, as long >as they really are "noise" and insignificant compared to the stronger clamp >current. This was poorly worded. What I meant to say, was that it is better to smooth the points (for example by eliminating intermediate, noisy points), rather than TRUNCATING them. Don't throw all of them away; keep at least the one on the end so that the simulator isn't left having to extrapolate (the results of which are simulator-dependent). Andy From owner-ibis Fri Jul 21 10:52:47 2000 Received: from ptldpop3.ptld.uswest.net (ptldpop3.ptld.uswest.net [198.36.160.3]) by server.eda.org (8.8.5/8.8.3) with SMTP id KAA27328 for ; Fri, 21 Jul 2000 10:52:46 -0700 (PDT) Received: (qmail 69682 invoked by alias); 21 Jul 2000 17:50:26 -0000 Delivered-To: fixup-ibis-users@eda.org@fixme Received: (qmail 69670 invoked by uid 0); 21 Jul 2000 17:50:26 -0000 Received: from unknown (HELO vasthorizons.com) (63.225.95.5) by ptldpop3.ptld.uswest.net with SMTP; 21 Jul 2000 17:50:26 -0000 Message-ID: <39788D63.278C094B@vasthorizons.com> Date: Fri, 21 Jul 2000 10:50:27 -0700 From: Scott McMorrow Organization: SiQual X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike LaBonte CC: ibis-users@eda.org Subject: Re: Ver. 3.2 and Ver. 2.1 Models References: <0056910006140733000002L132*@MHS> <39778A0E.9C09D7BE@mentor.com> <39786F37.CCD0A48D@cadence.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit We at SiQual provide IBIS version 3.2 models which include only version 2.1 features quite often. There are two reasons for this: 1) This causes ibischk3 to perform it's highest level of syntax checking. 2) Because it is our only leverage to encouraging CAD vendors to update their simulators to support 3.2 features. Recently, however, almost all of the models which we have developed use IBIS 3.2 features. Model Spec, Dynamic Clamps and Model Selector come to mind. Quite honestly, it is frustrating to us to find that only one simulator vendor can consistently support these advanced features in version 3.2. As a result, I have no problem in encouraging all vendors to provide version 3.2 models. Anything we can do on the model creation end to speed the adoption of 3.2 syntax in simulators is goodness for the industry. BTW, SiQual is also providing IBIS models which have been correlated to the original Spice decks and include the IBIS Accuracy Trailer as documentation. I would strongly encourage all model creators to do the same. best regards, scott -- Scott McMorrow Principal Engineer SiQual, Signal Quality Engineering 18735 SW Boones Ferry Road Tualatin, OR 97062-3090 (503) 885-1231 http://www.siqual.com Mike LaBonte wrote: > Periodically I hear that IC vendors feel pressured by users to provide IBIS 3.2 models. > I concur with Bob's point, and would like to suggest that it is primarily up the IC vendor > to make this determination on a part-by-part basis. If a part can be modeled with reasonable > accuracy using only IBIS 2.1 features, then there may be no reason to utilize IBIS 3.2 > features. So when customers ask for 3.2 models, it would be best to ask why. Hopefully > the reason is not "because it is the latest IBIS". > > Mike LaBonte > Cadence Design Systems > > Bob Ross wrote: > > > > Mike: > > > > I would use and supply Version 3.2 models only when Version 3.2 features > > are needed to accurately describe the part. Otherwise, I would still > > supply Version 2.1 models. > > > > Bob Ross > > Mentor Graphics > > > > mike.magdaluyo@philips.com wrote: > > > > > > To Model Users and EDA Vendors: > > > > > > Philips Semiconductors offers numerous standard logic Ver. 2.1 IBIS models. We are planning to start generating Ver. 3.2 models but would like your feedback on an issue. We are trying assess how many people have capability to run Ver 3.2 models and who > > > can use only Ver 2.1 models. Due to the number of logic families and products we have, we want to avoid maintaining 2 sets of libraries per product family for both versions, but we need to see that our customers' needs are met too. Your comments would > > > be greatly appreciated. > > > > > > Mike Magdaluyo > > > > > > Logic Products Group > > > Philips Semiconductors > > > (408) 991-2642 From owner-ibis Fri Jul 21 12:10:23 2000 Received: from ptldpop2.ptld.uswest.net (ptldpop2.ptld.uswest.net [198.36.160.2]) by server.eda.org (8.8.5/8.8.3) with SMTP id MAA27842 for ; Fri, 21 Jul 2000 12:10:23 -0700 (PDT) Received: (qmail 25099 invoked by alias); 21 Jul 2000 19:07:59 -0000 Delivered-To: fixup-ibis-users@eda.org@fixme Received: (qmail 25074 invoked by uid 0); 21 Jul 2000 19:07:58 -0000 Received: from unknown (HELO vasthorizons.com) (63.225.95.5) by ptldpop2.ptld.uswest.net with SMTP; 21 Jul 2000 19:07:58 -0000 Message-ID: <39789F90.828DB24D@vasthorizons.com> Date: Fri, 21 Jul 2000 12:08:00 -0700 From: Scott McMorrow Organization: SiQual X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Nolan , ibis-users@eda.org Subject: Re: Ver. 3.2 and Ver. 2.1 Models References: <0056910006140733000002L132*@MHS> <39778A0E.9C09D7BE@mentor.com> <39786F37.CCD0A48D@cadence.com> <39788D63.278C094B@vasthorizons.com> <39789C30.B347F04A@ti.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Stephen, Stephen Nolan wrote: >What is "the IBIS Accuracy Trailer"? Here is the directory for it on the IBIS website. http://www.vhdl.org/pub/ibis/accuracy/ The Trailer is a bunch of comment lines at the end of a model which are intended to document the correlation of an IBIS model to actual measurements. It was developed by a number of IBIS users, along with the accuracy spec and handbook, because of their frustration with poor model quality. We use the correlation metric which is defined by the specification to compare IBIS simulations with SPICE simulations and document these in the models we produce with the Accuracy Trailer. In our case, the standard test circuit we use is a driver driving a 50 ohm microstrip transmission line which is 8 inches long into a 5pF capacitive load. This gives us loads of information on the quality of IBIS simulations into a fairly complex reflected wave environment. Typically our correlations are within 98 to 99% of the original Spice waveform, according to the metric. We now deliver all models with correlation data to the orignal source. Additionally, we provide reports with pictures of the comparision waveforms to our end customers, which are usually semiconductor manufacturers. best regards, scott Scott McMorrow Principal Engineer SiQual, Signal Quality Engineering 18735 SW Boones Ferry Road Tualatin, OR 97062-3090 (503) 885-1231 http://www.siqual.com From owner-ibis Fri Jul 21 12:32:23 2000 Received: from gatekeep.ti.com (gatekeep.ti.com [192.94.94.61]) by server.eda.org (8.8.5/8.8.3) with ESMTP id MAA27904 for ; Fri, 21 Jul 2000 12:32:22 -0700 (PDT) Received: from dlep8.itg.ti.com ([157.170.134.88]) by gatekeep.ti.com (8.10.2/8.10.1) with ESMTP id e6LJTWH10950; Fri, 21 Jul 2000 14:29:32 -0500 (CDT) Received: from dlep8.itg.ti.com (localhost [127.0.0.1]) by dlep8.itg.ti.com (8.9.3/8.9.3) with ESMTP id OAA22006; Fri, 21 Jul 2000 14:29:09 -0500 (CDT) Received: from dlep4.itg.ti.com (dlep4.itg.ti.com [157.170.188.63]) by dlep8.itg.ti.com (8.9.3/8.9.3) with ESMTP id OAA21992; Fri, 21 Jul 2000 14:29:08 -0500 (CDT) Received: from ti.com (lta0460542.sh.sc.ti.com [158.218.201.142]) by dlep4.itg.ti.com (8.9.3/8.9.3) with ESMTP id OAA11769; Fri, 21 Jul 2000 14:29:31 -0500 (CDT) Message-ID: <3978A49E.26A9B4B7@ti.com> Date: Fri, 21 Jul 2000 14:29:34 -0500 From: Stephen Nolan Organization: Texas Instruments Incorporated X-Sender: "Stephen Nolan" <@dshmail.itg.ti.com> (Unverified) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en,ja,ko MIME-Version: 1.0 To: Scott McMorrow CC: ibis-users@eda.org Subject: Re: Ver. 3.2 and Ver. 2.1 Models References: <0056910006140733000002L132*@MHS> <39778A0E.9C09D7BE@mentor.com> <39786F37.CCD0A48D@cadence.com> <39788D63.278C094B@vasthorizons.com> <39789C30.B347F04A@ti.com> <39789F90.828DB24D@vasthorizons.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks, Scott. More questions: It looks like the IBIS Accuracy Handbook simply advises that the user determine the transmission-line parameters of the standard test board by doing lab-tests (TDR measurements). I'm curious if anyone has done so and would be willing to share those numbers. And/or has anyone used a 2D field solver on the board design file to get the RLGC parameters for the "50 ohm microstrip transmission line which is 8 inches long". Thanks. -- Regards, Stephen M. Nolan Scott McMorrow wrote: > > Stephen, > > Stephen Nolan wrote: > >What is "the IBIS Accuracy Trailer"? > > Here is the directory for it on the IBIS website. > > http://www.vhdl.org/pub/ibis/accuracy/ > > The Trailer is a bunch of comment lines at the end of > a model which are intended to document the correlation > of an IBIS model to actual measurements. It was developed > by a number of IBIS users, along with the accuracy spec and > handbook, because of their frustration with poor model > quality. > > We use the correlation metric which is defined by the > specification to compare IBIS simulations with SPICE > simulations and document these in the models we produce > with the Accuracy Trailer. > > In our case, the standard test circuit we use is a driver > driving a 50 ohm microstrip transmission line which > is 8 inches long into a 5pF capacitive load. This gives > us loads of information on the quality of IBIS simulations > into a fairly complex reflected wave environment. Typically > our correlations are within 98 to 99% of the original > Spice waveform, according to the metric. > > We now deliver all models with correlation data to the > orignal source. Additionally, we provide reports with > pictures of the comparision waveforms to our end customers, > which are usually semiconductor manufacturers. > > best regards, > > scott > > Scott McMorrow > Principal Engineer > SiQual, Signal Quality Engineering > 18735 SW Boones Ferry Road > Tualatin, OR 97062-3090 > (503) 885-1231 > http://www.siqual.com From owner-ibis Fri Jul 21 13:35:16 2000 Received: from ptldpop5.ptld.uswest.net ([198.36.160.5]) by server.eda.org (8.8.5/8.8.3) with SMTP id NAA27997 for ; Fri, 21 Jul 2000 13:35:15 -0700 (PDT) Received: (qmail 97282 invoked by alias); 21 Jul 2000 20:32:55 -0000 Delivered-To: fixup-ibis-users@eda.org@fixme Received: (qmail 97272 invoked by uid 0); 21 Jul 2000 20:32:55 -0000 Received: from unknown (HELO vasthorizons.com) (63.225.95.5) by 198.36.160.5 with SMTP; 21 Jul 2000 20:32:55 -0000 Message-ID: <3978B378.5DFB742@vasthorizons.com> Date: Fri, 21 Jul 2000 13:32:56 -0700 From: Scott McMorrow Organization: SiQual X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Nolan CC: ibis-users@eda.org Subject: Re: Ver. 3.2 and Ver. 2.1 Models References: <0056910006140733000002L132*@MHS> <39778A0E.9C09D7BE@mentor.com> <39786F37.CCD0A48D@cadence.com> <39788D63.278C094B@vasthorizons.com> <39789C30.B347F04A@ti.com> <39789F90.828DB24D@vasthorizons.com> <3978A49E.26A9B4B7@ti.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Stephen, We have done some real system correlation work which we are not at liberty to share. However, when we do, we perform TDR measurements of board parameters and use this to calibrate both our field solver results and in-circuit measurements of driver strength and edge-rate. We then crank these into our modeling efforts. Our results have been very good with up to 1.5 Gbit/second data streams. In most cases, however, we have neither the time, nor the allocated funds to perform such a rigorous correlation. Instead we make the assumption that our customers are supplying validated Spice models, which we use in further extraction and correlation work. In many cases we work with semiconductor vendors who do correlate their Spice decks to real silicon. Thus, an IBIS correlation to Spice is quite valid. The intent of the accuracy spec is that IBIS models be correlated to actually measurement. In reality, this is not always possible. We think that correlation to the Spice is the second best alternative in most cases. regards, scott Stephen Nolan wrote: > Thanks, Scott. > > More questions: > It looks like the IBIS Accuracy Handbook simply advises that the user determine > the transmission-line parameters of the standard test board by doing lab-tests > (TDR measurements). I'm curious if anyone has done so and would be willing to > share those numbers. And/or has anyone used a 2D field solver on the board > design file to get the RLGC parameters for the "50 ohm microstrip transmission > line which is 8 inches long". > > Thanks. > -- > Regards, > Stephen M. Nolan > > Scott McMorrow wrote: > > > > Stephen, > > > > Stephen Nolan wrote: > > >What is "the IBIS Accuracy Trailer"? > > > > Here is the directory for it on the IBIS website. > > > > http://www.vhdl.org/pub/ibis/accuracy/ > > > > The Trailer is a bunch of comment lines at the end of > > a model which are intended to document the correlation > > of an IBIS model to actual measurements. It was developed > > by a number of IBIS users, along with the accuracy spec and > > handbook, because of their frustration with poor model > > quality. > > > > We use the correlation metric which is defined by the > > specification to compare IBIS simulations with SPICE > > simulations and document these in the models we produce > > with the Accuracy Trailer. > > > > In our case, the standard test circuit we use is a driver > > driving a 50 ohm microstrip transmission line which > > is 8 inches long into a 5pF capacitive load. This gives > > us loads of information on the quality of IBIS simulations > > into a fairly complex reflected wave environment. Typically > > our correlations are within 98 to 99% of the original > > Spice waveform, according to the metric. > > > > We now deliver all models with correlation data to the > > orignal source. Additionally, we provide reports with > > pictures of the comparision waveforms to our end customers, > > which are usually semiconductor manufacturers. > > > > best regards, > > > > scott > > > > Scott McMorrow > > Principal Engineer > > SiQual, Signal Quality Engineering > > 18735 SW Boones Ferry Road > > Tualatin, OR 97062-3090 > > (503) 885-1231 > > http://www.siqual.com -- Scott McMorrow Principal Engineer SiQual, Signal Quality Engineering 18735 SW Boones Ferry Road Tualatin, OR 97062-3090 (503) 885-1231 http://www.siqual.com From owner-ibis Fri Jul 21 14:30:20 2000 Received: from mailgate.Cadence.COM (mailgate.Cadence.COM [158.140.2.1]) by server.eda.org (8.8.5/8.8.3) with ESMTP id OAA28247 for ; Fri, 21 Jul 2000 14:30:19 -0700 (PDT) Received: from zip.Cadence.COM (zip.Cadence.COM [158.140.103.36]) by mailgate.Cadence.COM (8.9.3/8.9.3) with ESMTP id OAA15368 for ; Fri, 21 Jul 2000 14:27:59 -0700 (PDT) Received: from cadence.com (zip [158.140.103.36]) by zip.Cadence.COM (8.9.3/8.8.5) with ESMTP id RAA04908; Fri, 21 Jul 2000 17:27:58 -0400 (EDT) Sender: mrl@cadence.com Message-ID: <3978C05E.F6655ABA@cadence.com> Date: Fri, 21 Jul 2000 17:27:58 -0400 From: Mike LaBonte Organization: Cadence Design Systems X-Mailer: Mozilla 4.51 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: IBIS-users@eda.org Subject: IBIS Models page update Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Received: By mailgate.Cadence.COM as OAA15368 at Fri Jul 21 14:27:59 2000 The IBIS Models web page at http://www.eigroup.org/ibis/models.htm has been updated. There is much more to be done on this page, but at least it has fewer dead links now. My thanks to Jon Powell for all the time that I now realize he has put into it over the years. Any suggestions for corrections, additions, or enhancements to this web page are welcome. Please send them to me (as IBIS Librarian). Mike LaBonte Cadence Design Systems From owner-ibis Fri Jul 21 17:15:02 2000 Received: from gw-nl4.philips.com (gw-nl4.philips.com [192.68.44.36]) by server.eda.org (8.8.5/8.8.3) with ESMTP id RAA28625 for ; Fri, 21 Jul 2000 17:15:01 -0700 (PDT) From: mike.magdaluyo@philips.com Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id CAA20383; Sat, 22 Jul 2000 02:11:48 +0200 (MEST) (envelope-from mike.magdaluyo@philips.com) Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com via mwrap (4.0a) id xma020381; Sat, 22 Jul 00 02:11:48 +0200 Received: from AMLMS01.DIAMOND.PHILIPS.COM (amlms01sv1.diamond.philips.com [161.88.79.213]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id CAA00569; Sat, 22 Jul 2000 02:11:47 +0200 (MET DST) Received: by AMLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via AMEC id 0056910006166664; Fri, 21 Jul 2000 19:09:56 -0500 To: Cc: Subject: Re: Ver. 3.2 and Ver. 2.1 Models Message-ID: <0056910006166664000002L142*@MHS> Date: Fri, 21 Jul 2000 19:09:56 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 07/21/00 19:11:36" Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by server.eda.org id RAA28626 To Mike, Bob, and all, Thanks for your advise on this issue. We will determine which families will benefit from the enhanced features of IBIS 3.2. Looks like our newer families with staged outputs, dynamic output impedance, output feedback, etc., will be modeled more accurately using Ver. 3.2. Regards, Mike Magdaluyo Logic Products Group Philips Semiconductors (408) 991-2642 mikelabonte@cadence.com@SMTP@cadence.com on 07/21/2000 09:45:58 AM Sent by: mrl@cadence.com To: ibis-users@eda.org@SMTP cc: Subject: Re: Ver. 3.2 and Ver. 2.1 Models Classification: Restricted Periodically I hear that IC vendors feel pressured by users to provide IBIS 3.2 models. I concur with Bob's point, and would like to suggest that it is primarily up the IC vendor to make this determination on a part-by-part basis. If a part can be modeled with reasonable accuracy using only IBIS 2.1 features, then there may be no reason to utilize IBIS 3.2 features. So when customers ask for 3.2 models, it would be best to ask why. Hopefully the reason is not "because it is the latest IBIS". Mike LaBonte Cadence Design Systems Bob Ross wrote: > > Mike: > > I would use and supply Version 3.2 models only when Version 3.2 features > are needed to accurately describe the part. Otherwise, I would still > supply Version 2.1 models. > > Bob Ross > Mentor Graphics > > mike.magdaluyo@philips.com wrote: > > > > To Model Users and EDA Vendors: > > > > Philips Semiconductors offers numerous standard logic Ver. 2.1 IBIS models. We are planning to start generating Ver. 3.2 models but would like your feedback on an issue. We are trying assess how many people have capability to run Ver 3.2 models and who > > can use only Ver 2.1 models. Due to the number of logic families and products we have, we want to avoid maintaining 2 sets of libraries per product family for both versions, but we need to see that our customers' needs are met too. Your comments would > > be greatly appreciated. > > > > Mike Magdaluyo > > > > Logic Products Group > > Philips Semiconductors > > (408) 991-2642 From owner-ibis Mon Jul 24 19:42:02 2000 Received: from mud.ssec.honeywell.com (mud.ssec.honeywell.com [129.30.62.69]) by server.eda.org (8.8.5/8.8.3) with ESMTP id TAA07631 for ; Mon, 24 Jul 2000 19:42:02 -0700 (PDT) Received: from ssec.honeywell.com (localhost [127.0.0.1]) by mud.ssec.honeywell.com with ESMTP (8.9.3 (PHNE_18979)/8.7.1) id VAA22587 for ; Mon, 24 Jul 2000 21:39:09 -0500 (CDT) Sender: brand@ssec.honeywell.com Message-ID: <397CFDCC.8A65B3DC@ssec.honeywell.com> Date: Mon, 24 Jul 2000 21:39:09 -0500 From: Dave Brand X-Mailer: Mozilla 4.7 [en] (X11; I; HP-UX B.10.20 9000/782) X-Accept-Language: en MIME-Version: 1.0 To: ibis-users@eda.org Subject: 5 volt tolerant I/O Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello all, I am trying to run a tristate output driver that will drive into ttl inputs on 5v IC's but can tolerate a 0v to 5v output swing if it's output is pulled there. I did try using voltage range, but didn't think that would work since I wasn't sure how to get -5 to +10 for the clamps, so I tried the pin mapping variable. I can't seem to get the pin mapping syntax to work that allows me to pull the output from -5 to +10 for power clamp and ground clamp, while maintaining the internal circuitry tied to 3.3v. I do NOT have a pin tied to 5v going to my driver. When I go to pin mapping, I also lose my supply to vcc and gnd in the netlists. Maybe someone could send me email as to what else to try. Thanks in advance, Dave Brand Reply to dave.brand@honeywell.com The input file below results in: s2ibis2 v1.1 -- North Carolina State University s2ibis2: Reading input file temp...done. s2ibis2: Analyzing component TRI512_HX3000 . s2ibis2: No POWER or GND pin associated with bus POWER_CLAMP. The bus has been specified as a power or ground bus in the [Pin Mapping] section of your input file, but it is not connected to a pin with model name POWER or GND. Here is what I tried: [pullup reference] 3.3 2.97 3.63 [pulldown reference] 0 0 0 [power clamp reference] 5 4.5 5.5 [gnd clamp reference] 0 0 0 [Pin Mapping] 1 NC NC GND_CLAMP POWER_CLAMP 2 NC DRV_VDD 3 DRV_GND NC 4 DRV_GND DRV_VDD 5 DRV_GND DRV_VDD [Pin] 1 20 PAD TRI512 -> 4 5 2 1 VCC POWER 3 0 GND GND 4 10 IN Input1 0 0 0 5 30 EN Enable1 0 0 0 [Model] TRI512 [Model type] 3-State [Polarity] Non-Inverting [Enable] Active-Low [Model File] sm.soi5.nom sm.soi5.wc sm.soi5.bc [sim time] 10.5n [Rising waveform] 50 0 NA NA NA NA NA NA NA [Rising waveform] 50 5 NA NA NA NA NA NA NA [Falling waveform] 50 5 NA NA NA NA NA NA NA [Falling waveform] 50 0 NA NA NA NA NA NA NA [C_comp] 7.26pF 7.39pF 7.26pF [Tr] .7ns 1ns .5ns [Tf] .7ns 1ns .5ns [Vmeas] 1.65V [Model] Input1 [Model type] Input [Polarity] Non-Inverting [Model File] sm.soi5.nom sm.soi5.wc sm.soi5.bc [Vinl] 0.0 [Vinh] 3.3 [Model] Enable1 [Model type] Input [Polarity] Inverting [Model File] sm.soi5.nom sm.soi5.wc sm.soi5.bc [Vinl] 0.0 [Vinh] 3.3 From owner-ibis Mon Jul 31 07:03:18 2000 Received: from tower.ti.com (tower.ti.com [192.94.94.5]) by server.eda.org (8.8.5/8.8.3) with ESMTP id HAA07659 for ; Mon, 31 Jul 2000 07:03:18 -0700 (PDT) Received: from dlep7.itg.ti.com ([157.170.134.103]) by tower.ti.com (8.10.2/8.10.1) with ESMTP id e6VE0In25884 for ; Mon, 31 Jul 2000 09:00:22 -0500 (CDT) Received: from dlep7.itg.ti.com (localhost [127.0.0.1]) by dlep7.itg.ti.com (8.9.3/8.9.3) with ESMTP id JAA23477 for ; Mon, 31 Jul 2000 09:00:10 -0500 (CDT) Received: from dlep4.itg.ti.com (dlep4.itg.ti.com [157.170.188.63]) by dlep7.itg.ti.com (8.9.3/8.9.3) with ESMTP id JAA23461 for ; Mon, 31 Jul 2000 09:00:10 -0500 (CDT) Received: from ti.com (lta0460542.sh.sc.ti.com [158.218.201.142]) by dlep4.itg.ti.com (8.9.3/8.9.3) with ESMTP id JAA15792 for ; Mon, 31 Jul 2000 09:00:17 -0500 (CDT) Message-ID: <398246BE.39DEAD26@ti.com> Date: Fri, 28 Jul 2000 21:51:42 -0500 From: Stephen Nolan Organization: Texas Instruments Incorporated X-Sender: "Stephen Nolan" <@dshmail.itg.ti.com> (Unverified) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en,ja,ko MIME-Version: 1.0 To: ibis-users@eda.org Subject: IBIS standard inconsistency Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In the IBIS standard, the keywords [IBIS Ver] and [File Rev] appear to the the only keywords that have capitalized words other than the first word (the word IBIS being completely capitalized accepted as an acronym). All other keyword have the first word capitalized followed by the other words lower case. Eg. [Comment char], [File name], [Voltage range].... Why is there an inconsistency in the style of these keywords? Also, some multiple-word keywords use an underscore between words instead of a space. Eg. [GND_clamp], [POWER_clamp]. Again, why the inconsistency? -- Regards, Stephen M. Nolan From owner-ibis Mon Jul 31 07:40:55 2000 Received: from mailgate.Cadence.COM (mailgate.Cadence.COM [158.140.2.1]) by server.eda.org (8.8.5/8.8.3) with ESMTP id HAA07843 for ; Mon, 31 Jul 2000 07:40:55 -0700 (PDT) Received: from gda.Cadence.COM (gda.Cadence.COM [158.140.106.10]) by mailgate.Cadence.COM (8.9.3/8.9.3) with ESMTP id HAA18552; Mon, 31 Jul 2000 07:38:29 -0700 (PDT) Received: from cadence.com (d158140105215 [158.140.105.215]) by gda.Cadence.COM (8.8.8/8.8.5) with ESMTP id KAA21519; Mon, 31 Jul 2000 10:38:28 -0400 (EDT) Message-ID: <39858F3D.9F3EA549@cadence.com> Date: Mon, 31 Jul 2000 10:37:49 -0400 From: Ian Dodd Organization: Cadence Design Systems, Inc. X-Mailer: Mozilla 4.7 [en]C-CCK-MCD (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Nolan CC: ibis-users@eda.org Subject: Re: IBIS standard inconsistency References: <398246BE.39DEAD26@ti.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Received: By mailgate.Cadence.COM as HAA18552 at Mon Jul 31 07:38:29 2000 Stephen, My reading of the spec suggests you are free to use any of these styles..... | 1) The content of the files is case sensitive, except for reserved | words and keywords. | 6) Keywords must be enclosed in square brackets, [], and must start in | column 1 of the line. No space or tab is allowed immediately after the | opening bracket '[' or immediately before the closing bracket ']'. If | used, only one space (' ') or underscore ('_') character separates the | parts of a multi-word keyword. Have you experimented with the golden parser to see what it will accept? Ian Dodd Cadence Design Systems idodd@cadence.com Stephen Nolan wrote: > > In the IBIS standard, the keywords [IBIS Ver] and [File Rev] appear to the the > only keywords that have capitalized words other than the first word (the word > IBIS being completely capitalized accepted as an acronym). All other keyword > have the first word capitalized followed by the other words lower case. Eg. > [Comment char], [File name], [Voltage range].... > > Why is there an inconsistency in the style of these keywords? > > Also, some multiple-word keywords use an underscore between words instead of a > space. Eg. [GND_clamp], [POWER_clamp]. > > Again, why the inconsistency? > -- > Regards, > Stephen M. Nolan From owner-ibis Mon Jul 31 07:48:19 2000 Received: from pop.nwlink.com (pop.nwlink.com [209.20.130.39]) by server.eda.org (8.8.5/8.8.3) with ESMTP id HAA07859 for ; Mon, 31 Jul 2000 07:48:19 -0700 (PDT) Received: from ip210.c246.blk1.bel.nwlink.com (ip210.c246.blk1.bel.nwlink.com [209.20.246.210]) by pop.nwlink.com (8.9.3/8.9.3) with SMTP id HAA10682; Mon, 31 Jul 2000 07:45:53 -0700 (PDT) Received: from mail.hyperlynx.com by ip210.c246.blk1.bel.nwlink.com via smtpd (for pop.nwlink.com [209.20.130.39]) with SMTP; 31 Jul 2000 14:45:28 UT Received: from hlgw.hyperlynx.com ([192.168.148.149]) by hazard.hyperlynx.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with SMTP id HAA22606; Mon, 31 Jul 2000 07:45:51 -0700 Message-ID: <000a01bffafe$19d74a00$9594a8c0@hyperlynx.com> From: "Matthew Flora" To: "Stephen Nolan" , Received: from SQUIDGE by hlgw.hyperlynx.com via smtpd (for mail.hyperlynx.com [192.168.149.2]) with SMTP; 31 Jul 2000 14:45:28 UT References: <398246BE.39DEAD26@ti.com> Subject: Re: IBIS standard inconsistency Date: Mon, 31 Jul 2000 07:46:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Dear Stephen M. Nolan, Section three of the specification does say: | 1) The content of the files is case sensitive, except for reserved | words and keywords. and: | 6) Keywords must be enclosed in square brackets, [], and must start in | column 1 of the line. No space or tab is allowed immediately after the | opening bracket '[' or immediately before the closing bracket ']'. If | used, only one space (' ') or underscore ('_') character separates the | parts of a multi-word keyword. So both forms you mentioned are legal. Why the text of the specification mixes the two is anyone's guess. Best regards, Matthew Flora ----- Original Message ----- From: "Stephen Nolan" To: Sent: Friday, July 28, 2000 7:51 PM Subject: IBIS standard inconsistency > In the IBIS standard, the keywords [IBIS Ver] and [File Rev] appear to the the > only keywords that have capitalized words other than the first word (the word > IBIS being completely capitalized accepted as an acronym). All other keyword > have the first word capitalized followed by the other words lower case. Eg. > [Comment char], [File name], [Voltage range].... > > Why is there an inconsistency in the style of these keywords? > > Also, some multiple-word keywords use an underscore between words instead of a > space. Eg. [GND_clamp], [POWER_clamp]. > > Again, why the inconsistency? > -- > Regards, > Stephen M. Nolan > From owner-ibis Mon Jul 31 08:24:14 2000 Received: from ausxc07.us.dell.com (ausxc07.us.dell.com [143.166.99.215]) by server.eda.org (8.8.5/8.8.3) with ESMTP id IAA07976 for ; Mon, 31 Jul 2000 08:24:13 -0700 (PDT) From: Aubrey_Sparkman@Dell.com Received: by ausxc07.us.dell.com with Internet Mail Service (5.5.2448.0) id ; Mon, 31 Jul 2000 10:21:16 -0500 Message-ID: <0340D4D07D98D311A60A00A0C92DCAF7017FB73D@ausxmbrh03.aus.amer.dell.com> To: mbflora@mail.hyperlynx.com, s-nolan1@ti.com Cc: ibis-users@eda.org Subject: RE: IBIS standard inconsistency Date: Mon, 31 Jul 2000 10:21:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BFFB02.F7CB9948" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BFFB02.F7CB9948 Content-Type: text/plain; charset="iso-8859-1" I'm sure there was some intent to give examples of allowed variation! :-) Aubrey Sparkman Signal Integrity Aubrey_Sparkman@Dell.com (512) 723-3592 > -----Original Message----- > From: Matthew Flora [mailto:mbflora@mail.hyperlynx.com] > Sent: Monday, July 31, 2000 9:46 AM > To: Stephen Nolan; ibis-users@eda.org > Subject: Re: IBIS standard inconsistency > > > Dear Stephen M. Nolan, > > Section three of the specification does say: > > | 1) The content of the files is case sensitive, except for reserved > | words and keywords. > > and: > > | 6) Keywords must be enclosed in square brackets, [], and > must start in > | column 1 of the line. No space or tab is allowed > immediately after the > | opening bracket '[' or immediately before the closing > bracket ']'. If > | used, only one space (' ') or underscore ('_') > character separates the > | parts of a multi-word keyword. > > So both forms you mentioned are legal. Why the text of the > specification > mixes the two is anyone's guess. > > Best regards, > Matthew Flora > > > ----- Original Message ----- > From: "Stephen Nolan" > To: > Sent: Friday, July 28, 2000 7:51 PM > Subject: IBIS standard inconsistency > > > > In the IBIS standard, the keywords [IBIS Ver] and [File > Rev] appear to the > the > > only keywords that have capitalized words other than the > first word (the > word > > IBIS being completely capitalized accepted as an acronym). > All other keyword > > have the first word capitalized followed by the other words > lower case. Eg. > > [Comment char], [File name], [Voltage range].... > > > > Why is there an inconsistency in the style of these keywords? > > > > Also, some multiple-word keywords use an underscore between > words instead of > a > > space. Eg. [GND_clamp], [POWER_clamp]. > > > > Again, why the inconsistency? > > -- > > Regards, > > Stephen M. Nolan > > > ------_=_NextPart_000_01BFFB02.F7CB9948 Content-Type: application/octet-stream; name="Sparkman, Aubrey.vcf" Content-Disposition: attachment; filename="Sparkman, Aubrey.vcf" BEGIN:VCARD VERSION:2.1 N:Sparkman;Aubrey FN:Sparkman, Aubrey EMAIL;PREF;INTERNET:Aubrey_Sparkman@Dell.com REV:19990728T212924Z END:VCARD ------_=_NextPart_000_01BFFB02.F7CB9948-- From owner-ibis Mon Jul 31 08:33:05 2000 Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by server.eda.org (8.8.5/8.8.3) with ESMTP id IAA08021 for ; Mon, 31 Jul 2000 08:33:04 -0700 (PDT) Received: from SMTP (fmsmsxvs04-1.fm.intel.com [132.233.42.204]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.30 2000/06/08 18:25:35 dmccart Exp $) with SMTP id PAA08449; Mon, 31 Jul 2000 15:31:34 GMT Received: from fmsmsx26.fm.intel.com ([132.233.48.26]) by 132.233.48.204 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 31 Jul 2000 15:30:37 0000 (GMT) Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2650.21) id <3X9RL9KM>; Mon, 31 Jul 2000 08:29:24 -0700 Message-ID: From: "Hobbs, Will" To: "'Aubrey_Sparkman@Dell.com'" , mbflora@mail.hyperlynx.com, s-nolan1@ti.com Cc: ibis-users@eda.org Subject: RE: IBIS standard inconsistency Date: Mon, 31 Jul 2000 08:29:16 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" My memory of this is a bit cloudy, but I do remember the 24-straight hour session we spent hammering out the final version of IBIS 1.1; it's quite possible that at 3:00 in the morning we missed it, and no one picked it up in subsequent reviews. Fortunately, it is inconsequential. Will -----Original Message----- From: Aubrey_Sparkman@Dell.com [mailto:Aubrey_Sparkman@Dell.com] Sent: Monday, July 31, 2000 8:21 AM To: mbflora@mail.hyperlynx.com; s-nolan1@ti.com Cc: ibis-users@eda.org Subject: RE: IBIS standard inconsistency I'm sure there was some intent to give examples of allowed variation! :-) Aubrey Sparkman Signal Integrity Aubrey_Sparkman@Dell.com (512) 723-3592 > -----Original Message----- > From: Matthew Flora [mailto:mbflora@mail.hyperlynx.com] > Sent: Monday, July 31, 2000 9:46 AM > To: Stephen Nolan; ibis-users@eda.org > Subject: Re: IBIS standard inconsistency > > > Dear Stephen M. Nolan, > > Section three of the specification does say: > > | 1) The content of the files is case sensitive, except for reserved > | words and keywords. > > and: > > | 6) Keywords must be enclosed in square brackets, [], and > must start in > | column 1 of the line. No space or tab is allowed > immediately after the > | opening bracket '[' or immediately before the closing > bracket ']'. If > | used, only one space (' ') or underscore ('_') > character separates the > | parts of a multi-word keyword. > > So both forms you mentioned are legal. Why the text of the > specification > mixes the two is anyone's guess. > > Best regards, > Matthew Flora > > > ----- Original Message ----- > From: "Stephen Nolan" > To: > Sent: Friday, July 28, 2000 7:51 PM > Subject: IBIS standard inconsistency > > > > In the IBIS standard, the keywords [IBIS Ver] and [File > Rev] appear to the > the > > only keywords that have capitalized words other than the > first word (the > word > > IBIS being completely capitalized accepted as an acronym). > All other keyword > > have the first word capitalized followed by the other words > lower case. Eg. > > [Comment char], [File name], [Voltage range].... > > > > Why is there an inconsistency in the style of these keywords? > > > > Also, some multiple-word keywords use an underscore between > words instead of > a > > space. Eg. [GND_clamp], [POWER_clamp]. > > > > Again, why the inconsistency? > > -- > > Regards, > > Stephen M. Nolan > > > From owner-ibis Mon Jul 31 10:27:55 2000 Received: from relay1.wv.mentorg.com (relay1.mentorg.com [192.94.38.42]) by server.eda.org (8.8.5/8.8.3) with ESMTP id KAA08536; Mon, 31 Jul 2000 10:27:54 -0700 (PDT) Received: from em-wv03.wv.mentorg.com by relay1.wv.mentorg.com (8.8.8/CF5.40F) id KAA22837; Mon, 31 Jul 2000 10:24:59 -0700 (PDT) Received: from mentor.com by em-wv03.wv.mentorg.com (8.8.8/CF5.40R) id KAA20782; Mon, 31 Jul 2000 10:24:57 -0700 (PDT) Sender: bob_ross@mentorg.com Message-ID: <3985B66A.532C3539@mentor.com> Date: Mon, 31 Jul 2000 10:24:58 -0700 From: Bob Ross X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ibis@eda.org, ibis-users@eda.org Subject: IBIS SUMMIT MEETING 9/14/00 FIRST ANNOUNCEMENT Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ------------------------------------------------------- IBIS SUMMIT FIRST CALL FOR PARTICIPATION, PRESENTATIONS & SPONSORSHIP!!!! ------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I B I S S U M M I T M E E T I N G Time/Date: 8:30 AM - 5:00 PM, Thursday, September 14, 2000 Location: The Crowne Plaza Hotel (NEW LOCATION) 10 Lincoln Square Worcester, MA Tel: (508) 791-1600 Fax: (508) 791-1796 Content: Presentations and Discussions Purpose: Solicit and Exchange IBIS Model Related Information and Ideas. Sponsors: North East Systems Associates, Inc. (NESA), Cadence Design Systems, HyperLynx, Mentor Graphics, IBIS Users Group Others to be determined WE ARE LOOKING FOR ADDITIONAL SPONSORS! (contact Kathy Breda, breda@nesa.com or Bob Ross, bob_ross@mentororg.com) PCB Conference: September 11-15, 2000 East Worcester's Centrum Centre Worcester, Massachusetts See http://www.pcbeast.com/ for more information. BACKGROUND The IBIS Users Group (IBIS East) has been formed under the leadership of Dr. Edward Sayre from North East Systems Associates, Inc. (NESA) and has been meeting to consider and forward IBIS model user concerns. As a result of East coast meetings, the group has developed an IBIS Accuracy Handbook document and has initiated the project to format Connector Models. These topics plus others of current interest to the EIA IBIS Open Forum will be discussed at this meeting. This meeting will be conducted as a formal IBIS Summit Meeting. Presentation are expected to be available and archived in an electronic format, and minutes of the meeting will be issued. Any pending formal decisions (votes) will be announced at least two weeks prior to the meeting. CALL FOR PARTICIPANTS People involved in IBIS Model development, EDA tool development, and digital circuit design are invited to participate to the Summit meeting. If you plan to participate, please register with the information below: Name: E-mail address: Company: Telephone: Send to: Kathy Breda (breda@nesa.com) CALL FOR PRESENTATIONS We are seeking presentations from individuals who have IBIS experiences or issues. Format of Presentation: Overhead Projections Time: 15-30 Minutes Electronic Archival: We request electronic versions so that the presentations can be archived and also made available to non-attendees. Formats used in the past have been text, Power Point, Word, Postscript, and Acrobat. Electronic presentations should be made available by September 8, 2000. Otherwise the presenter will be expected to provide 50 copies for distribution. If you plan a presentation, please supply Title: Presenter: E-mail address: Company: Telephone: Estimate Time: Send this to: Kathy Breda (breda@nesa.com) AGENDA The agenda includes presentations, discussions, breaks, and a luncheon (which will be provided). This will be developed as presentation proposals are received. So far the following presentatation is planned: Roy Leventhal, 3Com, - "IBIS and SI at 3Com" (Presented by Mike LaBonte, Cadence) LIST OF NEARBY HOTELS See http://www.pcbeast.com for travel directions, hotels and other information. ************************************************************** From owner-ibis Tue Aug 1 05:39:22 2000 Received: from mailgate2.Cadence.COM (mailgate2.Cadence.COM [158.140.2.31]) by server.eda.org (8.8.5/8.8.3) with ESMTP id FAA14121 for ; Tue, 1 Aug 2000 05:39:21 -0700 (PDT) Received: from zip.Cadence.COM (zip.Cadence.COM [158.140.103.36]) by mailgate2.Cadence.COM (8.9.3/8.9.3) with ESMTP id FAA19850 for ; Tue, 1 Aug 2000 05:36:45 -0700 (PDT) Received: from cadence.com (zip [158.140.103.36]) by zip.Cadence.COM (8.9.3/8.8.5) with ESMTP id IAA03874; Tue, 1 Aug 2000 08:36:31 -0400 (EDT) Sender: mrl@cadence.com Message-ID: <3986C44F.9BEB00D1@cadence.com> Date: Tue, 01 Aug 2000 08:36:31 -0400 From: Mike LaBonte Organization: Cadence Design Systems X-Mailer: Mozilla 4.51 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ibis-users@eda.org Subject: Re: IBIS standard inconsistency References: <398246BE.39DEAD26@ti.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Received: By mailgate2.Cadence.COM as FAA19850 at Tue Aug 1 05:36:45 2000 The IBIS spec distinguishes between keywords and subparameters. Keywords are enclosed within square brackets. The spec examples of keywords have space separators, even though the spec says that underscores are allowed. The use of opening and closing brackets makes it easy to parse these, even though they may appear as multiple words. The spec also says that underscores and spaces are equivalent. So even though the spec examples use [GND clamp], parsers are supposed to recognize [GND_clamp] as being equivalent. Subparameters have no brackets. The spec states "Spaces are not allowed in subparameter names". An example of a subparameter name is Model_type. Although parsers certainly can handle multiple word sequences, it works out better that subparameters are always a single word (no spaces). Mike LaBonte Cadence Design Systems Stephen Nolan wrote: > > In the IBIS standard, the keywords [IBIS Ver] and [File Rev] appear to the the > only keywords that have capitalized words other than the first word (the word > IBIS being completely capitalized accepted as an acronym). All other keyword > have the first word capitalized followed by the other words lower case. Eg. > [Comment char], [File name], [Voltage range].... > > Why is there an inconsistency in the style of these keywords? > > Also, some multiple-word keywords use an underscore between words instead of a > space. Eg. [GND_clamp], [POWER_clamp]. > > Again, why the inconsistency? > -- > Regards, > Stephen M. Nolan