Description: INFO-FRAME, Vol. 1, Issue 4-88 From: MRGATE Date: 16-AUG-1988 22:52:44 From: CSBVAX::MRGATE!mcdonald%loki.edsg@hac2arpa.hac.com@SMTP Received: from loki.edsg (mcdonald) by hac2arpa.hac.com (3.2/SMI-DDN) id AA09391; Tue, 16 Aug 88 17:47:11 PDT Received: by loki.edsg (4.12/E53-DOMAIN-RING) id AA02678; Tue, 16 Aug 88 17:13:52 pdt Date: Tue, 16 Aug 88 17:13:52 pdt From: mcdonald%loki.edsg@hac2arpa.hac.com (louis mcdonald) Message-Id: <8808170013.AA02678@loki.edsg> Company: Hughes Aircraft; El Segundo, CA 90245 To: info-frame-list%loki.edsg@hac2arpa.hac.com Subject: INFO-FRAME, Vol. 1, Issue 4-88 INFO-FRAME, Vol. 1 Issue 4-88 Tuesday, August 16th 1988 Today's Subjects: Framework News Re: Configuration Management in software development environment Oct, VEM, and RPC: A CAD Tool Framework CAD Framework Initiative News OA thoughts Generic JCL High/Low resolution menu interface ==================================================================== ``Stay aware and be informed'' %%% %%% Moderator's Note: %%% I will be on vacation from Aug 19 - Aug 31. Digests of %%% INFO-FRAME will continue when I get back. However, keep %%% those cards and letters coming in...... %%% ---------------------------------------------------------------------- Date: Tue, 16 Aug 88 09:38:35 pdt From: info-frame-new%loki.edsg@hac2arpa.hac.com Subject: Framework News (mag) DEC Professional - August 1988 `The Super Standard' - Provides background on X/Open and OSF. Seems like good introduction material. (mag) IEEE Computer - August 1988 `Software Engineering Standards' - - A number of trends are emerging in software engineering that offer opportunities for meaningful standards development. The trends are creating additional challlenges for engineering standards developers. ------------------------------ Date: Fri, 12 Aug 88 09:29:20 CDT From: DERSTAD@cim-vax.HONEYWELL.COM Subject: Re: Configuration Management in software development environment The Apollo tool equivalent to CMS is the Domain Software Engineering Environment (DSEE). We have been using DSEE for many years, and are very pleased. Lately, Apollo has been making some noises like they might be providing more support for heterogenous build environments. For example, a flashy marketing brochure called "Network Computing" indicates they demo'ed such a capability at several conferences. >From what I've been able to determine, this is more a coming attraction than a here and now capability. Still, they are the only vendor I know of seriously addressing this problem. This produces several possible options to the VAX/Apollo problem. One approach (the one we are presently implementing for some of our software) is to control all software development from the Apollo's, and use FTP and RSH type capabilities to shoot the files off, build them, etc. (DSEE build rules are very flexible - they can do almost anything). This works, of course, only if you want the Apollo as the development interface. I'm not aware of a good solution for handling check-outs to another machine, except to possible set up access restrictions of some type and build controls to prevent people from modifying non-checked out version, but this would be somewhat clumsy. ------------------------------ Subject: Oct, VEM, and RPC: A CAD Tool Framework Date: Fri, 12 Aug 88 10:02:41 -0700 From: Rick L. Spickelmier Oct, VEM, and RPC: A CAD Tool Framework Oct, VEM, and RPC form the framework for the Berkeley Design Environment [1]. The framework is designed to allow the integration of CAD tools across many technologies, levels of abstraction, and styles of design. Oct is a data manager for VLSI CAD design data. Oct is designed to be extensible: it makes very few assumptions about the kind of data to be stored. Instead it implements a few basic object types, a general mechanism for relating objects to one another, and a small set of generic operations on these objects. The set of operations insulates the user from the internals of Oct and changes in the data structures and algorithms, and protects the data from accidental corruption by the user. Higher-level layers can implement a particular design style on top of the Oct procedural interface. This allows experimentation with differing representations without requiring modifications to the underlying database. VEM is a graphics browser and editor for Oct. The primary goal of VEM is to provide a highly interactive graphics environment for viewing and editing Oct data. VEM works directly off of the Oct database and provides the higher-level abstractions necessary for the editing styles VEM supports (currently: mask-level, symbolic, and schematic). Furthermore, VEM is a highly extensible editor, allowing easy integration of new editing features and CAD tools (via RPC). VEM is written on top of the X window system (release 10). The Remote Procedure Call package, RPC, allows CAD tools to be controlled from VEM, but run as separate processes, possibly on different machines and written in different languages. This allows allows a designer (or design manager) to exploit a network of machines and select a machine for running the tool based on the needs of the tool and the load of the various machines on the network. By running as separate processes the editor is protected against tool malfunctions that could corrupt the editors address space or cause the editor to abort. The Oct/VEM/RPC framework is being used both in research and in graduate-level courses at Berkeley and other Universities. It is also being used at various industrial sites and consortia. There are over 60 tools integrated into the framework, along with many systems (macro-cell place and route, standard-cell place and route, digital signal processor synthesis, opamp synthesis, switched- capacitor synthesis, sea-of-gates place and route, etc.). [1] D. Harrison, P. Moore, R. Spickelmier, and A. R. Newton, ``Data Management and Graphics Editing in the Berkeley Design Environment,'' Proc. IEEE ICCAD '86, Santa Clara, CA. ------------------------------ Date: Mon, 15 Aug 88 15:34:31 pdt From: Tony Zingale Subject: CAD Framework Initiative News August 15, 1988 To: Info-Frame Readers From: Tony Zingale/EDA Systems Subject: CAD Framework Initiative I have noticed a number of questions and bullitens regarding the CAD Framework I nitiative (CFI) effort. Let me give you some background on the CFI since I was personally involved in the formation of the effort and sit on the Steering Committee for ED A Systems. The first meeting of the CFI was held in Santa Clara, CA on May 26-27 and was at tended by over 100 individuals representing 38 different companies. The purpose of th e meeting was to rally support from the industry (CAD/CAE vendors, CAD/CAE users, computer platform suppliers, ASIC manufacturers) around the need for a set of in dustry acceptable guidelines for design automation frameworks which will enable the coexistence and cooperation of a variety of design tools. A steering committee was elected by the group present at the initial meeting tha t included EDA Systems, Inc., Motorola, Inc., Digital Equipment Corporation, Cadence Design Systems, Mentor Graphics, Valid Logic Sytems, Honeywell, Inc., Microelectronic and Computer Technology Corporation (MCC), and Hewlet-Packard, I nc. The steering committe has a six month charter to formalize support for the CFI a nd to explore synergistic relationships with related activities such as the Air Force Engineering System (EIS) program and Open Software Foundation (OSF). Two Steering Committee meetings have taken place since the May meeting, with two addtional meetings scheduled for September and October. A CFI update and the next open technical session will be held during the ICCAD Conference, November 7-10 in Santa Clara, CA. In the meantime, if you are interested in getting on the CFI mail list please contact Andy Graham (CFI steering committee chairman) at Motorola (602)821-4180 or Ken Roberts at Motorola (602)821-4446. ------------------------------ Date: Mon, 15 Aug 88 19:06:35 PDT From: lmm <"HAL::MCDONALD"@rsgate.RSG.hac.com> Subject: OA thoughts Currently, when doing proposal work, our team members work on a variety of hosts; VAX/VMS, Macintosh, IBM PC and Apollo (Aegis). The BIGGEST problem we have is integration of the document from the different sources. We are investigating some sort of office automation environment that lets us: o Allow the user on each host to stay with his/her current WYSIWYG or text formatter. They are - RUNOFF on VAX/VMS - TeX and NROFF on Apollo - Microsoft Word on IBM and MAC o All drawings are done with MacDraw o Final integration will be TeX on the Apollo with Postscript as the printout format. To further automate this environment, I want to assume that the VAX, IBM PC and Macs are slave hosts. That is, all integration is done from the Apollo side. This environment has the ability to `logically' point to pieces of the proposal (text and pictures) on the other systems. At some point, the integrater can `get' all pieces from the slave hosts. This implies that the Apollo has network access to all these slave hosts. Questions that arise: o Should the inputs from the slave hosts already be in a format acceptable for integration (i.e. MW already in a TeX format and RUNOFF in a TeX format. Pictures in Postscript format) o If the above item does not have to necessarily be TRUE, is there a known way to execute a job from the Apollo to each slave host to translate the data? The basic goal is to allow each team member to work in his/her native environment, but allow the integrater an easy means of pulling all the pieces together. Big Mac hal!mcdonald!rsgate.ether@hac2arpa.hac.com ------------------------------ Date: Mon, 15 Aug 88 19:15:52 PDT From: lmm <"HAL::MCDONALD"@rsgate.RSG.hac.com> Subject: Generic JCL In our quest of automating some process control flow, we have looked upon the idea of a generic job control language. The idea is to allow a user to group one or more tools together with this language, have it run through a filter, and output the correct JCL for the target host. This language would support not only stepwise execution, but parallel, have conditional loops/steps, and support execution across hetergeneous environments. This makes it easy for a user to use the suite of tools on a new host. He/She does not have to learn all the tricks of the systems JCL in order to get the job done. Just run this generic JCL through a filter, and out pops the system specific JCL to get the job done. This is still on the blackboard (or in the blue sky), has anyone else thought about this concept? Big Mac ------------------------------ Date: Tue, 16 Aug 88 16:33:30 PDT From: lmm <"HAL::MCDONALD"@rsgate.RSG.hac.com> Subject: High/Low resolution menu interface Our current user environment crosses both workstation and VT terminal (i.e. high resolution and low resolution). We are building a simple menu/forms interface that can work on both the workstation and the VT terminal. The workstation platforms are Apollo and Sun, and the VT terminal platform will be VT100/220 on VAX/VMS. Our goal is to all the user interface to take advantage of the platform it is running under, and provide the same functionality. The menus are simple slide bar and popups. The forms are simple `fill in the field'. We want to make the user interface applications portable, so we have a *crude* menu/forms definition language that sets up what the interface looks like. We are willing to use CURSES for the VT interface, and maybe use X windows for the Apollo/Sun interface (other suggestions are welcomed). My general question is: Has/Does anyone else looked into this set up? I cannot believe we are the only ones how have a user community that is set up like this. :-) o What are the pitfalls, problems? o Is there a better approach? o I want to minimize the amount of host dependent code to one or two simple .H files. Big Mac ------------------------------------- %%% %%% Additions/Deletions/Corrections to list should be addressed to: %%% info-frame-request%loki.edsg@hac2arpa.hac.com %%% %%% Contributions/Questions/Answers to digest should be addressed to: %%% info-frame%loki.edsg@hac2arpa.hac.com %%% %%% News bulletins should be addressed to: %%% info-frame-news%loki.edsg@hac2arpa.hac.com %%% %%% Moderator: Louis McDonald; Hughes Aircraft - 213-616-3134 %%% mcdonald%loki.edsg@hac2arpa.hac.com %%% The views expressed in INFO-FRAME are those of the individual authors only. ********************* End of INFO-FRAME *********************