From Derrick_Duehren@ccm2.jf.intel.com Wed Mar 1 05:21:49 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26496; Wed, 1 Mar 95 05:21:49 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rjoGe-000Ue4C; Wed, 1 Mar 95 05:16 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rjoGd-000twdC; Wed, 1 Mar 95 05:16 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Wed, 1 Mar 95 05:16:38 PST Date: Wed, 1 Mar 95 05:16:38 PST From: Derrick Duehren Message-Id: <950301051638_6@ccm.hf.intel.com> To: IBIS@vhdl.org Cc: Randy_L_Wilhelm@ccm.fm.intel.com, Jerry_Budelman@ccm2.jf.intel.com Subject: Minutes from IBIS Open Forum Meeting 2/24/95 Text item: Text_1 Date: Feb. 28, 1995 From: Will Hobbs (503) 696-4369, fax (503) 696-4210 Will_Hobbs@ccm.jf.intel.com XTG Modeling Manager, Intel Corp., Chairperson, IBIS Open Forum Intel Corporation 5200 NE Elam Young Pkwy, Hillsboro, OR 97124 USA and Derrick Duehren (503) 696-4299, fax (503) 696-4904 Derrick_Duehren@ccm.jf.intel.com Intel Program Manager, IBIS Secretary Subject: Minutes from IBIS Open Forum Meeting 2/24/95 To: Apple Computer Duane Talsahashi ARPA Randy Harr AT&T Global Info Solutions Dave Moxley* Anacad Steffen Rochel Ansoft Henri Maramis Atmel Corporation Dan Terry Cadence Design Sandeep Khanna, C. Kumar Cadlab Ralf Bruning Contec Dileep Divekar* Digital Equipment Corp. Barry Katz EIA Patty Rusher High Design Technology Michael Smith, Dr. Ing. Cosso HP Palo Alto Tom Langdorf HP EESof Karl Kachigan, Henry Wu HyperLynx Kellee Crisafulli* IBM Jay Diepenbrock, Joseph Flanigan IBM-Motorola alliance Lynn Warriner, John Burnett INCASES Werner Rissiek, Olaf Rethmeier Integrated Silicon Systems Eric Bracken Intel Corporation Stephen Peters*, Don Telian, Will Hobbs* Arpad Muranyi*, Derrick Duehren* Interconnectix, Inc. Bob Ross* Intergraph Ian Dodd, David Wiens, Walter Katz IntuSoft Charles Hymowitz Mentor Graphics Ravender Goyal, Greg Doyle Meta-Software Mei Wong, You-Pang Wei, John Sliney MicroSim Arthur Wong National Semiconductor Syed Huq*, Raj Raghuraum, Atul Agarwal* NEC Hiroshi Matsumoto North Carolina State U. Steve Lipa, Michael Steer OptEM Engineering, Inc. Benny Leveille, Ken Ehn Pacific Numerix Paul K. U. Wang PC Ware Paul Munsey, Ron Neville Quad Design Jon Powell* Quantic Labs Mike Ventham Racal-Redac John Berrie Symmetry Martin Walker Synopsys, Logic Modeling G. Bill Lattin Texas Instruments Bob Ward Thomson-CSF/SCTF Jean Lebrun UniCAD Canada Ltd. Stephen Lum Zeelan Technology George Opsahl, Hiro Moriyasu CC: Intel Corporation Randy Wilhelm, Jerry Budelman, Intel IBIS team In the list above, attendees at the meeting are indicated by *. Upcoming Meetings: The bridge numbers for future IBIS teleconferences are listed below: Date Bridge Number Reservation # 3/17/95 (916) 356-9999 461603 4/7/95 (916) 356-9999 461605 4/28/95 (916) 356-9999 461609 All meetings are 8:00 AM to 10:00 AM Pacific Time (16:00 to 18:00 UTC). We try to have agendas out 7 days before each open forum and meeting minutes out within 7 days after. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the reservation number. NOTE: "AR" = Action Required. ------------------------------------------------------------------------------ Check-in, Intros, Announcements There were no new participants. There were no corrections made to last month's minutes. Will reported that Meta Software has licensed the Parser. AR Derrick: Note on the charter document that National Semiconductor has paid for the parser and inform Patti Rusher at EIA. [DONE] Conference Management Systems requested (and Will approved) a $500 payment to CMS for their services over the last two years. This amount is less than half what they typically charge. CMS had been providing the service free with the expectation that we would eventually become a paying client. CMS is now transferring our remaining funds ($1,400) to our EIA account. There were no new agenda items. Press Updates: Integrated Systems Design, March `95, pg 12 and pg 84 EETimes,2/6, Pg 8 Electronic news, 2/6, pg 52 New Models Available: Syed posted two 2.1 models, unchecked with parser because Michael does not have the parser. ds26c31.ibs, an RS-422 Quad Diff Line Driver ds26c32.ibs, an RS-422 Quad Diff Line Receiver Note: Bob Ross checked the files with the 2.1 parser and they passed. AR Jon -- get new parser binary to Michael. We discussed the need for a "Beta" directory in the vhdl.org library with a strong disclaimer file. Jon suggested having some means of enabling people to post models for evaluation. Will suggested indicating in the IBIS file name that the file is experimental/not final. Possibly, the "Beta" directory could be a publicly read/write. AR Michael -- Please make a proposal for this capability [Michael has agreed to make a proposal]. Progress toward enlisting new IC vendors Mike Ventham reported via email to Derrick that he has requested contact information from VLSI in Phoenix, but has not received anything yet. Dave Moxley is working with ASIC suppliers, and has gotten preliminary IBIS models from two of them. The files are not passing the parser yet, but Dave is working with them to get them right. Kellee is working with National and Xylinx. He expects Xylinx to have a set of 2000, 3000, 4000 Xylinx IBIS models for the vhdl.org library in a few months. We discussed the potential need for a separate reflector or newsgroup for IBIS users. [Update, many messages bouncing around the reflector on this topic.] Golden Parser 2.1 progress and release date Many did not receive their copies. Will will reissue the parser and asked if everyone could validate the GP by Friday 3/3/95. The approved parser is needed to get the EIA spec approval process going. Jon reported that he can do cross-compilation of the parser for all but DOS platforms and will update us next week. AR Will -- Resend the Rev 4 Golden Parser to the 13 licensees. [DONE -- Will apologizes. His admin. had prepared the disks to go out and then went on a short medical leave -- it was forgotten.] AR Derrick/Will -- Post Golden Parser 2.1 release approval process. [DONE. The 13 licensees will discuss and vote via email. No vote (silence) will be considered a YES vote.] Status of EIA affiliation Will and Derrick met with Patti Rusher of the EIA yesterday. Patti is OK with everything in our charter. EIA is now handling our finances. All checks can now be made to "EIA". Any payments still sent to CMS will be forwarded to the EIA. Patti will be sending a letter (which Will and Derrick have reviewed) to those in the roster document. The fee structure we decided upon is included. We discussed the cost of sending out a hardcopy of the spec (and possibly a floppy). Kellee volunteered to put together an IBIS "starter kit" with the spec, parser executable, overview, cookbook, and sample models, which we can make available as a floppy with the hardcopy spec. Suggested list price of $20 for spec only, $50 for starter kit. We need a formal process to respond to balloting comments. Bob Ross suggested we have a subcommittee draft a response, have the whole committee review the comment, and then respond officially. Kellee volunteer to chair the committee, and Bob Ross and Jon Powell will participate. Kellee wants to make sure the responses are professional so the commenter feels acknowledged and we continue to get their support. Rev 2.1 updates o S2IBIS 2.1 Bob Ross reported that Michael Steer has a student assigned to work on the conversion utility, but the funding has not yet arrived. Bob Ross suggested that they modularize the program before expanding it further. o Cookbook It could easily be a 3 person-month effort to redo this book. It may be more practical to make smaller changes and additions to the existing book. Syed is creating an internal book for generating models from bench measurement. It is in rough draft form now. Syed will check to see if there is any confidential information included. He thinks that he'll be able to make the material available Kellee volunteered to coordinate the Cookbook update/Starter Kit. Bob Ross and Syed will help. Bob thinks he may have tech pubs help available, though he can't commit yet. Syed put an article in HTML form, and posted it for Mosaic in NSC. Rumor is that the next version of Word can export HTML directly. If we had a vhdl.org IBIS home page, we could link to companies that support IBIS, etc. AR Kellee -- post information on public domain Mosaic software [DONE]. o Overview This document could be rolled into the cookbook. BIRD 25.2 Will reported that Intel has discussed this BIRD internally. Intel's position is that "C_comp is considered an independent variable. This is because C_comp includes bonding pad capacitance, which does not necessarily track fabrication process variations. The conservative approach to using IBIS data will associate large C_comp values with slow, weak models, and the small C_comp values with fast, strong models." (The low value should go in the Min. column.) This means that we have 4 potential models out of each set of data. In 3.0, we may want to add a keyword that can indicate which C_comp goes with the first ramp and vice-versa, if the model provider so chooses. The consensus is that C_comp is magnitude. AR Bob R. -- Add a sentence indicating that "This is an independent variable." [DONE] Bob Ross stepped through each paragraph of the BIRD 25.2. He suggested that portions may be good for inclusion in the new cookbook. Roll-call vote taken. BIRD 25.3 approved unanimously (including the quoted text above.). AR Bob -- Repost as approved BIRD 25.3. [DONE] We discussed options for rolling this BIRD into the spec. If we put this BIRD into the spec, the spec will need to be rolled to 2.2, the parser will also need to be updated. We also identified a need for a formal Golden Parser bug list that identifies everything that the parser does not check. Two issues are left on the table: First, should we roll in this BIRD before sending the 2.1 Spec out for EIA vote or wait to roll it in along with any other changes that come out of the voting process. Second, should be upgrade the parser to catch all 2.1 issues that it does not currently check for? Jon volunteered to do coding work on the GP. Wrap-up, Next Meeting Plans Our next meeting is a teleconference 3/17/95. Suggested Topics: o Tim Schreyer's findings on Diode effects. o Directions for MCM. ============================================================================== NOTES If you know of someone new who wants to join the e-mail reflector (ibis@vhdl.org), send e-mail to ibis-request@vhdl.org. Check the pub/ibis directory on vhdl.org for more information on previous discussions and results. You can get on via ftp anonymous, "guest" login from telnet or dial-in (415-335-0110), or send an email request to the automatic archive server, archive@vhdl.org. ============================================================================== From Derrick_Duehren@ccm2.jf.intel.com Wed Mar 1 05:21:52 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26504; Wed, 1 Mar 95 05:21:52 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rjoGh-000Ue4C; Wed, 1 Mar 95 05:16 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rjoGh-000twdC; Wed, 1 Mar 95 05:16 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Wed, 1 Mar 95 05:16:42 PST Date: Wed, 1 Mar 95 05:16:42 PST From: Derrick Duehren Message-Id: <950301051642_8@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: Golden Parser 2.1 Release Approval Process Text item: Text_1 Golden Parser 2.1 Release Approval Process ========================================== The 13 GP 2.1 licensees will discuss and vote via the IBIS reflector. No vote (silence) will be considered a YES vote. NOTE: I tried unsuccessfully to set up a separate reflector for this discussion and vote. Derrick Duehren IBIS Open Forum Secretary (a volunteer position) Phone (503) 696-4299, Fax (503) 696-4904 Derrick_Duehren@ccm.jf.intel.com 2111 NE 25th, JF1-97, Hillsboro, OR 97224 The Magnificent 13: ------------------- AT&T Global Info Solutions david.moxley@columbiasc.ncr.com Cadence Design Systems cpk@cadence.com Digital Equipment Corp. katz@decsim.enet.dec.com Hewlett-Packard karlk@sr.hp.com HyperLynx kellee@nwlink.com INCASES olaf@cadlab.cadlab.de wr@cadlab.cadlab.de Intel Corp Will_Hobbs@ccm2.jf.intel.com arpad_muranyi@ccm.hf.intel.com speters@ichips.intel.com derrickd Interconnectix, Inc. bob@icx.com Intergraph rkelley@ingr.com idodd@ingr.com Meta Software mei@metasw.com National Semiconductor huq@lightning.nsc.com Quad Design jonp@qdt.com Quantic Labs ventham@quantic.mb.ca From schumach@flare.convex.com Wed Mar 1 07:39:13 1995 Return-Path: Received: from convex.convex.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA27319; Wed, 1 Mar 95 07:39:13 PST Received: from flare.convex.com by convex.convex.com (8.6.4.2/1.35) id JAA14213; Wed, 1 Mar 1995 09:34:03 -0600 Received: from localhost by flare.convex.com (8.6.4/1.28) id JAA02026; Wed, 1 Mar 1995 09:34:01 -0600 Date: Wed, 1 Mar 1995 09:34:01 -0600 From: schumach@flare.convex.com (Richard A. Schumacher) Message-Id: <199503011534.JAA02026@flare.convex.com> To: Derrick_Duehren@ccm2.jf.intel.com, IBIS@vhdl.org Subject: Re: FW: IBIS users group (What will it take?) The ideal solution would be a moderated newsgroup, to keep the noise down, but given the lack of volunteers for a "model champion" we'd probably have a similar lack of moderators. Unmoderated newsgroup versus the present mail list is a close call for me, but I'd say stay with mail list. From schumach@flare.convex.com Wed Mar 1 07:42:17 1995 Return-Path: Received: from convex.convex.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA27332; Wed, 1 Mar 95 07:42:17 PST Received: from flare.convex.com by convex.convex.com (8.6.4.2/1.35) id JAA15128; Wed, 1 Mar 1995 09:37:07 -0600 Received: from localhost by flare.convex.com (8.6.4/1.28) id JAA02095; Wed, 1 Mar 1995 09:37:05 -0600 Date: Wed, 1 Mar 1995 09:37:05 -0600 From: schumach@flare.convex.com (Richard A. Schumacher) Message-Id: <199503011537.JAA02095@flare.convex.com> To: Mark=Leonard%CAE%PCPD=Hou@bangate.compaq.com, Will_Hobbs@ccm2.jf.intel.com, ibis@vhdl.org Subject: Re: Re[2]: IBIS Users' Group But if people keep replying with quotes of entire threads, including headers (!), I'll vote for a newsgroup instead of mail list. What ever happened to the concept of paraphrasing? From kellee@nwlink.com Wed Mar 1 14:50:08 1995 Return-Path: Received: from washington.nwlink.com (nwlink.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA01656; Wed, 1 Mar 95 14:50:08 PST Received: by washington.nwlink.com id AA11231 (5.67b/IDA-1.5 for ibis@vhdl.org); Wed, 1 Mar 1995 14:44:07 -0800 Date: Wed, 1 Mar 1995 14:44:07 -0800 Message-Id: <199503012244.AA11231@washington.nwlink.com> X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis@vhdl.org From: kellee@nwlink.com Subject: Re: SOS noise Response to Greg Hi Greg, >Would I be correct to assume that a simulator can generate di/dt >information by using the risetime data and V-I curves? YES >1. Driver di/dt is dependent on the slew rate of the input to the > driver, which in turn is dependent on the previous stage of logic > and its loading. The IBIS model should effectively include this effect. >2. Driver di/dt is also dependent on its own loading, i.e. the package > and transmission line. If there is strong coupling between adjacent > signals in the package, this can affect di/dt, too. The transmission line should be included by the simulator. The package effects would also be modeled, to the degree determined by the type of package model included in the IBIS file. Have a great day...Kellee Crisafulli, HyperLynx Inc. From kellee@nwlink.com Wed Mar 1 15:02:38 1995 Return-Path: Received: from washington.nwlink.com (nwlink.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA01757; Wed, 1 Mar 95 15:02:38 PST Received: by washington.nwlink.com id AA11853 (5.67b/IDA-1.5 for ibis@vhdl.org); Wed, 1 Mar 1995 14:56:38 -0800 Date: Wed, 1 Mar 1995 14:56:38 -0800 Message-Id: <199503012256.AA11853@washington.nwlink.com> X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis@vhdl.org From: kellee@nwlink.com Subject: Vote on IBISCHK2, (HyperLynx) HyperLynx votes NO on releasing V2.1d of the translator until all 5 of the items I mentioned are fixed. I might be willing to soften this if the entire group has strong feelings, however I think the case sensitivity will be pain for many future users. Fixing all 5 of these items should be relatively trival. Have a great day...Kellee Crisafulli, HyperLynx Inc. From contec!contec.contec.COM!dileep@netcom.com Wed Mar 1 15:04:58 1995 Return-Path: Received: from netcomsv.netcom.com (uucp7.netcom.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA01796; Wed, 1 Mar 95 15:04:58 PST Received: from contec.UUCP by netcomsv.netcom.com with UUCP (8.6.9/SMI-4.1) id OAA04443; Wed, 1 Mar 1995 14:38:19 -0800 Received: from contec13.contec.COM ([192.9.200.182]) by contec.COM (4.1/SMI-4.1) id AA28582; Wed, 1 Mar 95 14:02:34 PST Received: by contec13.contec.COM (5.0/SMI-SVR4) id AA26014; Wed, 1 Mar 1995 14:05:25 +0800 Date: Wed, 1 Mar 1995 14:05:25 +0800 From: dileep@contec.contec.COM (Dileep Divekar) Message-Id: <9503012205.AA26014@contec13.contec.COM> To: ibis@vhdl.org Subject: IBIS and SSO Cc: dileep@contec.contec.COM X-Sun-Charset: US-ASCII Content-Length: 1030 I have been reading the discussion about using IBIS models for modeling simultaneous switching noise (SSN). When the outputs are transitioning, the current thru supply or ground leads causes a voltage drop in the corresponding inductors, giving rise to SSN. IBIS provides information about these parasitic inductors. But based on my limited understanding of IBIS models, they do not provide information as to the supply and ground currents for each buffer when it is making a transition. These currents will be different from the dc I-V information provided for the output stage. Perhaps some one who knows more about the IBIS specification can provide a pointer to that information if it is already available in the present IBIS specification. Thanks. ------------------------------------------------------------ Dileep Divekar Contec Microelectronics 2188 Bering Drive San Jose, CA 95131 Phone - (408)-434-6767 x 126 Fax - (408)-434-6884 Email - dileep@contec.com ------------------------------------------------------------ From kellee@nwlink.com Wed Mar 1 15:16:02 1995 Return-Path: Received: from washington.nwlink.com (nwlink.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02037; Wed, 1 Mar 95 15:16:02 PST Received: by washington.nwlink.com id AA12290 (5.67b/IDA-1.5 for ibis@vhdl.org); Wed, 1 Mar 1995 15:10:02 -0800 Date: Wed, 1 Mar 1995 15:10:02 -0800 Message-Id: <199503012310.AA12290@washington.nwlink.com> X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis@vhdl.org From: kellee@nwlink.com Subject: Soliciting inputs for IBIS COOKBOOK V2.1 Hello IBIS citizens, "The time has come for all good men to come to the aid of their country." I am starting to collect information for the next generation of the IBIS cookbook. The COOKBOOK is a document intended to recommend procedures and methods to use when developing an IBIS model. This will be made available to individuals and companys interested in creating IBIS models. If you have a helpful hint, or any information you have written for your company relating to model development please let me know if you could contribute it to the cookbook. The following individuals have already indicated they may be able to supply information or assist with the development of the cookbook. Will, Derrick, Peter @ Intel (Provided the version 1.1 Cookbook) Kellee @ HyperLynx (editor for V2.x cookbook) Syed @ National, (May be able to release a cookbook he is working on) Bob @ Interconnectix (Misc. hints, and assist with editing) Can anyone else contribute? Someone who is actively developing a model at an IC company would be very very welcome! Kellee Have a great day...Kellee Crisafulli, HyperLynx Inc. From Will_Hobbs@ccm2.jf.intel.com Wed Mar 1 17:04:52 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02880; Wed, 1 Mar 95 17:04:52 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rjzEp-000UjeC; Wed, 1 Mar 95 16:59 PST Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rjzEp-000twoC; Wed, 1 Mar 95 16:59 PST Received: by ccm.jf.intel.com (ccmgate 3.0) Wed, 1 Mar 95 16:59:30 PST Date: Wed, 1 Mar 95 16:59:30 PST From: Will Hobbs Message-Id: <950301165930_2@ccm.jf.intel.com> To: 73053.721@compuserve.com, ibis@vhdl.org, kellee@nwlink.com Subject: Re: Vote on IBISCHK2, (HyperLynx) Text item: Kellee, I don't think Derrick's mail was necessarily a call for votes, but a description of the process. Since the parser has some known bugs, we need to get them fixed and re-send the parser to the licensees. When we feel it is good, the vote will be taken. Will HyperLynx votes NO on releasing V2.1d of the translator until all 5 of the items I mentioned are fixed. I might be willing to soften this if the entire group has strong feelings, however I think the case sensitivity will be pain for many future users. Fixing all 5 of these items should be relatively trival. Have a great day...Kellee Crisafulli, HyperLynx Inc. Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: Vote on IBISCHK2, (HyperLynx) From: kellee@nwlink.com To: ibis@vhdl.org Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: Windows Eudora Version 2.0.3 Message-Id: <199503012256.AA11853@washington.nwlink.com> Date: Wed, 1 Mar 1995 14:56:38 -0800 Received: by washington.nwlink.com id AA11853 (5.67b/IDA-1.5 for ibis@vhdl.org); Wed, 1 Mar 1995 14:56:38 -0800 Received: from washington.nwlink.com (nwlink.com) by vhdl.vhdl.org (4.1/SMI-4.1/ BARRNet) id AA01757; Wed, 1 Mar 95 15:02:38 PST Received: from VHDL.VHDL.ORG by hermes.intel.com (5.65/10.0i); Wed, 1 Mar 95 15: 24:36 -0800 Received: from hermes.intel.com by ichips.intel.com (5.64+/10.0i); Wed, 1 Mar 95 15:24:41 -0800 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0rjxl6-000twpC; Wed, 1 Mar 95 15:24 PST From Derrick_Duehren@ccm2.jf.intel.com Wed Mar 1 17:24:11 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA03028; Wed, 1 Mar 95 17:24:11 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rjzXi-000UhpC; Wed, 1 Mar 95 17:19 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rjzXi-000twoC; Wed, 1 Mar 95 17:19 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Wed, 1 Mar 95 17:19:02 PST Date: Wed, 1 Mar 95 17:19:02 PST From: Derrick Duehren Message-Id: <950301171902_1@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: Re: Soliciting inputs for IBIS COOKBOOK V2.1 Text item: Kellee, Let's see. For the cookbook, here's my killer chunky spaghetti sauce recipe: ----------------------------------------------- Derrick's spaghetti sauce ----------------------------------------------- 1 lb. ground beef (browned) 1 lb. Italian sausage (sliced and browned) 1 16 oz can tomato sauce 1 16 oz can stewed tomatoes 1 8 oz can tomato paste 1/2 medium onion (diced) 1 can pitted olives (sliced) 1 Tbs. oregano 1 tsp. garlic powder 1 Tbs. sugar 1/2 tsp. chili pepper 1 tsp. pepper 1/2 tsp. salt Water as needed (usually 1 cup) Optional: Diced green pepper 16 oz frozen spinach Put it all in a big pot and let it simmer for at least 45 min. ----------------------------------------------- I can't add much technical value to the cookbook, but I can do non-technical editing, if you don't have the resources there. Derrick Duehren IBIS Open Forum Secretary (a volunteer position) Phone (503) 696-4299, Fax (503) 696-4904 Derrick_Duehren@ccm.jf.intel.com 2111 NE 25th, JF1-97, Hillsboro, OR 97224 ______________________________ Reply Separator _________________________________ Subject: Soliciting inputs for IBIS COOKBOOK V2.1 Author: kellee@nwlink.com at SMTPGATE Date: 3/1/95 3:19 PM Hello IBIS citizens, "The time has come for all good men to come to the aid of their country." I am starting to collect information for the next generation of the IBIS cookbook. The COOKBOOK is a document intended to recommend procedures and methods to use when developing an IBIS model. This will be made available to individuals and companys interested in creating IBIS models. If you have a helpful hint, or any information you have written for your company relating to model development please let me know if you could contribute it to the cookbook. The following individuals have already indicated they may be able to supply information or assist with the development of the cookbook. Will, Derrick, Peter @ Intel (Provided the version 1.1 Cookbook) Kellee @ HyperLynx (editor for V2.x cookbook) Syed @ National, (May be able to release a cookbook he is working on) Bob @ Interconnectix (Misc. hints, and assist with editing) Can anyone else contribute? Someone who is actively developing a model at an IC company would be very very welcome! Kellee Have a great day...Kellee Crisafulli, HyperLynx Inc. Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: Soliciting inputs for IBIS COOKBOOK V2.1 From: kellee@nwlink.com To: ibis@vhdl.org Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: Windows Eudora Version 2.0.3 Message-Id: <199503012310.AA12290@washington.nwlink.com> Date: Wed, 1 Mar 1995 15:10:02 -0800 Received: by washington.nwlink.com id AA12290 (5.67b/IDA-1.5 for ibis@vhdl.org); Wed, 1 Mar 1995 15:10:02 -0800 Received: from washington.nwlink.com (nwlink.com) by vhdl.vhdl.org (4.1/SMI-4.1/ BARRNet) id AA02037; Wed, 1 Mar 95 15:16:02 PST Received: from vhdl.vhdl.org by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rjxfy-000UjOC; Wed, 1 Mar 95 15:19 PST Received: from ormail.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0rjxfy-000twoC; Wed, 1 Mar 95 15:19 PST From kellee@nwlink.com Wed Mar 1 19:15:07 1995 Return-Path: Received: from washington.nwlink.com (nwlink.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA03942; Wed, 1 Mar 95 19:15:07 PST Received: by washington.nwlink.com id AA26129 (5.67b/IDA-1.5 for ibis@vhdl.org); Wed, 1 Mar 1995 19:09:04 -0800 Date: Wed, 1 Mar 1995 19:09:04 -0800 Message-Id: <199503020309.AA26129@washington.nwlink.com> X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis@vhdl.org From: kellee@nwlink.com Subject: SOS (reply to Dileep) Hi Dileep, My assumptions are: 1) Steady state currents can be ignored since they don't contribute significantly to ground bounce. 2) Internal buffer currents driving low pF gate loads can be ignored relative to the much large output transistor, package, and external loading. 3) Internal logic switching noise can be negelected. 4) I have done hundreds of SOS measurements with PLD's and FPGA's. The output buffer switching with all other internal logic held constant always seemed to generate the majority of the SOS energy. I admit I don't have any data about chips like the new advanced microprocessors. Although I did do some SOS tests on a 68000 about 10 years ago and the buffer loading was again the major contributor. 5)Cross over region currents are small. That is the current that flows when both devices in a totem pole or CMOS output is smaller than the current resulting from the output switching the load and package and parasitic capacitance of the output stage. This is the one that I believe has the most room to cause error. But it is also highly process dependant. So in summary, while there are hundreds of other effects contributing to SOS I believe the output buffer transition is at least the major contributor. I won't be insulted if someone want's to tell me I am full of IBIS droppings. This is just some seat of the pant's info I have used over the years. Kellee Have a great day...Kellee Crisafulli, HyperLynx Inc. From uunet!qdt.com!jonp@uunet.uu.net Wed Mar 1 19:51:31 1995 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04154; Wed, 1 Mar 95 19:51:31 PST Received: from uucp1.UU.NET by relay3.UU.NET with SMTP id QQyfgp07015; Wed, 1 Mar 1995 22:46:04 -0500 Received: from qdt.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Wed, 1 Mar 1995 22:45:34 -0500 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01466; Wed, 1 Mar 95 18:15:05 PST Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA27139; Wed, 1 Mar 95 18:19:05 PST Received: from uucp1.UU.NET by relay3.UU.NET with SMTP id QQyfgj26933; Wed, 1 Mar 1995 21:16:23 -0500 Received: from qdt.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Wed, 1 Mar 1995 21:15:56 -0500 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA01388; Wed, 1 Mar 95 17:03:24 PST Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA26897; Wed, 1 Mar 95 17:07:24 PST Date: Wed, 1 Mar 95 17:07:24 PST From: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell) Message-Id: <9503020107.AA26897@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA27278; Wed, 1 Mar 95 17:05:23 PST To: uunet!uunet!contec.contec.COM!dileep@uunet.uu.net Cc: uunet!uunet!vhdl.org!ibis@uunet.uu.net, uunet!uunet!contec.contec.COM!dileep@uunet.uu.net In-Reply-To: Dileep Divekar's message of Wed, 1 Mar 1995 14:05:25 +0800 <9503012205.AA26014@contec13.contec.COM> Subject: IBIS and SSO >transition. These currents will be different from >the dc I-V information provided for the output stage. >Perhaps some one who knows more about the IBIS specification >can provide a pointer to that information if it is already >available in the present IBIS specification. There are, of course, different levels of accuracy, but the 2.1 IBIS spec (with AC waveforms and pin connection maps) does give enough data to model much of the risetime effects and current starvation effects of SSO on output devices. There is more information that we could add to increase the accuracy but in general I think you quickly get to a point where the most important issues become sub nano-second skew time between drivers and the actual physical description of the power routes which are not attainable in the IBIS level of information (and probably, to the common customer, not at all in any format ever). So it behoves us to make a good guess. (sorry, engineering approximation) jonp From bert@ibmoto.com Thu Mar 2 09:08:15 1995 Return-Path: Received: from styx.ibmoto.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA12740; Thu, 2 Mar 95 09:08:15 PST Received: from lw.ibmoto.com (lw.ibmoto.com [129.38.13.34]) by styx.ibmoto.com (8.6.10/8.6.9) with ESMTP id LAA27012; Thu, 2 Mar 1995 11:00:57 -0600 Received: (bert@localhost) by lw.ibmoto.com (8.6.10/8.6.9) id LAA19775; Thu, 2 Mar 1995 11:00:56 -0600 Message-Id: <199503021700.LAA19775@lw.ibmoto.com> To: ibis@vhdl.org Cc: jwalsh%ausvmr@ausvm6.austin.ibm.com, bert@ibmoto.com Subject: SOS (reply to Dileep) Date: Thu, 02 Mar 95 11:00:56 -0600 From: Lynn Warriner I agree with Kellee. Specifically for the PowerPC chips the output transistors have their own power and gnd pins. Even the logic that drives the final devices are independant of the output devices. The one problems that I see with IBIS modeling of SOS is accounting for the power and gnd parasitics properly, including mutual inductances. Also, information about when the devices switch is important. For example, by setting a few hundred pico second skew on the switching of drivers on one PowerPC chip lead to a reduction of the ground bounce voltage by a factor of two. To make this all meaningful -- The present IBIS models do not contain sufficent package information and driver switching skews to provide an accurate model. However, it can certainly be used as a bounding case. Regards, Lynn Warriner ------- Forwarded Message Received: from erebus.ibmoto.com (erebus.ibmoto.com [129.38.203.1]) by styx.ibmoto.com (8.6.10/8.6.9) with ESMTP id VAA13967 for ; Wed, 1 Mar 1995 21:14:02 -0600 From: kellee@nwlink.com Received: from vhdl.vhdl.org (VHDL.VHDL.ORG [198.31.14.3]) by erebus.ibmoto.com (8.6.9/8.6.9) with SMTP id VAA16540 for ; Wed, 1 Mar 1995 21:14:54 -0600 Received: from washington.nwlink.com (nwlink.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA03942; Wed, 1 Mar 95 19:15:07 PST Received: by washington.nwlink.com id AA26129 (5.67b/IDA-1.5 for ibis@vhdl.org); Wed, 1 Mar 1995 19:09:04 -0800 Date: Wed, 1 Mar 1995 19:09:04 -0800 Message-Id: <199503020309.AA26129@washington.nwlink.com> X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis@vhdl.org Subject: SOS (reply to Dileep) Hi Dileep, My assumptions are: 1) Steady state currents can be ignored since they don't contribute significantly to ground bounce. 2) Internal buffer currents driving low pF gate loads can be ignored relative to the much large output transistor, package, and external loading. 3) Internal logic switching noise can be negelected. 4) I have done hundreds of SOS measurements with PLD's and FPGA's. The output buffer switching with all other internal logic held constant always seemed to generate the majority of the SOS energy. I admit I don't have any data about chips like the new advanced microprocessors. Although I did do some SOS tests on a 68000 about 10 years ago and the buffer loading was again the major contributor. 5)Cross over region currents are small. That is the current that flows when both devices in a totem pole or CMOS output is smaller than the current resulting from the output switching the load and package and parasitic capacitance of the output stage. This is the one that I believe has the most room to cause error. But it is also highly process dependant. So in summary, while there are hundreds of other effects contributing to SOS I believe the output buffer transition is at least the major contributor. I won't be insulted if someone want's to tell me I am full of IBIS droppings. This is just some seat of the pant's info I have used over the years. Kellee Have a great day...Kellee Crisafulli, HyperLynx Inc. ------- End of Forwarded Message From uunet!qdt.com!jonp@uunet.uu.net Thu Mar 2 09:23:32 1995 Return-Path: Received: from relay3.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA12882; Thu, 2 Mar 95 09:23:32 PST Received: from uucp1.UU.NET by relay3.UU.NET with SMTP id QQyfir15013; Thu, 2 Mar 1995 12:17:07 -0500 Received: from qdt.UUCP by uucp1.UU.NET with UUCP/RMAIL ; Thu, 2 Mar 1995 12:16:58 -0500 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00565; Thu, 2 Mar 95 08:43:44 PST Received: from qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA29045; Thu, 2 Mar 95 08:47:45 PST Received: from uucp3.UU.NET by relay3.UU.NET with SMTP id QQyfip06282; Thu, 2 Mar 1995 11:45:35 -0500 Received: from qdt.UUCP by uucp3.UU.NET with UUCP/RMAIL ; Thu, 2 Mar 1995 11:45:33 -0500 Received: from hal.qdt.com by qdt.com (4.1/SMI-4.1) id AA00515; Thu, 2 Mar 95 08:05:35 PST Received: from f14.qdt.com by hal.qdt.com (4.1/SMI-4.1) id AA28953; Thu, 2 Mar 95 08:09:37 PST Date: Thu, 2 Mar 95 08:09:37 PST From: uunet!qdt.com!jonp@uunet.uu.net (Jon Powell) Message-Id: <9503021609.AA28953@hal.qdt.com> Received: by f14.qdt.com (4.1/SMI-4.1) id AA27304; Thu, 2 Mar 95 08:07:35 PST To: uunet!uunet!ccm2.jf.intel.com!Derrick_Duehren@uunet.uu.net Cc: uunet!uunet!vhdl.org!IBIS@uunet.uu.net In-Reply-To: Derrick Duehren's message of Wed, 1 Mar 95 17:19:02 PST <950301171902_1@ccm.hf.intel.com> Subject: Soliciting inputs for IBIS COOKBOOK V2.1 Derrick, how does you spaghetti sauce model SSO ? jonp From Will_Hobbs@ccm2.jf.intel.com Thu Mar 2 10:36:37 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA13828; Thu, 2 Mar 95 10:36:37 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rkFcw-000UjcC; Thu, 2 Mar 95 10:29 PST Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rkFcv-000twoC; Thu, 2 Mar 95 10:29 PST Received: by ccm.jf.intel.com (ccmgate 3.0) Thu, 2 Mar 95 10:29:29 PST Date: Thu, 2 Mar 95 10:29:29 PST From: Will Hobbs Message-Id: <950302102929_8@ccm.jf.intel.com> To: ibis@vhdl.org Cc: jwalsh%ausvmr@ausvm6.austin.ibm.com, bert@ibmoto.com Subject: Re: SOS (reply to Dileep) Text item: Lynn, all of these concerns are addressed in IBIS 2.1. Regards, Will Hobbs I agree with Kellee. Specifically for the PowerPC chips the output transistors have their own power and gnd pins. Even the logic that drives the final devices are independant of the output devices. The one problems that I see with IBIS modeling of SOS is accounting for the power and gnd parasitics properly, including mutual inductances. Also, information about when the devices switch is important. For example, by setting a few hundred pico second skew on the switching of drivers on one PowerPC chip lead to a reduction of the ground bounce voltage by a factor of two. To make this all meaningful -- The present IBIS models do not contain sufficent package information and driver switching skews to provide an accurate model. However, it can certainly be used as a bounding case. Regards, Lynn Warriner ------- Forwarded Message Received: from erebus.ibmoto.com (erebus.ibmoto.com [129.38.203.1]) by styx.ibmoto.com (8.6.10/8.6.9) with ESMTP id VAA13967 for ; Wed, 1 Mar 1995 21:14:02 -0600 From: kellee@nwlink.com Received: from vhdl.vhdl.org (VHDL.VHDL.ORG [198.31.14.3]) by erebus.ibmoto.com (8.6.9/8.6.9) with SMTP id VAA16540 for ; Wed, 1 Mar 1995 21:14:54 -0600 Received: from washington.nwlink.com (nwlink.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA03942; Wed, 1 Mar 95 19:15:07 PST Received: by washington.nwlink.com id AA26129 (5.67b/IDA-1.5 for ibis@vhdl.org); Wed, 1 Mar 1995 19:09:04 -0800 Date: Wed, 1 Mar 1995 19:09:04 -0800 Message-Id: <199503020309.AA26129@washington.nwlink.com> X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis@vhdl.org Subject: SOS (reply to Dileep) Hi Dileep, My assumptions are: 1) Steady state currents can be ignored since they don't contribute significantly to ground bounce. 2) Internal buffer currents driving low pF gate loads can be ignored relative to the much large output transistor, package, and external loading. 3) Internal logic switching noise can be negelected. 4) I have done hundreds of SOS measurements with PLD's and FPGA's. The output buffer switching with all other internal logic held constant always seemed to generate the majority of the SOS energy. I admit I don't have any data about chips like the new advanced microprocessors. Although I did do some SOS tests on a 68000 about 10 years ago and the buffer loading was again the major contributor. 5)Cross over region currents are small. That is the current that flows when both devices in a totem pole or CMOS output is smaller than the current resulting from the output switching the load and package and parasitic capacitance of the output stage. This is the one that I believe has the most room to cause error. But it is also highly process dependant. So in summary, while there are hundreds of other effects contributing to SOS I believe the output buffer transition is at least the major contributor. I won't be insulted if someone want's to tell me I am full of IBIS droppings. This is just some seat of the pant's info I have used over the years. Kellee Have a great day...Kellee Crisafulli, HyperLynx Inc. ------- End of Forwarded Message Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. From: Lynn Warriner Date: Thu, 02 Mar 95 11:00:56 -0600 Subject: SOS (reply to Dileep) Cc: jwalsh%ausvmr@ausvm6.austin.ibm.com, bert@ibmoto.com To: ibis@vhdl.org Message-Id: <199503021700.LAA19775@lw.ibmoto.com> Received: (bert@localhost) by lw.ibmoto.com (8.6.10/8.6.9) id LAA19775; Thu, 2 M ar 1995 11:00:56 -0600 Received: from lw.ibmoto.com (lw.ibmoto.com [129.38.13.34]) by styx.ibmoto.com ( 8.6.10/8.6.9) with ESMTP id LAA27012; Thu, 2 Mar 1995 11:00:57 -0600 Received: from styx.ibmoto.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA12740; Thu, 2 Mar 95 09:08:15 PST Received: from VHDL.VHDL.ORG by hermes.intel.com (5.65/10.0i); Thu, 2 Mar 95 09: 34:47 -0800 Received: from hermes.intel.com by ichips.intel.com (5.64+/10.0i); Thu, 2 Mar 95 09:34:54 -0800 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0rkEm8-000twrC; Thu, 2 Mar 95 09:34 PST From Arpad_Muranyi@ccm.fm.intel.com Fri Mar 3 08:25:29 1995 Return-Path: Received: from ormail.intel.com ([134.134.192.3]) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA25688; Fri, 3 Mar 95 08:25:29 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rka5I-000Uf4C; Fri, 3 Mar 95 08:20 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rka5I-000twpC; Fri, 3 Mar 95 08:20 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Fri, 3 Mar 95 08:20:06 PST Date: Fri, 3 Mar 95 08:20:06 PST From: Arpad Muranyi Message-Id: <950303082006_3@ccm.hf.intel.com> To: 73053.721@compuserve.com_at_smtpgate@ccm.hf.intel.com, 75123.3477@compuserve.com_at_smtpgate@ccm.hf.intel.com, ibis@vhdl.org Cc: kellee@nwlink.com_at_smtpgate@ccm.hf.intel.com, Will_Hobbs@ccm2.jf.intel.com Subject: Re: name casing Text item: Hi IBIS gurues, As far as I remember, the only request we made originally was to disable case sensitivity for DOS/Windows or PC compiled systems. Now that we have so many operating systems on various machines which emulate other operating systems, this request is not so clear to me any more. I am not even sure what the reason for the all-lower case rule was for case sensitive operating systems such as UNIX. To make things simple (?) would it make sense to compile case insensitive for those operating systems which are case insensitive, and case sensitive for those which are case sensitive? Arpad Muranyi Intel Corporation ----------------------------------------------------------------------------- All, I think I understand the name casing problem, but don't gather from the mail what the solution is supposed to be. Here's my take on it: 1) For DOS it makes sense to take the filename input by the user and convert it to lowercase before processing it. I assume other applications must do this because 'edit abc' does the same thing for me as 'edit ABC' (i.e., I get the same file both times). 2) Other O.S.'s (NT, UNIX) accessing DOS filesystems is not really a parser bug. The spec says that filenames must be all lower case, but this seems to conflict with the senario mentioned. I can only think of 3 solutions, none of which seem complete: - We can change the parser as mentioned in #1, but that won't help #2. - We can put in a compile switch that will allow the product to always convert the input name to lowercase, but that will only help those who purchase the source and can compile it that way. - We can always convert the input name to lowercase and fully eliminate the opportunity of UNIX, NT, ... users from parsing files that have any uppercase characters in their names. This could be fine since the rules say they must be lowercase. However, if a UNIX user happens to have 2 files, one called 'abc.ibs' and the other 'ABC.ibs', and they enter 'ibischk2 ABC.ibs' they will end up parsing the other file and probably not know their mistake. Please email Ron and I with your suggestions. Paul Munsey Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Message-Id: <950303061654_73053.721_GHB63-2@CompuServe.COM> Subject: name casing Cc: Kellee Crisafulli , Will Hobbs To: Arpad Muranyi , Ron Neville <75123.3477@compuserve.com>, Bob Ross From: Paul Munsey <73053.721@compuserve.com> Date: 03 Mar 95 01:16:55 EST Received: by dub-img-2.compuserve.com (8.6.10/5.941228sam) id BAA14310; Fri, 3 Mar 1995 01:18:32 -0500 Received: from dub-img-2.compuserve.com by hermes.intel.com (5.65/10.0i); Fri, 3 Mar 95 02:41:25 -0800 Received: from hermes.intel.com by fmmail.fm.intel.com with smtp (Smail3.1.28.1 #2) id m0rkUla-000algC; Fri, 3 Mar 95 02:39 PST From Will_Hobbs@ccm2.jf.intel.com Fri Mar 3 09:27:54 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26118; Fri, 3 Mar 95 09:27:54 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rkb3Y-000UeMC; Fri, 3 Mar 95 09:22 PST Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rkb3X-000twoC; Fri, 3 Mar 95 09:22 PST Received: by ccm.jf.intel.com (ccmgate 3.0) Fri, 3 Mar 95 09:22:22 PST Date: Fri, 3 Mar 95 09:22:22 PST From: Will Hobbs Message-Id: <950303092222_1@ccm.jf.intel.com> To: Arpad_Muranyi@ccm.fm.intel.com, 73053.721%compuserve.com_at_smtpgate@ccm.hf.intel.com, 75123.3477%compuserve.com_at_smtpgate@ccm.hf.intel.com, ibis@vhdl.org Cc: kellee%nwlink.com_at_smtpgate@ccm.hf.intel.com Subject: Re[2]: name casing Text item: Arpad, I thought you had experienced a problem putting ibis_chk under Windows because Windows read all file names as upper case. We wanted case insensitivity so regardless of how a brain-dead operating system messed with characters, the file could still be parsed. The spec says use lower case names so we wouldn't have the situation Paul describes, where two different files differ only in their case, making them OS-dependent. In my opinion, all file names should be treated as if they were all lower case, regardless of how they actually appear in the file system to the OS. Will Hi IBIS gurues, As far as I remember, the only request we made originally was to disable case sensitivity for DOS/Windows or PC compiled systems. Now that we have so many operating systems on various machines which emulate other operating systems, this request is not so clear to me any more. I am not even sure what the reason for the all-lower case rule was for case sensitive operating systems such as UNIX. To make things simple (?) would it make sense to compile case insensitive for those operating systems which are case insensitive, and case sensitive for those which are case sensitive? Arpad Muranyi Intel Corporation ----------------------------------------------------------------------------- All, I think I understand the name casing problem, but don't gather from the mail what the solution is supposed to be. Here's my take on it: 1) For DOS it makes sense to take the filename input by the user and convert it to lowercase before processing it. I assume other applications must do this because 'edit abc' does the same thing for me as 'edit ABC' (i.e., I get the same file both times). 2) Other O.S.'s (NT, UNIX) accessing DOS filesystems is not really a parser bug. The spec says that filenames must be all lower case, but this seems to conflict with the senario mentioned. I can only think of 3 solutions, none of which seem complete: - We can change the parser as mentioned in #1, but that won't help #2. - We can put in a compile switch that will allow the product to always convert the input name to lowercase, but that will only help those who purchase the source and can compile it that way. - We can always convert the input name to lowercase and fully eliminate the opportunity of UNIX, NT, ... users from parsing files that have any uppercase characters in their names. This could be fine since the rules say they must be lowercase. However, if a UNIX user happens to have 2 files, one called 'abc.ibs' and the other 'ABC.ibs', and they enter 'ibischk2 ABC.ibs' they will end up parsing the other file and probably not know their mistake. Please email Ron and I with your suggestions. Paul Munsey Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Message-Id: <950303061654_73053.721_GHB63-2@CompuServe.COM> Subject: name casing Cc: Kellee Crisafulli , Will Hobbs To: Arpad Muranyi , Ron Neville <75123.3477@compuserve.com>, Bob Ross From: Paul Munsey <73053.721@compuserve.com> Date: 03 Mar 95 01:16:55 EST Received: by dub-img-2.compuserve.com (8.6.10/5.941228sam) id BAA14310; Fri, 3 Mar 1995 01:18:32 -0500 Received: from dub-img-2.compuserve.com by hermes.intel.com (5.65/10.0i); Fri, 3 Mar 95 02:41:25 -0800 Received: from hermes.intel.com by fmmail.fm.intel.com with smtp (Smail3.1.28.1 #2) id m0rkUla-000algC; Fri, 3 Mar 95 02:39 PST Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: Re: name casing Cc: kellee%nwlink.com_at_smtpgate@ccm.hf.intel.com, Will_Hobbs@ccm2.jf.intel.com To: 73053.721%compuserve.com_at_smtpgate@ccm.hf.intel.com, 75123.3477%compuserve.com_at_smtpgate@ccm.hf.intel.com, ibis@vhdl.org Message-Id: <950303082006_3@ccm.hf.intel.com> From: Arpad Muranyi Date: Fri, 3 Mar 95 08:20:06 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Fri, 3 Mar 95 08:20:06 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rka5I-000twpC; Fri, 3 Mar 95 08:20 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rka5I-000Uf4C; Fri, 3 Mar 95 08:20 PST Received: from ormail.intel.com ([134.134.192.3]) by vhdl.vhdl.org (4.1/SMI-4.1/ BARRNet) id AA25688; Fri, 3 Mar 95 08:25:29 PST Received: from VHDL.VHDL.ORG by aurora.intel.com (5.65/10.0i); Fri, 3 Mar 95 08: 58:38 -0800 Received: from aurora by ichips.intel.com (5.64+/10.0i); Fri, 3 Mar 95 08:59:09 -0800 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0rkah6-000twoC; Fri, 3 Mar 95 08:59 PST From kellee@nwlink.com Fri Mar 3 13:41:41 1995 Return-Path: Received: from washington.nwlink.com (nwlink.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA06020; Fri, 3 Mar 95 13:41:41 PST Received: by washington.nwlink.com id AA01669 (5.67b/IDA-1.5 for ibis@vhdl.org); Fri, 3 Mar 1995 13:35:41 -0800 Date: Fri, 3 Mar 1995 13:35:41 -0800 Message-Id: <199503032135.AA01669@washington.nwlink.com> X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis@vhdl.org From: kellee@nwlink.com Subject: Re name casing for IBIS files I believe solution number 2 from Paul, or the following statement from Will both reflect what I believe is the best solution: > All file names should be treated as if they were all lower case, > regardless of how they actually appear in the file system to the OS. In other words continue the requirement that the file name be lower case as written into the actual IBIS file. However IBISCHK2 should convert the input file name to all lower case. This way if the user creates a file on DOS and sends it to another operating system it will still work. As far as users mixing up files like foo.ibs and FOO.ibs, the spec requires lower case file names and the parser already enforces it. Therefore I believe this fixes the problem and is consistent with our current specification. Kellee Have a great day...Kellee Crisafulli, HyperLynx Inc. From Arpad_Muranyi@ccm.fm.intel.com Fri Mar 3 17:26:53 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07522; Fri, 3 Mar 95 17:26:53 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rkiXP-000UedC; Fri, 3 Mar 95 17:21 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rkiXP-000twrC; Fri, 3 Mar 95 17:21 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Fri, 3 Mar 95 17:21:43 PST Date: Fri, 3 Mar 95 17:21:43 PST From: Arpad Muranyi Message-Id: <950303172143_3@ccm.hf.intel.com> To: Will_Hobbs@ccm2.jf.intel.com, ibis@vhdl.org Subject: Re[3]: name casing Text item: WILL, Yes, I had a problem with Windows being able to pass the arguments as upper-case only when doing a "File-Run..." thing on a highlighted file in File Manager. Are you suggesting with your last sentence that the parser should ignore the case all together? Arpad -------------------------------------------------------------------------------- Arpad, I thought you had experienced a problem putting ibis_chk under Windows because Windows read all file names as upper case. We wanted case insensitivity so regardless of how a brain-dead operating system messed with characters, the file could still be parsed. The spec says use lower case names so we wouldn't have the situation Paul describes, where two different files differ only in their case, making them OS-dependent. In my opinion, all file names should be treated as if they were all lower case, regardless of how they actually appear in the file system to the OS. Will Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Message-Id: <950303061654_73053.721_GHB63-2@CompuServe.COM> Subject: name casing Cc: Kellee Crisafulli , Will Hobbs To: Arpad Muranyi , Ron Neville <75123.3477@compuserve.com>, Bob Ross From: Paul Munsey <73053.721@compuserve.com> Date: 03 Mar 95 01:16:55 EST Received: by dub-img-2.compuserve.com (8.6.10/5.941228sam) id BAA14310; Fri, 3 Mar 1995 01:18:32 -0500 Received: from dub-img-2.compuserve.com by hermes.intel.com (5.65/10.0i); Fri, 3 Mar 95 02:41:25 -0800 Received: from hermes.intel.com by fmmail.fm.intel.com with smtp (Smail3.1.28.1 #2) id m0rkUla-000algC; Fri, 3 Mar 95 02:39 PST Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: Re: name casing Cc: kellee%nwlink.com_at_smtpgate@ccm.hf.intel.com, Will_Hobbs@ccm2.jf.intel.com To: 73053.721%compuserve.com_at_smtpgate@ccm.hf.intel.com, 75123.3477%compuserve.com_at_smtpgate@ccm.hf.intel.com, ibis@vhdl.org Message-Id: <950303082006_3@ccm.hf.intel.com> From: Arpad Muranyi Date: Fri, 3 Mar 95 08:20:06 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Fri, 3 Mar 95 08:20:06 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rka5I-000twpC; Fri, 3 Mar 95 08:20 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rka5I-000Uf4C; Fri, 3 Mar 95 08:20 PST Received: from ormail.intel.com ([134.134.192.3]) by vhdl.vhdl.org (4.1/SMI-4.1/ BARRNet) id AA25688; Fri, 3 Mar 95 08:25:29 PST Received: from VHDL.VHDL.ORG by aurora.intel.com (5.65/10.0i); Fri, 3 Mar 95 08: 58:38 -0800 Received: from aurora by ichips.intel.com (5.64+/10.0i); Fri, 3 Mar 95 08:59:09 -0800 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0rkah6-000twoC; Fri, 3 Mar 95 08:59 PST From Arpad_Muranyi@ccm.fm.intel.com Fri Mar 3 17:39:05 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07601; Fri, 3 Mar 95 17:39:05 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rkij4-000UeuC; Fri, 3 Mar 95 17:33 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rkij4-000twpC; Fri, 3 Mar 95 17:33 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Fri, 3 Mar 95 17:33:44 PST Date: Fri, 3 Mar 95 17:33:44 PST From: Arpad Muranyi Message-Id: <950303173344_3@ccm.hf.intel.com> To: kellee@nwlink.com, ibis@vhdl.org Subject: Re: Re name casing for IBIS files Text item: Kellee, What is being said here is that the parser should ignore the case to make it work regardless what the file name looks like. That is OK in terms of getting the parser to run, but since it is an IBIS spec. requirement to use all lower case file names, the parser should at least report an error message when it finds a not all lower case file name. Otherwise, it might go undetected... I would suggest an error message, but still run and don't abort. Arpad --------------------------------------------------------------------------- I believe solution number 2 from Paul, or the following statement from Will both reflect what I believe is the best solution: > All file names should be treated as if they were all lower case, > regardless of how they actually appear in the file system to the OS. In other words continue the requirement that the file name be lower case as written into the actual IBIS file. However IBISCHK2 should convert the input file name to all lower case. This way if the user creates a file on DOS and sends it to another operating system it will still work. As far as users mixing up files like foo.ibs and FOO.ibs, the spec requires lower case file names and the parser already enforces it. Therefore I believe this fixes the problem and is consistent with our current specification. Kellee Have a great day...Kellee Crisafulli, HyperLynx Inc. Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: Re name casing for IBIS files From: kellee@nwlink.com To: ibis@vhdl.org Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: Windows Eudora Version 2.0.3 Message-Id: <199503032135.AA01669@washington.nwlink.com> Date: Fri, 3 Mar 1995 13:35:41 -0800 Received: by washington.nwlink.com id AA01669 (5.67b/IDA-1.5 for ibis@vhdl.org); Fri, 3 Mar 1995 13:35:41 -0800 Received: from washington.nwlink.com (nwlink.com) by vhdl.vhdl.org (4.1/SMI-4.1/ BARRNet) id AA06020; Fri, 3 Mar 95 13:41:41 PST Received: from VHDL.VHDL.ORG by hermes.intel.com (5.65/10.0i); Fri, 3 Mar 95 13: 38:26 -0800 Received: from hermes.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0rkf3L-000twoC; Fri, 3 Mar 95 13:38 PST From bob@icx.com Fri Mar 3 20:44:06 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08615; Fri, 3 Mar 95 20:44:06 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 3 Mar 95 20:38 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Fri, 3 Mar 95 20:40 PST Message-Id: Date: Fri, 3 Mar 95 20:40 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: MORE ON NAME CASING To Kellee, Arpad, Will, and Committee In jumping into the "casing" issue, I may be missing something. I feel IBISCHK2 runs correctly as is. For reference, here are the portions of IBIS which refer to naming files: |============================================================================== | | General syntax rules and guidelines for ASCII IBIS files: | | 1) The content of the files is case sensitive, except for reserved | words and keywords. File names must be all lower case. | |============================================================================== | Keyword: [File name] | Required: Yes | Description: Specifies the name of the IBIS file, "filename.ibs". | Usage Rules: The file name must comply with normal DOS rules (8 char. max. | and no characters that are illegal in DOS). In addition, it | must be all lower case, and use the extension ".ibs". |------------------------------------------------------------------------------ [File name] ver2_1.ibs | While it was not intended that way, even if "file names" in 1) is interpreted to NOT include the ".ibs" extension, the Keyword Usage Rules clarify that the only allowable extension is ".ibs". Therefore, ALL characters in the "filename.ibs" MUST be lower case. Even in DOS systems, IBISCHK2 correctly detects any upper case violation in "filename.ibs" in the keyword [File Name]. It also correctly processes DOS uppercase "FILENAME.IBS" files without reporting an error. In UNIX systems, IBISCHK2 will CONTINUE the checking, even if the actual "FILEname.ibs" contains uppercase chararcters. An ERROR is reported, just as Arpad suggested. As Kelley previously reported, the checking DOES NOT CONTINUE with a mixed or uppercase EXTENSION ".IBS"; an ERROR is reported. While inconsistent, both actions are appropriate since any variation from ".ibs" or usage of any other extension is in violation of IBIS. Stopping at an extension violation prevents processing a non-IBIS file entered by mistake. To me, IBIS is clear regarding lower case filename requirements, and IBISCHK2 is taking all of the proper actions in rigid compliance with IBIS and also in dealing with the DOS situation where the actual files (names converted to upper case regardless of how they were entered) are processed without error. IBISCHK2 should NOT automatically change any file name, and an ERROR should be reported for any mixed case filename and extension. The point that I may be missing is with respect to a Windows interface. If a properly formatted lower case file name is presented with uppercase only characters, then I would think that the DOS rules should be applied. The risk is that there may ambiguity if any mixed case variations of the same name exist. The user should take care that this does not happen, since I think that IBISCHK2 has to assume the actual filename provided is correct if used with a case-converting interface. Bob Ross, Interconnectix, Inc. From bob@icx.com Sat Mar 4 13:32:59 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA17642; Sat, 4 Mar 95 13:32:59 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Sat, 4 Mar 95 13:27 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Sat, 4 Mar 95 13:29 PST Message-Id: Date: Sat, 4 Mar 95 13:29 PST From: bob@icx.com ( Bob Ross) To: 75053.721@compuserve.com, 75123.3477@compuserve.com, ibis@vhdl.org Subject: TEST MATRIX UPDATE Hello Fellow IBISans, Will and Paul and Ron: Pin Mapping problem has been checked as fixed. The detection of less than two entries in the Waveform table is fixed and parser correctly tests the "NA" rules for "min" and "max" columns of Waveform tables. So, aside from the Package Model tests which have not been done, all NOs are now yes. Congratulations! ... However, a new problem cropped up that did not exist in ibischk2b and ibischk2c is that "NA" in the typical column is now flagged as an ERROR. in Waveform tables. (It still works properly for VI tables.) "NA" can exist in the typical column, but not at the beginning or end. So a new "NO" now exists as the last test in the table below. Bob Ross, Interconnectix, Inc. A TEST MATRIX FOR IBIS VERSION 2d DATE: 10/31/94, 12/2/94, 1/26/95, 3/4/95 SPECIFICATION TESTED PASS Comments/who tested --------------------------------------+-----+-----------------------------+ Test that the parser only | | | accepts 1.0, 1.1, 2.0, 2.1 as | | | valid arguments to the [IBIS Ver] | yes | Stephen Peters | keyword. | | | | | | --------------------------------------+-----+-----------------------------+ Scaling Factors: | | | | | | Test that the parser recognizes | | | "T", "G" and "f" as valid scaling | yes | No indication either way | factors. | | Bob Ross - this is proper | | | operation | Test that the parser does not | | | recognize "t", "g" and "F" as | yes | No indication either way | Valid scaling factors. | | Bob Ross - proper operation | | | | --------------------------------------+-----+-----------------------------+ Keywords rules: | | | | | | Test that the parser recognizes | | | the [GND clamp] and [PWR clamp] | yes | Stephen Peters | keywords without the underscore. | | | Test Underscore rule for 3-word | yes | Bob Ross | Keyoreds - all 4 cases. | | | | | | Test that the parser issues an | | | error if a keyword does not begin | yes | Stephen Peters | in column 1. | | | | | | Test case insensitivity of all | | | keywords, reserved words and | yes | Pin mapping keyword does not| sub-parameters | | recognize "power" and "gnd" | | | Bob Ross - OK, should be | | | "pulldown_ref", "pullup_ref,| | | "gnd_clamp_ref", and | | | "power_clamp_ref" | | | | --------------------------------------+-----+-----------------------------+ Comments and Notes: | | | | | | Test that the parser does not | | | accept "+" and "-" as valid | yes | Stephen Peters | comment characters. | | | | | | Test that the parser recognizes | yes | Stephen Peters | the [Copyright] keyword. | | | | | | | | | --------------------------------------+-----+-----------------------------+ Component keyword related: | | | | | | Test that the parser issues an | | | error if the [Component] keyword | yes | Stephen Peters | has no component name after it. | | | | | | Test that the parser issues a warning | | | if the component name contains blanks | yes | Stephen Peters | | | | Test the component name length | | | rules: | | | parser accepts name < 40 characters | yes | Stephen Peters | parser accepts name = 40 characters | yes | " | parser fails if name > 40 characters | yes | " | | | | Test that the parser issues an | | | error if the [Manufacture] keyword | yes | Stephen Peters | has no Manufactures name after it. | | | | | | Test the Manufactures name length | | | rules: | | | parser accepts name < 40 characters | yes | Stephen Peters | parser accepts name = 40 characters | yes | Stephen Peters | parser fails if name > 40 characters | yes | Stephen Peters | | | | Test that an .ibs file can contain | yes | Bob Ross | more than one [Component] keyword | | | and component description. | | | | | | --------------------------------------+-----+-----------------------------+ Pin keyword related: | | | | | | Test that the parser recognizes | yes | Stephen Peters | the [Pin] keyword. | | | | | | Test that the parser issues a | | | error when every model_name does | yes | Bob Ross | not have a corresponding model | | (I don't see the problem) | defined. | | | | | | Test the "3 column or 6 column" | | | rule. | yes | Stephen Peters | | | | Test that the parser issues an error | | | when non-numeric data is in the pin | yes | Stephen Peters | data columns | | | --------------------------------------+-----+-----------------------------+ Package Model related: | | | | | | Test that the parser recognizes | yes | Stephen Peters | the [Package Model] keyword. | | | | | | Test the package model name length | | | rules | | | parser accepts name < 40 characters | no | Name is taken as a DOS file | parser accepts name = 40 characters | no | name and not as argument to | parser fails if name > 40 characters | no | the [Define Package Model] | | | keyword | Verify that the parser issues an | | | error if it cannot find: | | | | | | 1. A [Define Package Model] keyword | | | that has the same argument as the | | | [Package Model] keyword or | | | | | | 2. An external .pkg file that has | | | a [Define Package Model] keyword | | | with has the same argument as the | | | [Package Model] keyword. | | | | | | Test that the parser recognizes all | | | keywords in the package model | | | description: | | | [Define Package Model] | | | [Manufacturer] | | | [OEM] | | | [Description] | | | [Number of Pins] | | | [Pin Numbers] | | | [Model Data] | | | [Resistance Matrix] | | | [Inductance Matrix] | | | [Capacitance Matrix] | | | [Bandwidth] | | | [Row] | | | [End Model Data] | | | [End Package Data] | | | | | | --------------------------------------+-----+-----------------------------+ Pin Mapping keyword related: | | | | | | Test that the parser recognizes | yes | Stephen Peters | the [Pin Mapping] keyword. | | | | | | Test that the parser issues an | | | error if every pin listed in the | yes | Bob Ross - fixed | [Pin] keyword does not have an | | | entry in the [Pin Mapping] table | | | | | | Test the "3 column or 5 column" | yes | Stephen Peters | rule. | | | | | | Test that NC is a valid entry | | | in a column. | yes | Stephen Peters | | | | Test that each unique entry label | | | must connect to at least one pin | | | whose model name is POWER or GND | yes | Stephen Peters | | | | Test that NA is NOT a valid | | | column entry | yes | Bob Ross | | | | --------------------------------------+-----+-----------------------------+ Diff Pin keyword related: | | | | | | Test that the parser recognizes | yes | Bob Ross | the [Diff Pin] keyword. | | | | | | Test that the parser recognizes | yes | Bob Ross | the 5 associated sub-parameters | | | | | | Test the "4 column or 6 column" | yes | Bob Ross | rule. | | | | | | Test that NC is NOT a valid | yes | Bob Ross | column entry. | | | | | | Test that NA is a valid column | yes | Bob Ross | entry. | | | | | | Reports error for duplicate pin | yes | Bob Ross | numbers. | | | | | | --------------------------------------+-----+-----------------------------+ [Model] keyword: | | | | | | Test that the parser recognizes | yes | Bob Ross | the [Model] keyword. | | | | | | Test that the parser recognizes | | | each Model_type: | | | Input | yes | Bob Ross | Output | yes | | I/O | yes | | 3-state | yes | | Open_drain | yes | | I/O_open_drain | yes | | Open_sink | yes | | I/O_open_sink | yes | | Open_source | yes | | I/O_open_source | yes | | Input_ECL | yes | | Output_ECL | yes | | I/O_ECL | yes | | Terminator | yes | | | | | Test that the parser issues | | | a warning if an input type model | yes | Stephen Peters | does not have Vinh or Vinl defined. | | | For All I/O_* cases. | yes | Bob Ross | | | | | | | Test that the parser issues an | | | error if the Model_type or C_comp | yes | Stephen Peters | sub-parameters are missing. | | | | | | Test that the parser accepts a | | | [Model] description with only the | | | Model_type and C_comp sub-params | yes | Stephen Peters | defined. | | | | | | Test that the parser allows NA in | | | the min and max columns only of the | yes | Stephen Peters | C_Comp sub-parameter. | | | | | | Test that the parser allows only | | | Non-inverting and Inverting as | yes | Stephen Peters | choices for the Polarity sub-param | | | | | | Test that the parser allows only | | | Active-High and Active-Low as | yes | Stephen Peters | choices for the Enable sub-param | | | | | | Test that the parser recognizes | | | the Vmeas, Cref, Rref and Vref | yes | Stephen Peters | sub-parameters. | | | | | | --------------------------------------+-----+-----------------------------+ Temperature keyword related: | | | | | | Test that the parser recognizes | yes | Stephen Peters | the [Temperature Range] keyword | | | | | | --------------------------------------+-----+-----------------------------+ Power supply rail related: | | | | | | Test that the parser recognizes | | | the supply rail keywords | | | [Voltage Range] | yes | Stephen Peters | [Pullup Reference] | " | | [Pulldown Reference] | " | | [POWER Clamp Reference] | " | | [GND Clamp Reference] | " | | | | | Test that the parser issues an | | | error if the [Voltage Range] | | | keyword is absent and all four of | | | the other supply rail keywords are | yes | Stephen Peters | NOT present. | | | | | | --------------------------------------+-----+-----------------------------+ I/V table related: | | | | | | Test that the parser recognizes | | | the [Pullup], [Pulldown], [GND | yes | Stephen Peters | Clamp] and [Power Clamp] keywords. | | | | | | Test that the parser issues an | yes | Bob Ross | error if all three columns are | | | not included | | | | | | Test that NA is accepted in the | yes | Bob Ross | min and max columns. | | | | | | Test that the parser issues an | yes | Bob Ross | error if a column contains over | | | 100 points. | | | | | | Test that the parser issues an | | | error if a table contains less | yes | Stephen Peters | than two points. | | | | | | Test that the parser issues a | yes | Bob Ross | warning if non-monotonic data | | | is found. | | | Test for One Warning per Column | yes | Bob Ross | | | | --------------------------------------+-----+-----------------------------+ Terminator related: | | | | | | Test that the parser recognizes | yes | Bob Ross | the [Rgnd], [Rpower], [Rac] and | | | [Cac] keywords. | | | | | | Test if [Rac], then [Cac] req'd. | yes | Bob Ross | | | | Test if [Cac], then [Rac] req'd. | yes | Bob Ross | | | | Test if parser issues an error with | | | above keywords AND Model_type is NOT | yes | Bob Ross | Terminator. | | | | | | Test that parser DOES NOT issue an | yes | Bob Ross | error if above models are NOT | | | defined. (Clamps or no components | | | can also be "Terminators") | | | | | | Test that the parser issues an | yes | Bob Ross | error if all three columns are | | | not included | | | | | | Test that NA is accepted in the | yes | Bob Ross | min and max columns. | | | | | | --------------------------------------+-----+-----------------------------+ Ramp keyword related: | | | | | | Test that the parser recognizes | | | the [Ramp] keyword and the | yes | Stephen Peters | dv/dt_r and dv/dt_f sub-parameters. | | | | | | Test that the parser recognizes | yes | Stephen Peters | the R_load sub-parameter. | | | | | | Test that the R_load sub-parameter | yes | Stephen Peters | is optional. | | | | | | --------------------------------------+-----+-----------------------------+ Waveform Related: | | | | | | Test that the parser recognizes | | | the [Rising Waveform] and [Falling | yes | Bob Ross | Waveform] keywords. | | | | | | Test that the parser recognizes | | | the sub-parameters: | | | R_fixture | yes | Bob Ross | V_fixture | yes | | V_fixture_max | yes | | V_fixture_min | yes | | C_fixture | yes | | L_fixture | yes | | R_dut | yes | | L_dut | yes | | C_dut | yes | | | | | Test that the parser issues an | | | error if the R_fixture and | yes | Bob Ross | V_fixture sub-parameters are not | | | present. | | | | | | Test that the parser issues an | | | error if a column contains over | yes | Bob Ross | 100 points. | | | | | | Test that the parser issues an | | | error if a table contains less | yes | Bob Ross | than two points. | | | | | | Test NA permitted in typical column | NO | Bob Ross | --------------------------------------+-----+-----------------------------+ From kellee@nwlink.com Sun Mar 5 15:35:23 1995 Return-Path: Received: from washington.nwlink.com (nwlink.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA29265; Sun, 5 Mar 95 15:35:23 PST Received: by washington.nwlink.com id AA06298 (5.67b/IDA-1.5 for ibis@vhdl.org); Sun, 5 Mar 1995 15:29:22 -0800 Date: Sun, 5 Mar 1995 15:29:22 -0800 Message-Id: <199503052329.AA06298@washington.nwlink.com> X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis@vhdl.org From: kellee@nwlink.com Subject: Reply to Bob Ross, MORE ON NAME CASING >Bob stated: >In jumping into the "casing" issue, I may be missing something. I feel >IBISCHK2 runs correctly as is. >Even in DOS systems, IBISCHK2 correctly detects any upper case violation >in "filename.ibs" in the keyword [File Name]. It also correctly processes >DOS uppercase "FILENAME.IBS" files without reporting an error. Hi Bob, You are correct in that the parser does correctly check file names in the file. However this is not the issue at all. The problem is that DOS seems to store the characters as upper case internally. It seems to usually pass them as lower case, thus they compare usually. However if the actual file is transfered from a DOS system to say an NT system or a Windows 95 system or probably a UNIX system say over a modem. The file name is transfered as upper case. Then the file system can pass it to the program as case sensitive. Here is where the problem occurs. So unless we don't care about running on Windows 95, Windows NT, and we don't care if we can check IBIS files created on a DOS machine and uploaded to a UNIX machine, then WE BETTER FIX IT. The bottom line I believe is: 1) The parser already checks the file name recorded in the file properly (I think). 2) The parser checks the actual file name as stored on the operating system as case sensitive. If the file is developed on a DOS or Windows 3.1 platform using DOS it will have an upper case name. There is nothing anyone can do about it. There is no practical way to give it a lower case name. Just look a the file names by doing a 'dir'. Because of this we must do case insensitive file name checking for the file name given to the IBIS check program to check. The file name actually store in the IBIS file can be lower case and it can be checked for case sensitivity. Have a great day...Kellee Crisafulli, HyperLynx Inc. From KARL_KACHIGAN@HP5300.desk.hp.com Mon Mar 6 15:03:03 1995 Return-Path: Received: from hp.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA12395; Mon, 6 Mar 95 15:03:03 PST Received: from opnmail4.corp.hp.com by hp.com with ESMTP (1.37.109.15/15.5+ECS 3.3) id AA108750670; Mon, 6 Mar 1995 14:57:51 -0800 Received: from by opnmail4.corp.hp.com with SMTP (1.37.109.15/15.5+ECS 3.4 Openmail) id AA231410670; Mon, 6 Mar 1995 14:57:50 -0800 From: KARL_KACHIGAN@HP5300.desk.hp.com X-Openmail-Hops: 2 Date: Mon, 6 Mar 95 14:23:00 -0800 Message-Id: Subject: IBIS file question Sender: KARL_KACHIGAN%HP5300.desk.hp.com@opnmail4.corp.hp.com To: ibis@vhdl.org Hello IBISians, I am looking for a spec clarification. The IBIS spec allows for more than one component to be a part of an IBIS file. But is it likely that anyone would implement such an approach? Regards, Karl Kachigan HP EEsof Division From bob@icx.com Mon Mar 6 15:59:14 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA12710; Mon, 6 Mar 95 15:59:14 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 6 Mar 95 15:51 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 6 Mar 95 15:53 PST Message-Id: Date: Mon, 6 Mar 95 15:53 PST From: bob@icx.com ( Bob Ross) To: KARL_KACHIGAN@HP5300.desk.hp.com, ibis@vhdl.org Subject: Re: IBIS file question Karl: The Specification allows multiple components per *.ibs file. This is actually very practical. As an extreme case, we typically concatenate many Components and Models into ONE very large IBIS design file for a particular design. This save steps in loading ALL of the Components and keeps things together. This large file contains components of all of the technologies in the design and may be composed partially by cutting and pasting from other files. Even for a particular component there may be several strengths of a particular group of outputs based on some control pin. Combinations of such variations can be designated by Component name variations and might reside in the same IBIS file for convenient grouping. For posting of components, you will most likely see one file per Component. However, eventually you may see many similar technology Components within one IBIS file as a convenient grouping for a particular manufacturer (e.g., the complete 74FXX series components). So IBIS does allow multiple components within a file. Grouping many components into one file is commonly done using IBIS and also commonly done in other formats as well. Bob Ross, Interconnectix, Inc. > Hello IBISians, > I am looking for a spec clarification. > The IBIS spec allows for more than one component to be a part of an IBIS > file. But is it likely that anyone would implement such an approach? > Regards, > Karl Kachigan > HP EEsof Division From kellee@nwlink.com Mon Mar 6 19:54:27 1995 Return-Path: Received: from washington.nwlink.com (nwlink.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA14119; Mon, 6 Mar 95 19:54:27 PST Received: by washington.nwlink.com id AA19822 (5.67b/IDA-1.5 for ibis@vhdl.org); Mon, 6 Mar 1995 19:48:26 -0800 Date: Mon, 6 Mar 1995 19:48:26 -0800 Message-Id: <199503070348.AA19822@washington.nwlink.com> X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis@vhdl.org From: kellee@nwlink.com Subject: Reply to Karl Kachigan >I am looking for a spec clarification. > >The IBIS spec allows for more than one component to be a part of an IBIS >file. But is it likely that anyone would implement such an approach? >Karl Kachigan >HP EEsof Division > Hi Karl, HyperLynx has several IBIS files with multiple devices. Kellee Have a great day...Kellee Crisafulli, HyperLynx Inc. From kellee@nwlink.com Wed Mar 8 12:46:58 1995 Return-Path: Received: from washington.nwlink.com (nwlink.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA06456; Wed, 8 Mar 95 12:46:58 PST Received: by washington.nwlink.com id AA08916 (5.67b/IDA-1.5 for ibis@vhdl.org); Wed, 8 Mar 1995 12:40:58 -0800 Date: Wed, 8 Mar 1995 12:40:58 -0800 Message-Id: <199503082040.AA08916@washington.nwlink.com> X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis@vhdl.org From: kellee@nwlink.com Subject: Parser, Case, Resolution From: Kellee Crisafulli, HyperLynx Greetings, Bob Ross and I had a long conversation today about the case sensitivity issue with the parser and file names. Bob was initially against allowing upper case file names from the operating system to pass through the parser. The final out come of our conversation was the following: 1) The file name must remain lower case in the file itself (per the specification). 2) Either upper, lower or mixed upper/lower file names should be accepted on the command line. 3) If the file name from the command line is not all lower case than the parser must post a WARNING (accept versions compiled for DOS). The warning should be state that the file name should be lower case. 4) The comparision of the command line file name to the file name in the IBIS file must be case INSENSITIVE. 4) The file should be parsed and checked no matter what the case. For example if the user types in a lower case name and the file name on the system is upper case because it came from a DOS enviorment the file should still be parsed. If there are multiple file names x1.ibs, X1.IBS, x1.IBS, x1.Ibs then the file name which matches exactly what the user typed should be checked if present. If not then it is suffient to check only for a lower case name. Is this acceptable to everyone? Have a great day...Kellee Crisafulli, HyperLynx Inc. From blooms@ECE.ORST.EDU Wed Mar 8 13:22:19 1995 Return-Path: Received: from ECE.ORST.EDU by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA06660; Wed, 8 Mar 95 13:22:19 PST Received: from holmes.ECE.ORST.EDU by ECE.ORST.EDU with SMTP (1.38.193.4/16.2) id AA12713; Wed, 8 Mar 1995 13:17:00 -0800 Received: from localhost by holmes.ece.orst.edu (1.37.109.15/HP-Client) id AA273257419; Wed, 8 Mar 1995 13:16:59 -0800 Message-Id: <199503082116.AA273257419@holmes.ece.orst.edu> To: kellee@nwlink.com Cc: ibis@vhdl.org Subject: Re: Parser, Case, Resolution In-Reply-To: Your message of "Wed, 08 Mar 95 12:40:58 PST." <199503082040.AA08916@washington.nwlink.com> Date: Wed, 08 Mar 95 13:16:58 PST From: Scott Aron Bloom > 3) If the file name from the command line is not all lower case than the > parser must > post a WARNING (accept versions compiled for DOS). The warning should > be state that Does this mean there is no warning on DOS systems?? --------- Scott Interconnectix, Inc From bob@icx.com Wed Mar 8 17:58:54 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08454; Wed, 8 Mar 95 17:58:54 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 8 Mar 95 17:53 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 8 Mar 95 17:55 PST Message-Id: Date: Wed, 8 Mar 95 17:55 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org Subject: TEST MATRIX PACKAGE UPDATE Cc: 75053.721@compuserve.com, 75123.3477@compuserve.com Hello Fellow IBISans, Will and Paul and Ron: Here is another test matrix update. I exercized the PACKAGE portion at a fundamental (vs. in depth) level and it basically checks out OK. However, there are a few problems, which may need to be addressed. (1) When the [Number of Pins] argument is missing, get Program Bug, and program ABORTS - some internal indexing error message is given and row.c:180:assertion failed. (2) For "Banded_matrix", the [Bandwidth] keyword is required. No message is given when [Bandwidth] is not included. (3) For "Sparse_matrix" choices, need to be able to accept alphanumeric indicies. This is correctly done with [Pin Numbers] entries and [Row] number entries. In general, ibischk2 does catch the critical syntax violations, and a properly formatted .ibs and .pkg will correctly pass (except PGA's using Sparse_matrix per (3) above). There are a number of data-dependent details that are not fully checked. They fall into these categories: (a) Matching [Row] entries with [Pin Numbers] entries. (b) Particular [Row] data format characteristics. I believe fixing problems (1)-(3) will be sufficient for releasing the PACKAGE portion of ibischk2 at this time. It will be very useful at that level. It will provide excellent syntax checking, but may not check all data-dependent entry combinations that could be inferred from the specification. Since a lot of these combinations may not have been stated as "requirements", Paul and Ron have done an excellent job in their implementation without any tracking and feedback from us on the PACKAGE portions. For example, there is no statement that Sparse_matrix "Indicies" can be alphanumeric, but rather the statement: "When alphanumeric pin names are used, special care must be taken to ensure that the ordering defined in the [Pin Numbers] section is observed." In general, the full testing of the PACKAGE portion is a big project because of the potential detail and resulting clarification iterations on the Standard itself. This could be ongoing, eventually converging to a Version 3.0 enhancement and clarification revision based on testing and problems encountered in actual usage. Bob Ross, Interconnectix, Inc. A TEST MATRIX FOR IBIS VERSION 2d DATE: 10/31/94, 12/2/94, 1/26/95, 3/4/95, 3/8/95 SPECIFICATION TESTED PASS Comments/who tested --------------------------------------+-----+-----------------------------+ Test that the parser only | | | accepts 1.0, 1.1, 2.0, 2.1 as | | | valid arguments to the [IBIS Ver] | yes | Stephen Peters | keyword. | | | | | | --------------------------------------+-----+-----------------------------+ Scaling Factors: | | | | | | Test that the parser recognizes | | | "T", "G" and "f" as valid scaling | yes | No indication either way | factors. | | Bob Ross - this is proper | | | operation | Test that the parser does not | | | recognize "t", "g" and "F" as | yes | No indication either way | Valid scaling factors. | | Bob Ross - proper operation | | | | --------------------------------------+-----+-----------------------------+ Keywords rules: | | | | | | Test that the parser recognizes | | | the [GND clamp] and [PWR clamp] | yes | Stephen Peters | keywords without the underscore. | | | Test Underscore rule for 3-word | yes | Bob Ross | Keyoreds - all 4 cases. | | | | | | Test that the parser issues an | | | error if a keyword does not begin | yes | Stephen Peters | in column 1. | | | | | | Test case insensitivity of all | | | keywords, reserved words and | yes | Pin mapping keyword does not| sub-parameters | | recognize "power" and "gnd" | | | Bob Ross - OK, should be | | | "pulldown_ref", "pullup_ref,| | | "gnd_clamp_ref", and | | | "power_clamp_ref" | | | | --------------------------------------+-----+-----------------------------+ Comments and Notes: | | | | | | Test that the parser does not | | | accept "+" and "-" as valid | yes | Stephen Peters | comment characters. | | | | | | Test that the parser recognizes | yes | Stephen Peters | the [Copyright] keyword. | | | | | | | | | --------------------------------------+-----+-----------------------------+ Component keyword related: | | | | | | Test that the parser issues an | | | error if the [Component] keyword | yes | Stephen Peters | has no component name after it. | | | | | | Test that the parser issues a warning | | | if the component name contains blanks | yes | Stephen Peters | | | | Test the component name length | | | rules: | | | parser accepts name < 40 characters | yes | Stephen Peters | parser accepts name = 40 characters | yes | " | parser fails if name > 40 characters | yes | " | | | | Test that the parser issues an | | | error if the [Manufacture] keyword | yes | Stephen Peters | has no Manufactures name after it. | | | | | | Test the Manufactures name length | | | rules: | | | parser accepts name < 40 characters | yes | Stephen Peters | parser accepts name = 40 characters | yes | Stephen Peters | parser fails if name > 40 characters | yes | Stephen Peters | | | | Test that an .ibs file can contain | yes | Bob Ross | more than one [Component] keyword | | | and component description. | | | | | | --------------------------------------+-----+-----------------------------+ Pin keyword related: | | | | | | Test that the parser recognizes | yes | Stephen Peters | the [Pin] keyword. | | | | | | Test that the parser issues a | | | error when every model_name does | yes | Bob Ross | not have a corresponding model | | (I don't see the problem) | defined. | | | | | | Test the "3 column or 6 column" | | | rule. | yes | Stephen Peters | | | | Test that the parser issues an error | | | when non-numeric data is in the pin | yes | Stephen Peters | data columns | | | --------------------------------------+-----+-----------------------------+ Package Model related: | | | | | | Test that the parser recognizes | yes | Stephen Peters | the [Package Model] keyword. | | | | | | Test the package model name length | yes | Bob Ross | rules | | Fixed: | parser accepts name < 40 characters | yes | Name is taken as a DOS file | parser accepts name = 40 characters | yes | name and not as argument to | parser fails if name > 40 characters | yes | the [Define Package Model] | | | keyword | Verify that the parser issues an | | | error if it cannot find: | | | | | | 1. A [Define Package Model] keyword | | | that has the same argument as the | yes | Bob Ross | [Package Model] keyword or | | | | | | 2. An external .pkg file that has | yes | Bob Ross | a [Define Package Model] keyword | | | with has the same argument as the | | | [Package Model] keyword. | | | | | | 3. Test that the parser recognizes | | | all keywords in the package model | | | description and operation below: | | | (1) Error if Missing | | | (2) Error if Duplicate | | | (3) Error if Wrong Argument | | | [Define Package Model] 1,2,3 | yes | Bob Ross | [Manufacturer] 1,2,3 | yes | | [OEM] 1,2,3 | yes | | [Description] 1,2,3 | yes | | [Number of Pins] 1,2,3-fails | NO | Should be fixed - "Abnormal| | | program termination" with | | | no argument | [Pin Numbers] 1,2,3 | yes | | [Model Data] 1,2 | yes | | [Resistance Matrix] 2,3 | yes | | [Inductance Matrix] 1,2,3 | yes | | [Capacitance Matrix] 1,2,3 | yes | | [Bandwidth] 1-fails,2,3 | NO | (problems below) | [Row] 1,2,3-fails | NO | (problems below) | [End Model Data] 1,2 | yes | Bob Ross | [End Package Data] 1,2 | yes | " | | | | | | | 4. Full_matrix Tests | | Bob Ross | [Bandwidth] error test | yes | | [Row] number entry (match pin) | NO | | [Row] number entry (repeated) | NO | | [Row] number entry (all rows entered) | NO | | [Row] format (upper triange matrix) | NO | | [Row] format (excessive data) | yes | | [Row] format (missing data) | NO | | | | | 5. Banded_matrix Tests | | Bob Ross | [Bandwidth] req'd test | NO | Should be fixed | [Bandwidth] argument req'd | yes | | [Bandwidth] argument value | yes | | [Row] number entry (match pin) | NO | | [Row] number entry (repeated) | NO | | [Row] format (excessive data) | yes | | [Row] format (missing data) | NO | | | | | 6. Sparse_matrix Tests | | Bob Ross | [Bandwidth] error test | yes | | [Row] number entry (match pin) | NO | | [Row] number entry (repeated) | NO | | [Row] index match | yes | | [Row] index (alpha string) | NO | Should be fixed | [Row] format (excessive data) | NO | | [Row] format (missing data) | NO | | | | | --------------------------------------+-----+-----------------------------+ Pin Mapping keyword related: | | | | | | Test that the parser recognizes | yes | Stephen Peters | the [Pin Mapping] keyword. | | | | | | Test that the parser issues an | | | error if every pin listed in the | yes | Bob Ross - fixed | [Pin] keyword does not have an | | | entry in the [Pin Mapping] table | | | | | | Test the "3 column or 5 column" | yes | Stephen Peters | rule. | | | | | | Test that NC is a valid entry | | | in a column. | yes | Stephen Peters | | | | Test that each unique entry label | | | must connect to at least one pin | | | whose model name is POWER or GND | yes | Stephen Peters | | | | Test that NA is NOT a valid | | | column entry | yes | Bob Ross | | | | --------------------------------------+-----+-----------------------------+ Diff Pin keyword related: | | | | | | Test that the parser recognizes | yes | Bob Ross | the [Diff Pin] keyword. | | | | | | Test that the parser recognizes | yes | Bob Ross | the 5 associated sub-parameters | | | | | | Test the "4 column or 6 column" | yes | Bob Ross | rule. | | | | | | Test that NC is NOT a valid | yes | Bob Ross | column entry. | | | | | | Test that NA is a valid column | yes | Bob Ross | entry. | | | | | | Reports error for duplicate pin | yes | Bob Ross | numbers. | | | | | | --------------------------------------+-----+-----------------------------+ [Model] keyword: | | | | | | Test that the parser recognizes | yes | Bob Ross | the [Model] keyword. | | | | | | Test that the parser recognizes | | | each Model_type: | | | Input | yes | Bob Ross | Output | yes | | I/O | yes | | 3-state | yes | | Open_drain | yes | | I/O_open_drain | yes | | Open_sink | yes | | I/O_open_sink | yes | | Open_source | yes | | I/O_open_source | yes | | Input_ECL | yes | | Output_ECL | yes | | I/O_ECL | yes | | Terminator | yes | | | | | Test that the parser issues | | | a warning if an input type model | yes | Stephen Peters | does not have Vinh or Vinl defined. | | | For All I/O_* cases. | yes | Bob Ross | | | | | | | Test that the parser issues an | | | error if the Model_type or C_comp | yes | Stephen Peters | sub-parameters are missing. | | | | | | Test that the parser accepts a | | | [Model] description with only the | | | Model_type and C_comp sub-params | yes | Stephen Peters | defined. | | | | | | Test that the parser allows NA in | | | the min and max columns only of the | yes | Stephen Peters | C_Comp sub-parameter. | | | | | | Test that the parser allows only | | | Non-inverting and Inverting as | yes | Stephen Peters | choices for the Polarity sub-param | | | | | | Test that the parser allows only | | | Active-High and Active-Low as | yes | Stephen Peters | choices for the Enable sub-param | | | | | | Test that the parser recognizes | | | the Vmeas, Cref, Rref and Vref | yes | Stephen Peters | sub-parameters. | | | | | | --------------------------------------+-----+-----------------------------+ Temperature keyword related: | | | | | | Test that the parser recognizes | yes | Stephen Peters | the [Temperature Range] keyword | | | | | | --------------------------------------+-----+-----------------------------+ Power supply rail related: | | | | | | Test that the parser recognizes | | | the supply rail keywords | | | [Voltage Range] | yes | Stephen Peters | [Pullup Reference] | " | | [Pulldown Reference] | " | | [POWER Clamp Reference] | " | | [GND Clamp Reference] | " | | | | | Test that the parser issues an | | | error if the [Voltage Range] | | | keyword is absent and all four of | | | the other supply rail keywords are | yes | Stephen Peters | NOT present. | | | | | | --------------------------------------+-----+-----------------------------+ I/V table related: | | | | | | Test that the parser recognizes | | | the [Pullup], [Pulldown], [GND | yes | Stephen Peters | Clamp] and [Power Clamp] keywords. | | | | | | Test that the parser issues an | yes | Bob Ross | error if all three columns are | | | not included | | | | | | Test that NA is accepted in the | yes | Bob Ross | min and max columns. | | | | | | Test that the parser issues an | yes | Bob Ross | error if a column contains over | | | 100 points. | | | | | | Test that the parser issues an | | | error if a table contains less | yes | Stephen Peters | than two points. | | | | | | Test that the parser issues a | yes | Bob Ross | warning if non-monotonic data | | | is found. | | | Test for One Warning per Column | yes | Bob Ross | | | | --------------------------------------+-----+-----------------------------+ Terminator related: | | | | | | Test that the parser recognizes | yes | Bob Ross | the [Rgnd], [Rpower], [Rac] and | | | [Cac] keywords. | | | | | | Test if [Rac], then [Cac] req'd. | yes | Bob Ross | | | | Test if [Cac], then [Rac] req'd. | yes | Bob Ross | | | | Test if parser issues an error with | | | above keywords AND Model_type is NOT | yes | Bob Ross | Terminator. | | | | | | Test that parser DOES NOT issue an | yes | Bob Ross | error if above models are NOT | | | defined. (Clamps or no components | | | can also be "Terminators") | | | | | | Test that the parser issues an | yes | Bob Ross | error if all three columns are | | | not included | | | | | | Test that NA is accepted in the | yes | Bob Ross | min and max columns. | | | | | | --------------------------------------+-----+-----------------------------+ Ramp keyword related: | | | | | | Test that the parser recognizes | | | the [Ramp] keyword and the | yes | Stephen Peters | dv/dt_r and dv/dt_f sub-parameters. | | | | | | Test that the parser recognizes | yes | Stephen Peters | the R_load sub-parameter. | | | | | | Test that the R_load sub-parameter | yes | Stephen Peters | is optional. | | | | | | --------------------------------------+-----+-----------------------------+ Waveform Related: | | | | | | Test that the parser recognizes | | | the [Rising Waveform] and [Falling | yes | Bob Ross | Waveform] keywords. | | | | | | Test that the parser recognizes | | | the sub-parameters: | | | R_fixture | yes | Bob Ross | V_fixture | yes | | V_fixture_max | yes | | V_fixture_min | yes | | C_fixture | yes | | L_fixture | yes | | R_dut | yes | | L_dut | yes | | C_dut | yes | | | | | Test that the parser issues an | | | error if the R_fixture and | yes | Bob Ross | V_fixture sub-parameters are not | | | present. | | | | | | Test that the parser issues an | | | error if a column contains over | yes | Bob Ross | 100 points. | | | | | | Test that the parser issues an | | | error if a table contains less | yes | Bob Ross | than two points. | | | | | | Test NA permitted in typical column | NO | Bob Ross | --------------------------------------+-----+-----------------------------+ From Will_Hobbs@ccm2.jf.intel.com Thu Mar 9 13:00:22 1995 Return-Path: Received: from chronos.synopsys.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19373; Thu, 9 Mar 95 13:00:22 PST Received: from ormail.intel.com by chronos.synopsys.com with SMTP id AA12126 (5.65c/IDA-1.4.4 for ); Thu, 9 Mar 1995 12:55:07 -0800 Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rmWKM-000Uo4C; Wed, 8 Mar 95 16:43 PST Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rmWKL-000twoC; Wed, 8 Mar 95 16:43 PST Received: by ccm.jf.intel.com (ccmgate 3.0) Wed, 8 Mar 95 16:43:41 PST Date: Wed, 8 Mar 95 16:43:41 PST From: Will Hobbs Message-Id: <950308164341_1@ccm.jf.intel.com> To: ibis@vhdl.org, ibis@ccm2.jf.intel.com Subject: model creator name, a suggestion IBIS folk, In the comments at the beginning of a file, there should be some way of tracking the file to the original engineer that created the file. I suggest we make it standard practice for the creator to "sign" his/her files in a comment. This doesn't require a keyword, and doesn't even necessarily have to point at a specific individual. But there should be a simple way for someone to come along later and figure out who to check with when there are problems. Just a suggestion for a standard practice to follow. Will Hobbs Intel Corp. From Arpad_Muranyi@ccm.fm.intel.com Thu Mar 9 13:00:44 1995 Return-Path: Received: from chronos.synopsys.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19378; Thu, 9 Mar 95 13:00:44 PST Received: from ormail.intel.com by chronos.synopsys.com with SMTP id AA12148 (5.65c/IDA-1.4.4 for ); Thu, 9 Mar 1995 12:55:29 -0800 Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rmUem-000UolC; Wed, 8 Mar 95 14:56 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rmUem-000twpC; Wed, 8 Mar 95 14:56 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Wed, 8 Mar 95 14:56:39 PST Date: Wed, 8 Mar 95 14:56:39 PST From: Arpad Muranyi Message-Id: <950308145639_15@ccm.hf.intel.com> To: kellee@nwlink.com, ibis@vhdl.org Subject: Re: Parser, Case, Resolution Text item: Kellee, Very good, I agree with the recommendation you and Bob came up with. In fact I thought I recommended the same thing in one of my EMAILs last week. I might not have stated it clearly enough, because I didn't get any responses to it. Another way of looking at this issue is that no other error message stops the parser from running. Why should this do that? Just give a message and keep running. However, I have a minor thing to pick on. I would issue an ERROR message and not just a warning, since it is a direct violation of the spec. To be forgiving to case-insensitive systems, I would put a statement in the error message that tells the user something like this: "IBIS file names must be all lower case. Please ignore this message if you are running in an operating system which does not allow case-sensitive file names." Of course, the parser would continue parsing which it currently does in the case of all other error messages. Arpad Muranyi Intel Corporation ______________________________ Reply Separator _________________________________ Subject: Parser, Case, Resolution Author: kellee@nwlink.com at Internet_Gateway Date: 3/8/95 12:45 PM From: Kellee Crisafulli, HyperLynx Greetings, Bob Ross and I had a long conversation today about the case sensitivity issue with the parser and file names. Bob was initially against allowing upper case file names from the operating system to pass through the parser. The final out come of our conversation was the following: 1) The file name must remain lower case in the file itself (per the specification). 2) Either upper, lower or mixed upper/lower file names should be accepted on the command line. 3) If the file name from the command line is not all lower case than the parser must post a WARNING (accept versions compiled for DOS). The warning should be state that the file name should be lower case. 4) The comparision of the command line file name to the file name in the IBIS file must be case INSENSITIVE. 4) The file should be parsed and checked no matter what the case. For example if the user types in a lower case name and the file name on the system is upper case because it came from a DOS enviorment the file should still be parsed. If there are multiple file names x1.ibs, X1.IBS, x1.IBS, x1.Ibs then the file name which matches exactly what the user typed should be checked if present. If not then it is suffient to check only for a lower case name. Is this acceptable to everyone? Have a great day...Kellee Crisafulli, HyperLynx Inc. Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: Parser, Case, Resolution From: kellee@nwlink.com To: ibis@vhdl.org Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: Windows Eudora Version 2.0.3 Message-Id: <199503082040.AA08916@washington.nwlink.com> Date: Wed, 8 Mar 1995 12:40:58 -0800 Received: by washington.nwlink.com id AA08916 (5.67b/IDA-1.5 for ibis@vhdl.org); Wed, 8 Mar 1995 12:40:58 -0800 Received: from washington.nwlink.com (nwlink.com) by vhdl.vhdl.org (4.1/SMI-4.1/ BARRNet) id AA06456; Wed, 8 Mar 95 12:46:58 PST Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Wed, 8 Mar 95 12: 45:50 -0800 Received: from hermes.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0rmScB-000twpC; Wed, 8 Mar 95 12:45 PST From huq@rockie.nsc.com Thu Mar 9 13:16:17 1995 Return-Path: Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19509; Thu, 9 Mar 95 13:16:17 PST Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA20555 for ibis@vhdl.org; Thu, 9 Mar 95 13:11:03 -0800 Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA00153 for ibis@vhdl.org; Thu, 9 Mar 95 13:11:01 -0800 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA13461; Thu, 9 Mar 95 13:11:36 PST Date: Thu, 9 Mar 95 13:11:36 PST From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9503092111.AA13461@rockie.nsc.com> To: ibis@vhdl.org, ibis@ccm2.jf.intel.com, Will_Hobbs@ccm2.jf.intel.com Subject: Re: model creator name, a suggestion Will, Good idea. We are doing that for models coming out from National. Regards, Syed. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Syed B. Huq Applications Engineer/Data Transmission Products National Semiconductor Tel:(408)721-4874; Fax:(408)721-4785 Internet:huq@rockie.nsc.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > From Will_Hobbs@ccm2.jf.intel.com Thu Mar 9 13:07:29 1995 > Date: Wed, 8 Mar 95 16:43:41 PST > From: Will Hobbs > To: ibis@vhdl.org, ibis@ccm2.jf.intel.com > Subject: model creator name, a suggestion > Content-Length: 554 > > IBIS folk, > > In the comments at the beginning of a file, there should be some way of > tracking the file to the original engineer that created the file. I suggest > we make it standard practice for the creator to "sign" his/her files in a > comment. This doesn't require a keyword, and doesn't even necessarily have > to point at a specific individual. But there should be a simple way for > someone to come along later and figure out who to check with when there are > problems. > > Just a suggestion for a standard practice to follow. > > Will Hobbs > Intel Corp. > From Will_Hobbs@ccm2.jf.intel.com Fri Mar 10 16:02:59 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA05918; Fri, 10 Mar 95 16:02:59 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rnEXj-000UivC; Fri, 10 Mar 95 15:56 PST Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rnEXi-000twuC; Fri, 10 Mar 95 15:56 PST Received: by ccm.jf.intel.com (ccmgate 3.0) Fri, 10 Mar 95 15:56:25 PST Date: Fri, 10 Mar 95 15:56:25 PST From: Will Hobbs Message-Id: <950310155625_6@ccm.jf.intel.com> To: Arpad_Muranyi@ccm.fm.intel.com, kellee@nwlink.com, ibis@vhdl.org Cc: 73053.721@compuserve.com Subject: Re[2]: Parser, Case, Resolution Text item: Arpad, I do not think we should act on this resolution without a meeting. It sounds like we have a solution, but I don't think we should have Ron and Paul implement until we discuss this among the licensees. If this can wait for resolution until next Friday, that should be our first topic. Is this OK with everyone? Will Hobbs Intel Corp. Kellee, Very good, I agree with the recommendation you and Bob came up with. In fact I thought I recommended the same thing in one of my EMAILs last week. I might not have stated it clearly enough, because I didn't get any responses to it. Another way of looking at this issue is that no other error message stops the parser from running. Why should this do that? Just give a message and keep running. However, I have a minor thing to pick on. I would issue an ERROR message and not just a warning, since it is a direct violation of the spec. To be forgiving to case-insensitive systems, I would put a statement in the error message that tells the user something like this: "IBIS file names must be all lower case. Please ignore this message if you are running in an operating system which does not allow case-sensitive file names." Of course, the parser would continue parsing which it currently does in the case of all other error messages. Arpad Muranyi Intel Corporation ______________________________ Reply Separator _________________________________ Subject: Parser, Case, Resolution Author: kellee@nwlink.com at Internet_Gateway Date: 3/8/95 12:45 PM From: Kellee Crisafulli, HyperLynx Greetings, Bob Ross and I had a long conversation today about the case sensitivity issue with the parser and file names. Bob was initially against allowing upper case file names from the operating system to pass through the parser. The final out come of our conversation was the following: 1) The file name must remain lower case in the file itself (per the specification). 2) Either upper, lower or mixed upper/lower file names should be accepted on the command line. 3) If the file name from the command line is not all lower case than the parser must post a WARNING (accept versions compiled for DOS). The warning should be state that the file name should be lower case. 4) The comparision of the command line file name to the file name in the IBIS file must be case INSENSITIVE. 4) The file should be parsed and checked no matter what the case. For example if the user types in a lower case name and the file name on the system is upper case because it came from a DOS enviorment the file should still be parsed. If there are multiple file names x1.ibs, X1.IBS, x1.IBS, x1.Ibs then the file name which matches exactly what the user typed should be checked if present. If not then it is suffient to check only for a lower case name. Is this acceptable to everyone? Have a great day...Kellee Crisafulli, HyperLynx Inc. Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: Parser, Case, Resolution From: kellee@nwlink.com To: ibis@vhdl.org Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: Windows Eudora Version 2.0.3 Message-Id: <199503082040.AA08916@washington.nwlink.com> Date: Wed, 8 Mar 1995 12:40:58 -0800 Received: by washington.nwlink.com id AA08916 (5.67b/IDA-1.5 for ibis@vhdl.org); Wed, 8 Mar 1995 12:40:58 -0800 Received: from washington.nwlink.com (nwlink.com) by vhdl.vhdl.org (4.1/SMI-4.1/ BARRNet) id AA06456; Wed, 8 Mar 95 12:46:58 PST Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Wed, 8 Mar 95 12: 45:50 -0800 Received: from hermes.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0rmScB-000twpC; Wed, 8 Mar 95 12:45 PST Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: Re: Parser, Case, Resolution To: kellee@nwlink.com, ibis@vhdl.org Message-Id: <950308145639_15@ccm.hf.intel.com> From: Arpad Muranyi Date: Wed, 8 Mar 95 14:56:39 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Wed, 8 Mar 95 14:56:39 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rmUem-000twpC; Wed, 8 Mar 95 14:56 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rmUem-000UolC; Wed, 8 Mar 95 14:56 PST Received: from ormail.intel.com by chronos.synopsys.com with SMTP id AA12148 (5.65c/IDA-1.4.4 for ); Thu, 9 Mar 1995 12:55:29 -0800 Received: from chronos.synopsys.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA19378; Thu, 9 Mar 95 13:00:44 PST Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Thu, 9 Mar 95 13: 22:17 -0800 Received: from hermes.intel.com by ichips.intel.com (5.64+/10.0i); Thu, 9 Mar 95 13:22:41 -0800 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0rmpfR-000twoC; Thu, 9 Mar 95 13:22 PST From huq@rockie.nsc.com Sun Mar 12 09:31:48 1995 Return-Path: Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA26311; Sun, 12 Mar 95 09:31:48 PST Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA20199 for ibis@vhdl.org; Sun, 12 Mar 95 09:26:32 -0800 Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA03724 for ibis@vhdl.org; Sun, 12 Mar 95 09:26:26 -0800 Received: from kural by rockie.nsc.com (4.1/SMI-4.1) id AA17286; Fri, 10 Mar 95 13:50:48 PST Date: Fri, 10 Mar 95 13:50:48 PST From: huq@rockie.nsc.com (Syed Huq) Message-Id: <9503102150.AA17286@rockie.nsc.com> To: ibis@vhdl.org Subject: IBIS and Pinnacle Hi IBISgurus, Within our corporation, there is a push going on for device documentation (ex.datasheets)using SGML(Standard Generalized Markup Language) under what is know as PCIS(Pinnacles Component Information Standard). The question came up whether IBIS and Pinnacle can work together to link the two programs somehow. This will give customers a SGML formatted copy of a datasheet along with an IBIS models which can both be available electronically. Pinnacle is moving more towards providing datasheets thru SGML formatted databooks while IBISis providing models in a standard software parsable format. I remember meeting a member of the Pinnacle group in our last years DAC IBIS summit. Has anything happened since or can anyone comment on this issue. Do you guys see this being feasible ? Regards, Syed. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Syed B. Huq Applications Engineer/Data Transmission Products National Semiconductor Tel:(408)721-4874; Fax:(408)721-4785 Internet:huq@rockie.nsc.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From cer@Cadence.COM Mon Mar 13 05:45:20 1995 Return-Path: Received: from mailgate.Cadence.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA06591; Mon, 13 Mar 95 05:45:20 PST Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id FAA17844 for ; Mon, 13 Mar 1995 05:40:04 -0800 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via smap (V1.0mjr) id sma017799; Mon Mar 13 05:39:52 1995 Received: from oahu by cadence.Cadence.COM (5.61/3.14) id AA00339; Mon, 13 Mar 95 05:39:03 -0800 Received: by oahu (5.65+/1.5) id AA18536; Mon, 13 Mar 95 08:39:48 -0500 Date: Mon, 13 Mar 95 08:39:48 -0500 From: cer@cadence.com (Chrisopher E. Reid) Message-Id: <9503131339.AA18536@oahu> To: ibis@vhdl.org Subject: HTML ibis documents Fellow Ibis'ers, If there is really interest in having an HTML version of IBIS data around then I suggest that the HTML version should be derived from the IBIS format automatically. We do not want the headaches of keeping two parallel data streams concurrent! There are two options: 1) Define a new format that results in an HTML document that is also easily parsed automatically, or as I suggested above 2) Write a program that automatically converts from the current IBIS format to an HTML document. I think option 2 is better since many people (such as us) already depend on the current Ibis format and would find it burdensome to change that format now. Chris Reid cer@cadence.com From Derrick_Duehren@ccm2.jf.intel.com Mon Mar 13 10:02:20 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08586; Mon, 13 Mar 95 10:02:20 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0roEMZ-000UokC; Mon, 13 Mar 95 09:57 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0roEMZ-000twoC; Mon, 13 Mar 95 09:57 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Mon, 13 Mar 95 09:57:03 PST Date: Mon, 13 Mar 95 09:57:03 PST From: Derrick Duehren Message-Id: <950313095703_2@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: Re: IBIS and Pinnacle I was involved in the early stages of the SGML/Pinnacle effort. Incorporating IBIS into the Pinnacle's SGML format should be pretty straightforward, but it'll take some ergs to write a conversion $cript. Derrick Duehren IBIS Open Forum Secretary (a volunteer position) Phone (503) 696-4299, Fax (503) 696-4904 Derrick_Duehren@ccm.jf.intel.com 2111 NE 25th, JF1-97, Hillsboro, OR 97224 ______________________________ Reply Separator _________________________________ Subject: IBIS and Pinnacle Author: huq@rockie.nsc.com at SMTPGATE Date: 3/12/95 9:37 AM Hi IBISgurus, Within our corporation, there is a push going on for device documentation (ex.datasheets)using SGML(Standard Generalized Markup Language) under what is know as PCIS(Pinnacles Component Information Standard). The question came up whether IBIS and Pinnacle can work together to link the two programs somehow. This will give customers a SGML formatted copy of a datasheet along with an IBIS models which can both be available electronically. Pinnacle is moving more towards providing datasheets thru SGML formatted databooks while IBISis providing models in a standard software parsable format. I remember meeting a member of the Pinnacle group in our last years DAC IBIS summit. Has anything happened since or can anyone comment on this issue. Do you guys see this being feasible ? Regards, Syed. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Syed B. Huq Applications Engineer/Data Transmission Products National Semiconductor Tel:(408)721-4874; Fax:(408)721-4785 Internet:huq@rockie.nsc.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From Will_Hobbs@ccm2.jf.intel.com Mon Mar 13 14:10:21 1995 Return-Path: Received: from ormail.intel.com ([134.134.192.3]) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10147; Mon, 13 Mar 95 14:10:21 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0roIEQ-000Us9C; Mon, 13 Mar 95 14:04 PST Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0roHuW-000twtC; Mon, 13 Mar 95 13:44 PST Received: by ccm.jf.intel.com (ccmgate 3.0) Mon, 13 Mar 95 13:44:19 PST Date: Mon, 13 Mar 95 13:44:19 PST From: Will Hobbs Message-Id: <950313134419_3@ccm.jf.intel.com> To: cer@Cadence.COM, ibis@vhdl.org Subject: Re: HTML ibis documents Text item: Sounds like a perfect job for Perl. Will Fellow Ibis'ers, If there is really interest in having an HTML version of IBIS data around then I suggest that the HTML version should be derived from the IBIS format automatically. We do not want the headaches of keeping two parallel data streams concurrent! There are two options: 1) Define a new format that results in an HTML document that is also easily parsed automatically, or as I suggested above 2) Write a program that automatically converts from the current IBIS format to an HTML document. I think option 2 is better since many people (such as us) already depend on the current Ibis format and would find it burdensome to change that format now. Chris Reid cer@cadence.com Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: HTML ibis documents To: ibis@vhdl.org Message-Id: <9503131339.AA18536@oahu> From: cer@cadence.com (Chrisopher E. Reid) Date: Mon, 13 Mar 95 08:39:48 -0500 Received: by oahu (5.65+/1.5) id AA18536; Mon, 13 Mar 95 08:39:48 -0500 Received: from oahu by cadence.Cadence.COM (5.61/3.14) id AA00339; Mon, 13 Mar 95 05:39:03 -0800 Received: from cadence.cadence.com(158.140.18.1) by mailgate.cadence.com via sma p (V1.0mjr) id sma017799; Mon Mar 13 05:39:52 1995 Received: (from smap@localhost) by mailgate.Cadence.COM (8.6.8/8.6.8) id FAA1784 4 for ; Mon, 13 Mar 1995 05:40:04 -0800 Received: from mailgate.Cadence.COM by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA06591; Mon, 13 Mar 95 05:45:20 PST Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Mon, 13 Mar 95 06 :07:51 -0800 Received: from hermes.intel.com by ichips.intel.com (5.64+/10.0i); Mon, 13 Mar 9 5 06:08:02 -0800 Received: from ichips.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0roAmy-000twoC; Mon, 13 Mar 95 06:08 PST From Derrick_Duehren@ccm2.jf.intel.com Tue Mar 14 06:16:20 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA20109; Tue, 14 Mar 95 06:16:20 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0roXJP-000UulC; Tue, 14 Mar 95 06:11 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0roXJP-000twpC; Tue, 14 Mar 95 06:11 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Tue, 14 Mar 95 06:11:02 PST Date: Tue, 14 Mar 95 06:11:02 PST From: Derrick Duehren Message-Id: <950314061102_1@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: IBIS 3/17/95 Meeting Agenda IBIS Open Forum Meeting Agenda for 3/17/95 Bridge: Res: (916) 356-9999 461603 All meetings are 8:00 AM to 10:00 AM Pacific Time (16:00 to 18:00 UTC). When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the reservation number. 8:00 Check-in, Intros, Announcements Hobbs - Intros of new IBIS participants - Review of previous meeting's minutes (and ARs) - Miscellany/announcements/treasurer's report - Opens for new issues - Press updates - New models available 8:20 Progress toward enlisting new IC vendors All 8:45 Golden Parser 2.1 status Hobbs - IBIS filename case resolution Hobbs - Tabs and Control-Ms in .ibs files Arpad - Advanced package options Ross - Other issues 9:00 EIA affiliation status Hobbs Rev 2.1 updates Hobbs o S2IBIS 2.1 o Cookbook o Overview 9:20 Model creator name Hobbs SGML/HTML support? Huq 9:55 Wrap-up, next meeting plans Hobbs From kellee@nwlink.com Wed Mar 15 11:13:35 1995 Return-Path: Received: from washington.nwlink.com (nwlink.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA05994; Wed, 15 Mar 95 11:13:35 PST Received: by washington.nwlink.com id AA27480 (5.67b/IDA-1.5 for ibis@vhdl.org); Wed, 15 Mar 1995 11:06:45 -0800 Date: Wed, 15 Mar 1995 11:06:45 -0800 Message-Id: <199503151906.AA27480@washington.nwlink.com> X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis@vhdl.org From: kellee@nwlink.com Subject: To Paul, regarding case. >From: Paul Munsey <73053.721@compuserve.com> > >1) It seems to be more complex. Yes I think your right, however it will make life for the the users much easier. >2) I believe that item 4 (the second item 4) contradicts itself. That is, > the final statement says: > "If not (the file name matches exactly what the user typed) then it > is suffient to check only for a lower case name". > This sounds like the parser should try and open the file exactly as it was > entered on the command line; if no such file exists, then the parser should > try and open the filename as all lowercase characters. This sounds fine, > but the first two sentences of the item say: > "The file should be parsed and checked no matter what the case. > For example if the user types in a lower case name and the file name > on the system is upper case because it came from a DOS enviorment > the file should still be parsed." > Now it sounds like we're saying to check for uppercase names, not lower. > Let me know if I'm missreading this. >Paul Munsey I don't believe there is any contradiction. So I will try to say it another way. 1) The parser should check any file with the same name and a .ibs extension no matter what the case of the name or extension. This means the user might type FOO.ibs or Foo.IbS or foo.ibs and the parser should check the either file foo.ibs or FOO.IBS. However if both FOO.IBS and foo.ibs are present then the file with matching case should be tested unless it is not clear which file matches, then pick the lower case file. 2) The file name in the .ibs file must still be tested for case and a warning given if not lower case. 3) If a user has gotten a file from a DOS system with the name FOO.IBS and another version of the same file was copied and edited on a unix system with the name foo.ibs then he should be able to explicitly select which file to use. (This was Bob's concern) Have a great day...Kellee Crisafulli, HyperLynx Inc. From kellee@nwlink.com Wed Mar 15 11:17:55 1995 Return-Path: Received: from washington.nwlink.com (nwlink.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA06046; Wed, 15 Mar 95 11:17:55 PST Received: by washington.nwlink.com id AA28010 (5.67b/IDA-1.5 for ibis@vhdl.org); Wed, 15 Mar 1995 11:11:56 -0800 Date: Wed, 15 Mar 1995 11:11:56 -0800 Message-Id: <199503151911.AA28010@washington.nwlink.com> X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis@vhdl.org From: kellee@nwlink.com Subject: Answer to Scott, about Case >From: Scott Aron Bloom > 3) If the file name from the command line is not all lower case than the > parser must > post a WARNING (accept versions compiled for DOS). The warning should > be state that >Does this mean there is no warning on DOS systems?? That is correct. The DOS systems internally save file names as upper case and that cannot be changed. All DOS systems should not be forced to generate a WARNING. Have a great day...Kellee Crisafulli, HyperLynx Inc. From kellee@nwlink.com Fri Mar 17 23:50:53 1995 Return-Path: Received: from washington.nwlink.com (nwlink.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA06617; Fri, 17 Mar 95 23:50:53 PST Received: by washington.nwlink.com id AA12360 (5.67b/IDA-1.5 for ibis@vhdl.org); Fri, 17 Mar 1995 23:44:53 -0800 Date: Fri, 17 Mar 1995 23:44:53 -0800 Message-Id: <199503180744.AA12360@washington.nwlink.com> X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ibis@vhdl.org From: kellee@nwlink.com Subject: IBIS meeting, resolution on CASE issue From: Kellee Crisafulli, HyperLynx To: IBIS All and Paul Re: Resolution of the Case issue at the meeting on Friday, 3-17-95 We agreed that the some changes are needed to the new IBIS parser before final release. We also agreed that Paul should receive additional compensation for making these changes. The following changes are required in the new IBIS parser: 1) After a file name is read from the command line the file extesion should be tested to see if it is either .ibs or .IBS, if so attempt to open the file using the name as typed on the command line. If this fails because a file with this name is not present, convert the name and file extension to lower case and attempt to open the file again. If this fails because a file with this name is not present, convert the name and file extension to uppoer case and try again. If this fails, then report file not found. If any one of the three attempts to open the file succeed, then proceed to parse and check the file. 2) The program shall include a compiler switch to perform the following: 1) If the file opens, and the name typed in on the command line is not lower case and the parser was compiled for anything other than a DOS file system computer, than the parser shall reported a warning to the user indicating the file name should be lower case. (how is that for a long sentence). 2) If the parser was compiled for a DOS file system computer than no warning should occur. 3) The above also applies to any file names referenced from within the file for example .pkg files in version 2.x IBIS. So three attempts to open the pkg file should be made, first as entered in the file, then as lower case, then as upper case. 4) File names specified within the .ibs file must be lower case. This includes both the .ibs and .pkg file names. If they are not lower case a warning should be issued indicating that file names should be lower case. (I believe we already have this warning. Paul please verify.) 5) The parser should issue ONE warning if any tab characters are found in the file. The Warning should inform the user that 'IBIS files should not contain tab characters'. This is to prevent problems with editors expanding tabs differently and ending up with files with lines over 80 characters because tabs were expanded with say 8 characters instead of say 3 as the author intended. 6) The parser should also read files from either DOS or UNIX enviroments without error. This probably requires the files to be opened in binary mode and a special 'gets' function to be written which recognizes any of the following as an end of line character: 0x0d 0x0a 0x0d followed by 0a 0x0a followed by 0d It was noted that files have been found which contain the following as an end of line character: 0d0a for dos, or 0a for Unix and this causes the parser to reject correct files. 7) The DOS end of file character 0x1a (control Z) should be ignored. This is a problem for Unix versions of the parser reading a file from a DOS enviorment which was transported without stripping the end of file character. 8) If a tab is found in an IBIS file it should be treated as ONE 0x20(space) character. This applies both to counting the total number of characters on the line and treating it as a a white space character. (I think the parser already does this. Paul please verify). Have a great day...Kellee Crisafulli, HyperLynx Inc. From johnb@redac.co.uk Mon Mar 20 04:25:30 1995 Return-Path: Received: from relay1.pipex.net by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04326; Mon, 20 Mar 95 04:25:30 PST Received: from redac.co.uk (actually redactcouk.redac.co.uk) by flow.pipex.net with SMTP (PP); Mon, 20 Mar 1995 12:19:53 +0000 Received: from redpo by redac.co.uk (5.0/SMI-SVR4) id AA04058; Mon, 20 Mar 1995 12:24:48 +0000 Received: from [89.32.39.5] (mac4_tsupp) by redpo (4.1/Redac-Interior-Gateway-V1.1) id AA08651; Mon, 20 Mar 95 12:11:37 GMT Date: Mon, 20 Mar 95 12:11:34 GMT Message-Id: <9503201211.AA08651@redpo> To: ibis@vhdl.org From: johnb@redac.co.uk (John Berrie) Subject: Ramp Rates Content-Length: 1229 Dear IBISians, 1. Can anyone clarify the convention for the dV/dT values for the ramp characteristics. It is of course necessary to extract rise or fall time in order to get dV/dT, but is the value for dV necessarily the actual voltage transition when the output is being measured with a standard load ? In other words, if a device had a 20%->80% transition time of 2nS with a transition voltage of 5V, would 2.5V/1nS be allowed as an equally valid entry as 5V/2nS. The reason I ask is that when looking at the line formula-based in the frequency domain, the upper frequency of concern is 0.35/Tr which is a useful figure to be able to derive easily and approximately. 2. Any information on IBIS model availability, now or in the near future, free or for sale, would be most welcome. Thanks in advance for your help. Best Regards, John -------------------------------------------------------------------------- John Berrie, Chief Application Engineer Zuken-Redac Limited, Green Lane,Tewkesbury, Glos. GL20 8HE, England Tel: (44) 01684 294161 Fax:(44) 01684 299754 E-Mail johnb@redac.co.uk -------------------------------------------------------------------------- From Arpad_Muranyi@ccm.fm.intel.com Mon Mar 20 12:39:28 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07432; Mon, 20 Mar 95 12:39:28 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rqo9L-000Uk7C; Mon, 20 Mar 95 12:34 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rqo9L-000tzOC; Mon, 20 Mar 95 12:34 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Mon, 20 Mar 95 12:34:03 PST Date: Mon, 20 Mar 95 12:34:03 PST From: Arpad Muranyi Message-Id: <950320123403_4@ccm.hf.intel.com> To: kellee@nwlink.com, ibis@vhdl.org Subject: Re: IBIS meeting, resolution on CASE issue Text item: Kellee, Regarding point 5) I think that the warning message should be milder, since it is still legal to use TABs. It should say something like: "It is recommended that IBIS files should not contain TAB characters" Arpad ----------------------------------------------------------------------------- 5) The parser should issue ONE warning if any tab characters are found in the file. The Warning should inform the user that 'IBIS files should not contain tab characters'. This is to prevent problems with editors expanding tabs differently and ending up with files with lines over 80 characters because tabs were expanded with say 8 characters instead of say 3 as the author intended. Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: IBIS meeting, resolution on CASE issue From: kellee@nwlink.com To: ibis@vhdl.org Content-Type: text/plain; charset="us-ascii" Mime-Version: 1.0 X-Mailer: Windows Eudora Version 2.0.3 Message-Id: <199503180744.AA12360@washington.nwlink.com> Date: Fri, 17 Mar 1995 23:44:53 -0800 Received: by washington.nwlink.com id AA12360 (5.67b/IDA-1.5 for ibis@vhdl.org); Fri, 17 Mar 1995 23:44:53 -0800 Received: from washington.nwlink.com (nwlink.com) by vhdl.vhdl.org (4.1/SMI-4.1/ BARRNet) id AA06617; Fri, 17 Mar 95 23:50:53 PST Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Fri, 17 Mar 95 23 :48:16 -0800 Received: from hermes.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0rptFB-000txEC; Fri, 17 Mar 95 23:48 PST From Derrick_Duehren@ccm2.jf.intel.com Mon Mar 20 14:00:27 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08033; Mon, 20 Mar 95 14:00:27 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rqpPi-000Ul5C; Mon, 20 Mar 95 13:55 PST Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rqpPi-000txgC; Mon, 20 Mar 95 13:55 PST Received: by ccm.jf.intel.com (ccmgate 3.0) Mon, 20 Mar 95 13:55:02 PST Date: Mon, 20 Mar 95 13:55:02 PST From: Derrick Duehren Message-Id: <950320135502_1@ccm.jf.intel.com> To: ibis@vhdl.org Subject: Re[2]: IBIS meeting, resolution on CASE issue I agree with Arpad, except I recommend dropping the word "should". So it would display as: "It is recommended that IBIS files not contain TAB characters" - Derrick ______________________________ Reply Separator _________________________________ Subject: Re: IBIS meeting, resolution on CASE issue Author: Arpad Muranyi at JFCCM3 Date: 3/20/95 12:51 PM Kellee, Regarding point 5) I think that the warning message should be milder, since it is still legal to use TABs. It should say something like: "It is recommended that IBIS files should not contain TAB characters" Arpad ----------------------------------------------------------------------------- 5) The parser should issue ONE warning if any tab characters are found in the file. The Warning should inform the user that 'IBIS files should not contain tab characters'. This is to prevent problems with editors expanding tabs differently and ending up with files with lines over 80 characters because tabs were expanded with say 8 characters instead of say 3 as the author intended. From bob@icx.com Mon Mar 20 19:58:18 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10389; Mon, 20 Mar 95 19:58:18 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 20 Mar 95 19:52 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Mon, 20 Mar 95 19:54 PST Message-Id: Date: Mon, 20 Mar 95 19:54 PST From: bob@icx.com ( Bob Ross) To: ibis@vhdl.org, johnb@redac.co.uk Subject: Re: Ramp Rates John, Regarding quesiton 1, if 5V/2nS is the true ramp rate in compliance with the NOTES ON DATA DERIVATION METHOD, replacing this with 2.5V/1nS is NOT equivalent (assuming that the subparameter R_load has not changed) for several reasons: (1) It would be in violaton of the specified measurement conditions. (2) A different measurement condition that is not in compliance with the stated conditions (e.g. a lower resistance load) would most likely NOT give a 1nS risetime response, but something closer to 2nS. (3) The dV value is actually redundant since it can be derived from the I/V characteristics and test load DC conditions directly. If it is in conflict with the derived value, I would use the derived value for consistency with I/V curve usaage elsewhere in the IBIS model. It is my interpretation to assume that dt_r and dt_f are the informative portions of the [Ramp] specification and are to be used directly. Even though the [Ramp] is given as a ratio, it should NOT be scaled. However, I believe the frequency response approximation assumes Tr is the 10-90% value, so the only scaling would be to multiply dt_r by (.8/.6) to extrapolate to the 10-90% value, and similarly for dt_f. Bob Ross Interconnectix, Inc. > Dear IBISians, > 1. Can anyone clarify the convention for the dV/dT values for the ramp > characteristics. It is of course necessary to extract rise or fall time in > order to get dV/dT, but is the value for dV necessarily the actual voltage > transition when the output is being measured with a standard load ? In > other words, if a device had a 20%->80% transition time of 2nS with a > transition voltage of 5V, would 2.5V/1nS be allowed as an equally valid > entry as 5V/2nS. The reason I ask is that when looking at the line > formula-based in the frequency domain, the upper frequency of concern is > 0.35/Tr which is a useful figure to be able to derive easily and > approximately. > 2. Any information on IBIS model availability, now or in the near future, > free or for sale, would be most welcome. > Thanks in advance for your help. > Best Regards, > John > -------------------------------------------------------------------------- > John Berrie, Chief Application Engineer > Zuken-Redac Limited, > Green Lane,Tewkesbury, > Glos. GL20 8HE, England > Tel: (44) 01684 294161 > Fax:(44) 01684 299754 > E-Mail johnb@redac.co.uk > -------------------------------------------------------------------------- From Arpad_Muranyi@ccm.fm.intel.com Tue Mar 21 15:21:28 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA21819; Tue, 21 Mar 95 15:21:28 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rrD9g-000UglC; Tue, 21 Mar 95 15:16 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rrD9g-000tyyC; Tue, 21 Mar 95 15:16 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Tue, 21 Mar 95 15:16:04 PST Date: Tue, 21 Mar 95 15:16:04 PST From: Arpad Muranyi Message-Id: <950321151604_4@ccm.hf.intel.com> To: Derrick_Duehren@ccm2.jf.intel.com, ibis@vhdl.org Subject: Re[3]: IBIS meeting, resolution on CASE issue Text item: Sounds good to me. (Thanks for correcting my broken English). Arpad --------------------------------------------------------------------------- I agree with Arpad, except I recommend dropping the word "should". So it would display as: "It is recommended that IBIS files not contain TAB characters" - Derrick Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. Subject: Re[2]: IBIS meeting, resolution on CASE issue To: ibis@vhdl.org Message-Id: <950320135502_1@ccm.jf.intel.com> From: Derrick Duehren Date: Mon, 20 Mar 95 13:55:02 PST Received: by ccm.jf.intel.com (ccmgate 3.0) Mon, 20 Mar 95 13:55:02 PST Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rqpPi-000txgC; Mon, 20 Mar 95 13:55 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rqpPi-000Ul5C; Mon, 20 Mar 95 13:55 PST Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA08033; Mon, 20 Mar 95 14:00:27 PST Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Mon, 20 Mar 95 13 :57:50 -0800 Received: from hermes.intel.com by relay.jf.intel.com with smtp (Smail3.1.28.1 #2) id m0rqpSR-000tyQC; Mon, 20 Mar 95 13:57 PST From liren@lsil.com Tue Mar 21 18:17:01 1995 Return-Path: Received: from relay2.UU.NET by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA22887; Tue, 21 Mar 95 18:17:01 PST Received: from lsi.lsil.com by relay2.UU.NET with SMTP id QQyice23821; Tue, 21 Mar 1995 21:11:36 -0500 Received: from mhost.lsil.com by lsi.lsil.com with SMTP id AA29558 (5.67a/IDA-1.4.4 for ); Tue, 21 Mar 1995 17:57:40 -0800 Received: from egst26.lsil.com by mhost.lsil.com (4.1/SMI-4.1) id AA02658; Tue, 21 Mar 95 17:57:36 PST Received: by egst26.lsil.com (4.1/SMI-4.0) id AA08093; Tue, 21 Mar 95 17:57:35 PST Date: Tue, 21 Mar 95 17:57:35 PST From: liren@lsil.com (Liren Chen) Message-Id: <9503220157.AA08093@egst26.lsil.com> To: ibis@vhdl.org Subject: info info please ****************************************************************************** Liren Chen LSI Logic Corporation Tel:(408)433-8378 1501 McCarthy Blvd, MS E-189 Fax:(408)433-7719 Milpitas, CA95035 . E-Mail:liren@lsil.com .- / \ -. ./' /+-+\ `\. ****************************************************************************** From Powelljon@aol.com Wed Mar 22 22:11:50 1995 Return-Path: Received: from mail02.mail.aol.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA07814; Wed, 22 Mar 95 22:11:50 PST Received: by mail02.mail.aol.com (1.37.109.11/16.2) id AA069948789; Thu, 23 Mar 1995 01:06:29 -0500 Date: Thu, 23 Mar 1995 01:06:29 -0500 From: Powelljon@aol.com Message-Id: <950323010628_58310375@aol.com> To: ibis@vhdl.org Subject: IBIS art I am in the process of making up the IBIS participation signs for the DAC. I need a good picture (perferably line art) or an IBIS like creature. Bob, if you can give me a good rendition of your IBIS logo that would be great (I have been unable to duplicate). I am looking for a bmp file or similar computer ready art but can scan if good hardcopy is available. thanks for any help jon powell From mbs@eos.ncsu.edu Thu Mar 23 03:57:42 1995 Return-Path: Received: from mbs.ece.ncsu.edu (c11058-335dan.ece.ncsu.edu) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA10548; Thu, 23 Mar 95 03:57:42 PST Received: by mbs.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA16505; Thu, 23 Mar 1995 06:52:19 -0500 From: mbs@eos.ncsu.edu Message-Id: <9503231152.AA16505@mbs.ece.ncsu.edu> To: ibis@vhdl.org Subject: New IBIS model Date: Thu, 23 Mar 95 06:52:19 EST A new model from National Semiconductor has been added to the library. details are model 700v.ibs component CGS700V directory /pub/ibis/models/national/interface Michael Steer From Will_Hobbs@ccm2.jf.intel.com Fri Mar 24 12:07:06 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA29966; Fri, 24 Mar 95 12:07:06 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rsFYC-000UlLC; Fri, 24 Mar 95 12:01 PST Received: from ccm.jf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rsFYB-000tz5C; Fri, 24 Mar 95 12:01 PST Received: by ccm.jf.intel.com (ccmgate 3.0) Fri, 24 Mar 95 12:01:39 PST Date: Fri, 24 Mar 95 12:01:39 PST From: Will Hobbs Message-Id: <950324120139_1@ccm.jf.intel.com> To: ibis@vhdl.org Subject: BIRD 26, Syntax guidelines on Tab usage Buffer Issue Resolution Document (BIRD) BIRD ID#: 26 ISSUE TITLE: General syntax rules an guidelines on TAB character usage REQUESTOR: Arpad Muranyi, Intel Corporation, Folsom, CA DATE SUBMITTED: March 20, 1995 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ******************************************************************************* ******************************************************************************* STATEMENT OF THE ISSUE: Even though TAB characters are allowed in IBIS files and their usage is legal, there are times when their use can cause problems. For example, in conjunction with the 80 character/line limitation, the golden parser might issue error messages with IBIS files in which the TAB characters were converted to SPACE characters, but were error free before the conversion took place. At such conversions a TAB character is usually replaced by several SPACE characters. This can turn a line originally less than 80 characters into lines more than 80 characters long. Conversions like this are usually done by text editors and file transfering software and may take place unnoticed by the user. ******************************************************************************* STATEMENT OF THE RESOLVED SPECIFICATIONS: A new section should be added to the General sytax rules and guidelines section which recommends that TAB characters should be avoided if possible. | General syntax rules and guidelines: | | . | | . | | . | | 10) The usage of TAB characters is legal, but they should be avoided as far | | as possible. This is to eliminate possible complications which might arise | | in situations when TAB characters are automatically converted to multiple | | spaces by text editing, file transfering and similar software. In cases | | like that, lines might become longer than 80 characters which is illegal in | | IBIS files. | ******************************************************************************* ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: A user of an IBIS file reported that the Golden parser generated error messages with IBIS files which he downloaded from the vhdl.org machine. These IBIS files were error free when checked with the Golden parser before and after posting. The problem was localized to those lines in the IBIS file in question, which were 76 characters long and contained a TAB character. During the user's downloading process these TABs were converted to eight spaces resulting in 84 character lines which are illegal in IBIS. ******************************************************************************* ANY OTHER BACKGROUND INFORMATION: ******************************************************************************* From mbs@eos.ncsu.edu Mon Mar 27 08:54:15 1995 Return-Path: Received: from mbs.ece.ncsu.edu (c11058-335dan.ece.ncsu.edu) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA04120; Mon, 27 Mar 95 08:54:15 PST Received: by mbs.ece.ncsu.edu (5.65/Eos/C-U-09Sep93) id AA05192; Mon, 27 Mar 1995 11:48:51 -0500 From: mbs@eos.ncsu.edu Message-Id: <9503271648.AA05192@mbs.ece.ncsu.edu> To: ibis@vhdl.org Subject: IBIS model -- directory path change Date: Mon, 27 Mar 95 11:48:50 EST The recently submitted ibis model 700v.ibs has been moved to a new directory chain: /pub/ibis/models/national/cgs . Documentation on this model has been updated. Michael Steer From yoram@taux01.nsc.com Tue Mar 28 03:12:32 1995 Return-Path: Received: from gatekeeper.nsc.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA11804; Tue, 28 Mar 95 03:12:32 PST Received: from nsc.nsc.com by gatekeeper.nsc.com (5.65/fma-120691) with SMTP; id AA20821 for ibis@vhdl.org; Tue, 28 Mar 95 03:07:03 -0800 Received: from taux01.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP id AA16139 for ibis@vhdl.org; Tue, 28 Mar 95 03:06:47 -0800 Received: from tasu44.nsc.com by taux01.nsc.com (4.1/SMI-4.1) id AA28929; Tue, 28 Mar 95 13:07:31 IST Received: by tasu44.nsc.com (4.1/SMI-4.1) id AA20647; Tue, 28 Mar 95 13:07:29 IST Date: Tue, 28 Mar 95 13:07:29 IST From: yoram@taux01.nsc.com (Yoram Avigdor) Message-Id: <9503281107.AA20647@tasu44.nsc.com> To: ibis@vhdl.org Subject: Subscription to IBIS I would like to be a subscriber of the IBIS correspondence. Thanks, Yoram Avigdor *********************************************************************** * Yoram Avigdor Email : yoram@taux01.nsc.com * * NSTA Circuit Group Manager Work Phone : 972-9-594-301 * * National Semiconductor (ISRAEL) Fax : 972-9-558-332 * * Home Phone : 972-9-974-557 * *********************************************************************** From scott@icx.com Tue Mar 28 16:32:55 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA20157; Tue, 28 Mar 95 16:32:55 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 28 Mar 95 16:27 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Tue, 28 Mar 95 16:29 PST Message-Id: To: ibis@vhdl.org Subject: Remove one of my accounts Date: Tue, 28 Mar 1995 16:29:54 -0800 From: Scott Aron Bloom Please remove blooms@ece.orst.edu from the reflector listing. Scott Interconnectix, Inc. From scott@icx.com Wed Mar 29 13:32:42 1995 Return-Path: Received: from icx.com (icx.rain.com) by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA01535; Wed, 29 Mar 95 13:32:42 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 29 Mar 95 13:27 PST Received: by icx.com (/\==/\ Smail3.1.28.1 #28.14) id ; Wed, 29 Mar 95 13:29 PST Message-Id: To: ibis@vhdl.org Subject: IBIS parser 2.1 problem Date: Wed, 29 Mar 1995 13:29:42 -0800 From: Scott Aron Bloom While trying to compiler the IBIS parser 2.1d using gcc, I ran accross a problem that has not come up under other compilers. The value of FILENAME_MAX is never defined, with out this definition gcc will not compile ibischk. What is the difference between FILENAME_MAX and IBIS_FILENAME_LEN? Any help would be appreciated Scott Interconnectix, Inc. From bert@ibmoto.com Wed Mar 29 14:59:10 1995 Return-Path: Received: from styx.ibmoto.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA02065; Wed, 29 Mar 95 14:59:10 PST Received: from lw.ibmoto.com (lw.ibmoto.com [129.38.13.34]) by styx.ibmoto.com (8.6.10/8.6.9) with ESMTP id QAA14927 for ; Wed, 29 Mar 1995 16:53:45 -0600 Received: (bert@localhost) by lw.ibmoto.com (8.6.10/8.6.9) id QAA25443; Wed, 29 Mar 1995 16:53:44 -0600 Message-Id: <199503292253.QAA25443@lw.ibmoto.com> To: ibis@vhdl.org Date: Wed, 29 Mar 95 16:53:43 -0600 From: Lynn Warriner unsubscribe From Derrick_Duehren@ccm2.jf.intel.com Wed Mar 29 17:48:31 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA03377; Wed, 29 Mar 95 17:48:31 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0ru9GM-000Uf0C; Wed, 29 Mar 95 17:43 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0ru9GL-000ty3C; Wed, 29 Mar 95 17:43 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Wed, 29 Mar 95 17:43:04 PST Date: Wed, 29 Mar 95 17:43:04 PST From: Derrick Duehren Message-Id: <950329174304_1@ccm.hf.intel.com> To: Jerry_Budelman@ccm2.jf.intel.com, Randy_L_Wilhelm@ccm.fm.intel.com, IBIS@vhdl.org Subject: Minutes from IBIS Open Forum Meeting 3/17/95 Date: March 29, 1995 From: Will Hobbs (503) 264-4369, fax (503) 264-4210 Will_Hobbs@ccm.jf.intel.com XTG Modeling Manager, Intel Corp., Chairperson, IBIS Open Forum Intel Corporation 5200 NE Elam Young Pkwy, Hillsboro, OR 97124 USA and Derrick Duehren (503) 264-4299, fax (503) 264-4904 Derrick_Duehren@ccm.jf.intel.com Intel Program Manager, IBIS Secretary Subject: Minutes from IBIS Open Forum Meeting 3/17/95 Participants: ARPA Randy Harr AT&T Global Info Solutions Dave Moxley* Anacad Steffen Rochel Ansoft Henri Maramis Atmel Corporation Dan Terry Cadence Design Sandeep Khanna, C. Kumar* Cadlab Ralf Bruning Contec Dileep Divekar Digital Equipment Corp. Barry Katz EIA Patty Rusher High Design Technology Michael Smith, Dr. Ing. Cosso HP Palo Alto Tom Langdorf HP EESof Karl Kachigan, Henry Wu HyperLynx Kellee Crisafulli IBM Jay Diepenbrock, Joseph Flanigan IBM-Motorola alliance Lynn Warriner, John Burnett INCASES Werner Rissiek, Olaf Rethmeier Integrated Silicon Systems Eric Bracken Intel Corporation Stephen Peters*, Don Telian, Will Hobbs* Arpad Muranyi*, Derrick Duehren*, Tim Schreyer* Interconnectix, Inc. Bob Ross* Intergraph Ian Dodd, David Wiens, Walter Katz IntuSoft Charles Hymowitz Mentor Graphics Ravender Goyal, Greg Doyle Meta-Software Mei Wong, You-Pang Wei, John Sliney MicroSim Arthur Wong National Semiconductor Syed Huq*, Raj Raghuraum, Atul Agarwal NEC Hiroshi Matsumoto North Carolina State U. Steve Lipa, Michael Steer OptEM Engineering, Inc. Benny Leveille, Ken Ehn Pacific Numerix Paul K. U. Wang Quad Design Jon Powell* Quantic Labs Mike Ventham Racal-Redac John Berrie Symmetry Martin Walker Synopsys, Logic Modeling G. Bill Lattin Texas Instruments Bob Ward* Thomson-CSF/SCTF Jean Lebrun UniCAD Canada Ltd. Stephen Lum Zeelan Technology George Opsahl, Hiro Moriyasu CC: Intel Corporation Randy Wilhelm, Jerry Budelman, Intel IBIS team In the list above, attendees at the meeting are indicated by *. Upcoming Meetings: The bridge numbers for future IBIS teleconferences are listed below: Date Bridge Number Reservation # 4/7/95 (916) 356-9999 461605 4/28/95 (916) 356-9999 461609 All meetings are 8:00 AM to 10:00 AM Pacific Time (16:00 to 18:00 UTC). We try to have agendas out 7 days before each open forum and meeting minutes out within 7 days after. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the reservation number. NOTE: "AR" = Action Required. ------------------------------------------------------------------------------ Check-in, Intros, Announcements There were no new participants. There were no corrections made to last month's minutes. Conference Management Systems transferred our remaining funds ($1,400) to our EIA account. Derrick told of a Cadence AWK script for generating IBIS-like model data from SPICE runs. AR Kumar -- Check into it. [Done] The script converts raw vi data of the 4 tables to Cadence's SigNoise format. Kumar sees no use for it in the IBIS forum unless someone is willing to write a script to dump the data into an IBIS file. In that case the process would be: Raw Data (already in IBIS type of column format) ----> script ----> MODEL statement in an .ibs file New Agenda Items: New keyword for differential I/O (Bob Ward) Enhancements to the timing spec (Stephen Peters) Diode Transit Times (Tim Schreyer) Press Updates: Design Superconference, one paper by Chipcomm mentioned IBIS throughout. IEEE Transactions, February issue mentions IBIS once. ***** NEWS FLASH! ***** The March 16 EDN Magazine has a feature article on IBIS by Derrick, Will, Arpad, and Robin Rosenbaum. *********************** New Models Available: National Semiconductor submitted more models to Michael for posting. Progress toward enlisting new IC vendors None reported. Golden Parser 2.1 progress and release date - IBIS filename case resolution DOS seems to be inconsistent with its treatment of filename case, especially when transferring it to other operating systems. Consensus is that the Golden parser should only submit a warning if filenames are not all lowercase. Kellee captured our consensus and read his notes on what we decided. All agreed. It is repeated below. Bob Ross pointed out that this discussion also applies to .pkg files and the .ibs (.IBS) extension. AR Kellee -- Work with Paul Munsey to resolve and implement these changes. ****************** CASE-RELATED GOLDEN PARSER CORRECTIONS ******************** We agreed that some changes are needed to the new IBIS parser before final release. We also agreed that Paul should receive additional compensation for making these changes. The following changes are required in the new IBIS parser: 1) After a file name is read from the command line the file extension should be tested to see if it is either .ibs or .IBS, if so attempt to open the file using the name as typed on the command line. If this fails because a file with this name is not present, convert the name and file extension to lower case and attempt to open the file again. If this fails because a file with this name is not present, convert the name and file extension to upper case and try again. If this fails, then report file not found. If any one of the three attempts to open the file succeed, then proceed to parse and check the file. 2) The program shall include a compiler switch to perform the following: a) If the file opens, and the name typed in on the command line is not lower case and the parser was compiled for anything other than a DOS file system computer, than the parser shall reported a warning to the user indicating the file name should be lower case. (how is that for a long sentence). b) If the parser was compiled for a DOS file system computer than no warning should occur. c) The above also applies to any file names referenced from within the file for example .pkg files in version 2.x IBIS. So three attempts to open the pkg file should be made, first as entered in the file, then as lower case, then as upper case. d) File names specified within the .ibs file must be lower case. This includes both the .ibs and .pkg file names. If they are not lower case a warning should be issued indicating that file names should be lower case. (I believe we already have this warning. Paul please verify.) e) The parser should issue ONE warning if any tab characters are found in the file. The Warning should inform the user that 'IBIS files should not contain tab characters'. >> Arpad/Derrick's subsequent recommended wording: "It is recommended that >> IBIS files not contain TAB characters" This is to prevent problems with editors expanding tabs differently and ending up with files with lines over 80 characters because tabs were expanded with say 8 characters instead of say 3 as the author intended. f) The parser should also read files from either DOS or UNIX environments without error. This probably requires the files to be opened in binary mode and a special 'gets' function to be written which recognizes any of the following as an end of line character: 0x0d 0x0a 0x0d followed by 0a 0x0a followed by 0d It was noted that files have been found which contain the following as an end of line character: 0d0a for DOS, or 0a for UNIX and this causes the parser to reject correct files. 7) The DOS end of file character 0x1a (control Z) should be ignored. This is a problem for UNIX versions of the parser reading a file from a DOS environment which was transported without stripping the end of file character. 8) If a tab is found in an IBIS file it should be treated as ONE 0x20(space) character. This applies both to counting the total number of characters on the line and treating it as a white space character. (I think the parser already does this. Paul please verify). ***************************** END OF CORRECTIONS ***************************** - Tabs and Control-Ms in .ibs files Apparently files are modified during transfer to and from vhdl.org. Dave Moxley found some wrong characters (^M at end of line) that weren't in Arpad's original file. Arpad reviewed all the Intel files on vhdl.org and found all the files except two had Ctrl-Ms at the end of every line. One of these only had the ^M where the disclaimer was edited into the file, implying that the editing process was responsible. Further, the editing process can be done correctly as demonstrated by the one clean file. The extra ^M should not cause a problem according to the spec, but the 1.1 parser has a problem with it. Bob Ward suggested changing the library procedure to include a ^M stripping process and add a rule to the next version of the spec to exclude ^M. Arpad and Bob Ross would like to see the Librarian run a script to strip any Ctrl- Ms on .ibs files before posting it to vhdl.org. ^Z is another concern, which can occur whenever files are transferred in binary mode. There are several ways to strip these out, such as a stock filter (arcr?) in UNIX, to get rid of the ^Ms. FTP will usually do the right thing when transferring between OSs. The recommendation is to ask Paul Munsey to change the Golden Parser read routines so they work with either DOS or UNIX, ignore ^Z, and accept CRLF in various combinations (0A, 0D are acceptable as end of line, 1A as end of file). AR Kellee -- communicate this to Paul. (Instructions to Paul are in Kellee's Case changes above.) For archive purposes, UNIX format will be used. Librarian should run a DOS- to-UNIX filter on all files such that all files on vhdl.org are UNIX compatible (w/o Ctrl-Ms and Ctrl-Zs). - Tabs to spaces. Some editors convert tabs to spaces, violating the 80 character line length. We could put a flag in the GP to warns user that tabs are found and that they can cause problems with some systems that may convert these to spaces. "Your file may not parse correctly if..." AR Kellee -- Inform Paul, Arpad will work with Paul to clarify. (Instructions to Paul are in Kellee's Case changes above.) Need to recommend that tabs not be used in the next rev of the spec. AR Arpad -- Create a BIRD to strongly discourage use of tabs. [Done, BIRD 26] AR Michael Steer -- Convert all tabs to single spaces (and inform submitter that these changes were made). Will suggested that we offer Paul an extra $500 payment for this incremental work. Kellee will talk to Paul to see if this is appropriate. - Advanced package options Tabled for our next meeting. - Other issues We agreed to target 4/15/95 to have the full release of the GP. Status of EIA affiliation Pattie Rusher has sent out the "Join EIA IBIS" letter but it allows those who are already EIA members to escape paying dues. This was not our intention. AR Derrick -- Talk to Pattie R. Correct the "If already member of EIA, no dues due..." language in the EIA letter. Rev 2.1 updates o S2IBIS 2.1 Bob Ross reported that Michael Steer has a student assigned to work on the conversion utility, but the funding has not yet arrived. Bob Ross suggested that they modularize the program before expanding it further. o Cookbook No discussion. o Overview No discussion. Model Creator Name Will proposes that we recommended that the creator name or organization be included as a comment in the .ibs file so users have a way of reporting bugs found. SGML/HTML Support? PCIS (Pinnacle Component Interface Standard). Syed will post information on IBIS/SGML after he collects more information. New Keyword for Differential I/O Bob Ward will submit an Egg. Enhancements to the Timing Spec Stephen will create an Egg. Diode Transit Times Tim Schreyer summarized his experiments at Intel with ESD clamp diodes and has duplicated the effect in SPICE. The diodes overshoot when clamped, but have a TT of up to 70 nS, and when they turn on, they stay on for 20 nS, then spike charge back into the line when they turn off. This effect is very sensitive to turn-off time. Tim has calculated and simulated with the same results. Shottky diodes may exhibit different effects. Tim feels that Shottky diodes won't exhibit this effect. AR Tim -- "Clean up" your notes and give the files to Derrick for posting to vhdl.org. These method may be good to include as part of the IBIS spec. The forum will continue its investigations, using Tim's paper as a starting point. We'll need a way to measure it, and a way to get the information in IBIS, such as a new keyword. TT, C0 and a few other parameters were used in the analysis. It might be possible to measure this using a low impedance 4-foot line. Perhaps we can generate TT from this measurement. This could also be a good graduate study at NCSU. Wrap-up, Next Meeting Plans Our next meeting is a teleconference 4/7/95. Suggested Topics: o Directions for MCM. o Golden Parser 2.1 progress and release date - Advanced package options o New keyword for differential (Bob Ward's Egg) o Enhancements to the timing spec (Stephen's Egg) o EIA progress toward balloting ============================================================================== NOTES If you know of someone new who wants to join the e-mail reflector (ibis@vhdl.org), send e-mail to ibis-request@vhdl.org. Check the pub/ibis directory on vhdl.org for more information on previous discussions and results. You can get on via ftp anonymous, "guest" login from telnet or dial-in (415-335-0110), or send an email request to the automatic archive server, archive@vhdl.org. ============================================================================== From Derrick_Duehren@ccm2.jf.intel.com Fri Mar 31 19:27:30 1995 Return-Path: Received: from ormail.intel.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet) id AA27721; Fri, 31 Mar 95 19:27:30 PST Received: from relay.jf.intel.com by ormail.intel.com with smtp (Smail3.1.28.1 #7) id m0rutlE-000UdeC; Fri, 31 Mar 95 19:22 PST Received: from ccm.hf.intel.com by relay.jf.intel.com (Smail3.1.28.1 #2) id m0rutlD-000txHC; Fri, 31 Mar 95 19:22 PST Received: by ccm.hf.intel.com (ccmgate 3.0) Fri, 31 Mar 95 19:22:02 PST Date: Fri, 31 Mar 95 19:22:02 PST From: Derrick Duehren Message-Id: <950331192202_1@ccm.hf.intel.com> To: IBIS@vhdl.org Subject: IBIS Open Forum 4/7/95 Meeting Agenda IBIS Open Forum Meeting Agenda for 4/7/95 Bridge: Res: (916) 356-9999 461605 All meetings are 8:00 AM to 10:00 AM Pacific Time (16:00 to 18:00 UTC). When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the reservation number. 8:00 Check-in, Intros, Announcements Hobbs - Intros of new IBIS participants - Review of previous meeting's minutes (and ARs) - Miscellany/announcements/treasurer's report - Opens for new issues - Press updates - New models available 8:20 Progress toward enlisting new IC vendors All 8:45 Golden Parser 2.1 status Hobbs - IBIS filename case resolution Hobbs - Tabs and Control-Ms in .ibs files Arpad - Advanced package options Ross - Release date Hobbs - Other issues 9:00 EIA Status Hobbs - Affiliation/sign-up letter Duehren - Progress toward balloting Duehren Plans for IBIS Meeting at DAC (June12-16) Hobbs Thurs, 6/15/95, 8:30 - 1:00? Rev 2.1 updates Hobbs o S2IBIS 2.1 o Cookbook o Overview 9:20 SGML/HTML support? Huq New Keyword for Differential I/O Ward Enhancements to the Timing Spec Peters Diode Transit Times ??? Directions for MCM ??? Advanced Package Options ??? 9:55 Wrap-up, next meeting plans Hobbs