- Email: [email protected]
Future applications of a full capability engineering work station
0026-26921841150243030 $5.00/0
Future applications of a full capability engineering work station by Les Holland Motorola Semiconductor Products, Mesa. Arizona 8 5 2 0 2 , USA
This paper is written to articulate for the user and developer community several important design requirements for a full capability engineering work station (EWS). The viewpoint presented is that of a broad-line merchant semiconductor manufacturer.
1.
Introduction
The design of multi-million transistor chips requires that the design team have rapid, one-terminal access to all the design data (system specifications; block, logic and transistor level schematic diagrams; plus mask layout graphics) together with access and fast turnaround response from logic simulation, circuit analysis, interconnect checking and design rule checking software. As we exceed the limit of being able to breadboard new designs, the EWS will be the "electronic workbench" that allows engineers to view logic signals and analog waveforms from computer simulations. The hardware necessary to implement an EWS exists; what's lacking is highly functional, easy-to-use sol, ware that accesses a well-managed, integrated engineering design database. The foundations for such a system outlined in this paper include the need for:. (i) public, flexible data formats with the ability to do powerful editing functions; (ii) the system to manage and control design changes and updates (even throughout multiuser, multi-site installations); (iii) work lists of yet-to-be-completed tasks; and (iv) a highly human engineered man-machine interface that supports log analysis and flexible forms of fast, accurate input. These ideas are a starting point for discussions while there's still time for users and developers to talk. The results of these open communications can assure a more useful EWS. A lack of dialog will result in numerous, non-compatible and low functionality systems. The requirements for a full capability engineering work station that will serve the needs of a broad-line merchant semiconductor manufacturer are diverse. We are a number of businesses ranging from discrete devices (small signal transistors, power devices, RF transistors) through VLSI products (MOS and bipolar logic arrays, microprocessors, RAMs and ROMs). These products are produced in a number of technologies: CMOS, NMOS, and numerous Bipolar processes (TTL, LS, ECL, MMT, MOSAIC, and Linear). Our needs range from low volume R&D circuits, government contracts and test vehicles (where fast design time is paramount) to RAMs and ROMs (where every square mil of silicon means thousands of dollars in terms of throughput and yields). The 1990's will bring multi-million device chips and will require design productivity increases ofmore than one order ofmagnitude. We cannot meet the need for a I0 to 100 times productivity increase by trying to coax a few more percentage points of productivity from one or more phases of the design cycle. Indeed, the needs for automation transcend the design phase into pilot runs and high volume production to allow these areas to perform trend analysis and to modify the original design data as may be necessary to improve yields or performance. 30
MICROELECTRONICS JOURNALVo115 No 2 9 1984 Benn Electronics Publications Ltd, Luton
Thus, the engineering work station needs of a broad-line merchant semiconductor manufacturer are a super-set of most other needs. We encompass all technologies; we design complete, multi-chip systems; we perform fast turnaround, custom, low volume designs; and finally (and increasingly important) we interface closely with our customers who are also doing numerous designs in each of the above areas. More and more IC's are being designed by the customer in such areas as automotive, entertainment, photographic, communications, data products and computers. The highly popular gate array products allow even the small customer to rapidly design his own proprietary IC for his high technology product. For volume productions, these designs are transferred to semiconductor manufacturers. 1.1 What is an engineering work station? Some definitions are in order to delimit the issues for future debate. In the months ahead, it will be very popular to claim that a system is an engineering work station. Work station: A term used by personnel, administrators, and non-engineering managers to define a specific work location. The term includes office, cubicle, desk, computer console, table, drafting table and other locations where a person might work while sitting or standing. A work station is often shared when expensive equipment is involved (such as two or three shift production operations). Excluded are halls, aisles, meeting rooms, cafeteria, break areas, dark rooms and all other out-of-plant locations. Engineering work: The various tasks that engineers are paid to perform. Included are design, analysis, communication, breadboarding, documentation, de-bug efforts, testing, planning, organising, programming and other tasks producing sweat from mental effort. Design and analysis,- the traditional tasks for which engineers are educated, account for only 15 to 25 percent of an engineer's work day. Excluded are games, vacations, eating, sleeping, exercise and other physical activities. Engineering work station: Also known as the personal engineering computer, the (hopefully) low-cost designer station, or the database access and modification terminal. An EWS is that combination of raster graphics hardware and software for use by an engineer to aid his productivity in the conduct of his efforts. The EWS provides extensions (by way of computer power and memory) to the engineers' abilities and interfaces his ideas to other computers, an engineering design database, and various output devices that effectively process information in the form of standard engineering documents (drawings, charts, graphs, schematics, specifications and other high level graphics). The key to a full capability EWS is software that is highly functional and easy to use. 1.2 Why engineering work stations? The addition of an EWS to the set of available design tools will help to facilitate communication among the design team, to compile all the appropriate design information in one place, to bring the power of computers to those who have designed computers, to keep track of the massive amounts of data associated with the design process, but most important--to increase productivity. Getting designs completed faster and more error free requires giving each member of the design team the customised tools to aid his work, to extend his capacity, to amplify his abilities. There is a point at which adding members to the design team will not reduce the design time. In some cases, we are already beyond this point. Why is this new tool necessary for LSI and VLSI design? Because, other methods haven't worked to the degree necessary. Our history with computers as aids to engineers dates back into the 1960's with primitive circuit analysis models, 2-state logic simulators, and punch-card based computer graphics systems. There were various in-house software and system development activities to aid portions of the design process. While some of these efforts were quite successful, they tended to be expensive to maintain (or complete) and limited as to extensions across the parameters of complexity, design size, and process technologies. 31
Future applications of a full capability engineering work station continued from page 31
Also, the tasks of interfacing numerous pieces of software into a system is a thankless undertaking which usually takes longer than planned so that it fails to meet the schedules of those who will use the resulting system. Recent efforts have shown the need for a strong central engineering design data base containing all the relevant information to be accessed by members of the design team. Alphanumeric terminal access is not sufficient: graphics is the language of design. The value of graphics increases the speed and accuracy of engineering communications. Whether the information is input specifications (in the form of block, logic or transistor level schematic diagrams); intermediate information (in the form of analog waveforms for voltages and currents, digital signals as a function of time, or diffusion profiles for model analysis); or output information (in the form of interconnect lists or layout graphics)--graphics is the communication medium. Indeed, graphics makes it possible for the design team to communicate with computers in terms understood by both the man and the machine. 1.3 Reasons for buying an engineering work station Often the purchase of a new type of computer system is justified as the only way possible to complete a portion of the IC design task. This was the case for interactive computer graphics systems where the ability to generate a magnetic tape for pattern generators (either optical or electron beam) and the ability to manage large amounts of graphical data for mask layout made the systems a necessity. Similar arguments can be made for logic simulators, circuit analysis programs, and (more recently) design rule check and interconnect check programs. If you're serious about doing IC designs, some forms of these tools are a necessity. In other cases, the use of computer aids is a choice (and a very expensive choice). Printed circuit boards (PCBs) are an example where over 50% of new and modified designs are handled manually (using rubylith, hand taping, photographic, or stick-off techniques). Some PCB work utilises partial " C A D " such as a grease pencil layout to on-line design or the method of draw plus digitize and edit. Few designs (as an overall percentage) use automatic place and/or route CAD tools. For PCB designs in the computer industry, however, the utilisation of CAD tools is well established as the only way to get the job done. The EWS closely parallels the PCB area in that most IC designs can be completed without the use of an EWS. However, if the functionality versus cost ratio is favourable, (if the system really performs as advertised) then more and more ICs will be designed utilising the capabilities of an EWS. For LSI and VLSI designs theremay be no choice; ifthe design is to be completed to meet the market window for a product, the use of a full capability EWS may be a necessity. Sometimes the purchase of a system is a policy decision or (more simply), it's fashionable. Everyone wants one, or needs one to be assured that indeed his job is as important as all the others. (Case in point: Colour raster graphics terminals over 19" green storage CRTs over 11" green storage CRTs.) 1.4 Hardware, software costs of system development The development of an EWS as a product will parallel software development systems (and these are in serious trouble). There are few standards within the various tools available for software development. Each editor, language, debugger, system monitor, command syntax and file control system differs as a function of what hardware and/or operating system it was developed for. Current estimates are that hardware represents only 30% of new system costs with software being the major cost factor at 70%. Trends indicate the software portion may climb to 80% in the next five years. Also, software maintenance is extremely expensive and is often done by less experienced, less motivated workers than those who implemented the original routines. With high-performance hardware becoming available and with the strong needs of the design community, is it reasonable to hope for a degree of sameness of functions as EWS systems are developed. 32
2.
Foundations for an E W S
2.1
Public formats to be complete--flexible--compatible
The lessons to be learned from the development history of interactive graphic systems should be well known and recognised by developers of engineering work stations. Various interactive graphics vendors followed divergent paths: (i) Core, disk, and magnetic tape data formats were identical, documented, made available to users, and (with a few minor exceptions) upward compatible over a ten year period. (ii) Different (and proprietary data formats were used for core, disk, and magnet tape. An "external" magnetic tape format was defined in both binary and ASCII (with several versions). It should be no surprise that the first vendor's format became an informal industry standard. In fact, it is possible to translate layout graphics from vendor X's format to vendor Y's format using the first vendor's format as the interchange medium! The lesson: If data formats are stable and made available to users, the value and number of functions generated by users (both on the system and on other off-line systems) will increase the system acceptance by the user community. The converse is also true: If users are forced to deal with slow-to-generate, ever-changing external formats, the value of the system to the user community is reduced. All of the above fails to address the fact that the only information that can be reasonably converted between systems (and formats) is that which is common among systems. In the case of interactive graphics systems, this consisted of rectangles, polygons, paths, and subfigures. When any of the extremely useful features of any one system (such as stretchable cells, unlimited text fonts, font scaling, true arcs, nodal cells, text nodes, snap nodes and multiple data types or bins) are utilised, it becomes difficult or even impossible to generate an accurate one-toone conversion of the data. One method to prevent a recurrence of this nightmare (or at least reduce its effect) will be for the various developers of an EWS to include more features in their original data formats (even allowing for un-implemented functions or providing hooks for future additions) and to clearly understand the users need to be able to accept designs generated on different systems. Here the merchant semiconductor manufacturers bear the brunt of having to accept customer designs from a number of system's, so we feel the need to simplify (or eliminate) difficult and time consuming conversion tasks. 2.2
Change and update control: a foundation for the data
Current systems offer little to facilitate update control: (i) Copy the file or named sub-structure and then modify the copy. (The system usually maintains no more than five previous versions because of storage limitations.) Often there is no difference between two (or more) backup copies. (ii) Re-name the file or substructure. (This necessitates a manual record keeping of old name, new name, reason for the change, plus having to remember to delete un-needed versions, copies, or names later. (iii) Copy of existing data to another media (floppy disk or magnetic tape) which also requires extensive manual bookkeeping. Having "extra" backups actually generates a false sense of security; the system should keep track of what-is-where. The actual data differences between sequential versions ofthese numerous copies range from zero to only a few percent of the total data content. There is a better way. Maintain the data with fields to show the date and time of additions, deletions, and the command or function. An analogy is a 5000 person payroll file with 33
Future applications of a full
capability engineering w o r k station continued from page 33
numerous updates. What is most often of concem is who was added or deleted in a particular time period of interest. Likewise, engineering data can be handled in a method flagging additions and deletions where A - B + C = D . A is the previous file; B represents any deletions; C represents any additions; and D is the current file. Any modifications can be handled as deletions plus additions. The value of having date-time plus function allows another very useful feature: reversing (or the un-do) of a function at any later time (assuming subsequent modifications have not been made) or the ability to flag the fact that an un-do cannot be automatically completed and the reason (such as a trace of what data has undergone subsequent modification). An example: most graphics systems include an explode or smash function. This removes a reference to a subfigure and inserts as exploded data the contents of the subfigure processed through the placement transform (x and y shifts, rotation, mirror, scaling, etc.) The value ofthis function is unquestioned: it allows a designer to make one-of-a-kind modifications to a standard subfigure. The danger of using the function is extreme: subsequent edits to the subfigure do not propagate throughout the hierarchy of previous references. Each previously exploded occurrence must be individually edited manually. Furthermore, there is no available record of where data currently exists from a particular explode. Despite classroom warnings to always be careful with explode, it all to frequently happens that the need to un-explode arises. The above proposed data structure solves this problem by maintaining information on what was exploded, and the reverse operation is now quite simple. Other useful information to include in the data for history purposes is when major operations are performed such as DRC, P G outputs, layer sizing, shape merging, model extraction, wire list extraction, and off-system backup copies generated. The existence of a small amount of additional information (in the add and delete fields) has another useful function: it simplifies the comparison of data between two backups. It is not necessary to perform a global explode and a total graphical exclusive--or to generate the changes in a useful form. Indeed, the changes expressed in hierarchial form are usually more valuable than the changes in the global, exploded formats. This compare feature is a foundation requirement for analysis of engineering design data. Design, by its very nature, requires extensive editing, additions, and a return to "the way it was when it last worked". If the computer does not or cannot facilitate the bookkeeping of this data, then the computer can often be more a burden than a help. Another useful column in the add and delete fields might be "Why*." But only after we have the basic capability can we intelligently outline a further need and determine its realistic value. In summary, the data base system must support the following operations: (i) comparisons of data between any two times or any two operations; (ii) the un-do of functions--return to the way it used to be; (iii) trial operations; (iv) prevent the need for manual bookkeeping; (v) version control without the need to generate multiple copies of files; and (vi) dual edits (either by using the system's graphics editor or by text edits of a manreadable file).
2.3 Software evolves as needs are defined Examples of successful software includes many systems where the problem is short-term and clearly defined. These include process control, smart traffic lights, and electronic telephone exchanges among others. Where the task is long term (like design projects of 6 to 18 months) and where manual intervention must be allowed (remember Three Mile Island.*), the task of 34
generating successful software is vastly more extensive and the results are not always successful. Also, there is a tendency to forget a basic rule of software: a task must be bounded and well-defined before it can be automated or any software solution can be implemented. Examples of design automation software shortcomings abound. A system questioning a user "Are you sure?" is guaranteed to delay the function for a few seconds.Thereis no guarantee that a thoughtful reconsideration of the function occurs. Powerful, one-way (non-reversible functions) are rampant. In actuality, engineering tasks consist of many "What i f . . . " or "Let's try it" situations. If a system does not support temporary functions, then it does not allow the engineer to work in his familiar ways. Two classes of successful software include those where the function is extremely well defined (and the user can chain functions together) and more complex functions where no manual intervention is allowed. Even route and place algothrims can be implemented until a user demands the ability to pre-route portions, or assist or improve parts of the intermediate results. Software to handle these "assists' is more complex, but its need should be recognised from the beginning. Successful engineering software often is the result of three or four major re-writes (with easy integration of improvements) versus trying to patch and improve an older generation system without a solid base. History also shows that a solid base can support the easy addition of new features with little impact to other routines and data structures. 2.4
Work lists of tasks
A basic feature of engineering stations is the need to maintain work lists oftasks that need to be done. These can be a list of changes made in a logic level diagram that must also be made in a physical (layout graphics) level. These lists allow the man and the machine to work more closely in a more natural relationship. The tendency is for computer programs to expect that all information is current and correct. In reality, there are usually a number of items (from complete blocks to individual interconnects) that are not consistent between the various pieces of a design. This is especially true where the design consists of several equivalent forms (block level, logic diagram level, transistor schematic level, layout graphics, hardware breadboard). The design support system should recognise the differences in these various forms rather than making the incorrect assumption that all forms are equal and correct. Design changes simply do not occur in lockstep fashion. 2.5 Different forms of design data Another need for an engineering work station is the ability to compare logic implementations in different forms: a gate level logic diagram may be converted into several transistor level schematics diagrams as a function of whether the implementation is to be in MOS, TTL, or ECL. This is necessary because each technology provides some functions "free" (such as wired-or, wired-and, multiple inputs, XOR and transmission gates) while other technologies require added components to implement a particular function. Some of the rules for converting logic are clear;, others require extensive manual efforts. 2.6
Multi-user, multi-site update resolution
Arbitration and resolution of multi-user, multi-site design changes need to be managed by the EWS. This requires a high speed communications link between stations and between sites. Current costs for long distance communications at speeds above 9600 baiad often exceed the hardware costs of the EWS. Resolution of changes consists of allowing multiple users to make changes that are mutually exclusive: engineer A can change the input buffers; engineer B can change the random logic; and engineer C can change the ROM programming. After file comparisons (utilising the date-time 35
Future applications of a full capability engineering work station continued from page 35
flags), the differences can be transmitted to each site for inclusion into that copy of the design. Messages at the next user session indicate the extent of the changes and who made them. When changes are detected that are not mutually exclusive (engineer A at one site has changed the input buffers; and engineer D at another site has also changed the input buffers), then the system can flag what has occurred. In this case, either set of changes can be accepted and then the other set of changes can be repeated on the new data. This also provides an extremely valuable communications function.There tends to be more careful planning and co-operation if designers are aware that the task is being overseen with attention to the most minute details. The computer may not guarantee that all the data is always accurate, but it causes designers to be more careful in their tasks. A healthy environment of "Someone really cares" and " I ' m smarter than any machine" allows the designer to compete with the machine on a friendly, non-threatening basis which results in a better f'mal design. The element of competition sets up a Win-Win situation for all members of the design team. 2.7 Log, playback, and log analysis An E W S should support a logging function and a playback of the log (or portions ofit) on either original or different data. This can be extremely effective in tracking down problems: is it a cockpit problem (the user did the wrong thing), a software problem (those last few bugs are quite elusive), or is there a problem in the interaction of the software function and this particular set of data ("Oh, what you really want in this case is different from what the software currently generates"). The playback function will also be useful in early training and demonstrations (and if it aids the functions of marketing, it must surely be of some value to a used). After a log is generated, a log analysis function is needed. This will indicate which commands and functions need to be improved, combined, repaired or eliminated. Also, it will allow managers to determine which users are most efficient in using the system, which need additional training, and which few should not be using the system (due either to carelessness, lack of understanding, or a complete waste of time and resources). A log function without log analysis is like marriage without sex: relationships may continue, but there's no hope for a future generation. 2.8 Flexible forms of input A system should accept multiple forms of user inputs: keyboard commands, macros, menu, programmable menus, hierarchical menus. The key to utility is some simple form of input (such as a structured menu) for the beginner or casual user and a more sophisticated form of input (such as type ahead with edits and programmable menus) for the most advanced user. The system should not reduce the speed of input for the more advanced user by requiring him to wait for prompts, menus, questions, or unusual cases which alter the input required. A further aid to fast, accurate system usage is a good system ofdefaults and modal values that are preset (or remembered from the last usage). User defined macros can allow command chaining for particular cases that occur often. Just as the system supports and encourages hierarchical design, the system should support higher levels of building blocks in the use of system functions. This will be possible if each function is clearly defined and is as independent (as possible) from other functions.
3.
Conclusions
So where are we? The engineer will accomplish his design task with whatever tools are made available to him. If usage of a particular system is mandated, he will use it as best he can (or quit ifthe battle is too st~'enuous). I f a system is made available on a " T r y it" basis, he will use it--if it's learning efforts are reasonable and the functions performed are of sufficient value. For a unified design support system, an engineer will offer numerous requests for new or 36
different functions. Here lies the real road to success: listen to the users ~needs and solve them in a co-operative manner. Such a system will result in increased usefulness to the user and the number of systems in use will increase as the word of their value spreads. The use of early, less-than-complete systems or systems fitting a narrow market need is acceptable if the value-of-use exceeds the costs (efforts to learn and use, time, dollars--in this order). Successful examples of narrow systems include interactive computer graphics systems, D R C sol, ware, logic simulation, circuit analysis programs, and first generation engineering work stations that perform schematic capture as their basic function. 3.1
Where not to cut corners
Since hardware is changing faster than software (and becoming as costly too) it is extremely important that functional software be generated so that it can migrate forward over several future generations of hardware. This will allow a developer to take advantage of cost reductions in microprocessors, memories, disks, hardware function boxes for such applications as routing, logic simulation, matrix operations on graphics, database hardware, and other just-around-thecomer functions. Ifa system is optimised around a specific hardware configuration (limited core, disk or even a specific microprocessor) its future may be dim. The more successful analysis, simulation, and checking software packages currently run on a number of hardware configurations, and no less should be expected of software that creates an engineering work station. So where can comers be cut? Implement fewer functions rather than implement incomplete functions. Solve a problem correctly the first time rather than rewrite or patch software due to incomplete specifications. Rush a product to market and it may be like a flashbulb--very short lived. It is essential that developers listen to users, customers, potential customers and critics. The messages may seem strong, diverse, confusing. Ifso, seek more information to clarify the details rather than rush ahead with no clear destination in mind. If user needs seem to be totally different, then maybe the common points of those needs are not clearly defined and understood.
37
Future applications of a full capability engineering work station by Les Holland Motorola Semiconductor Products, Mesa. Arizona 8 5 2 0 2 , USA
This paper is written to articulate for the user and developer community several important design requirements for a full capability engineering work station (EWS). The viewpoint presented is that of a broad-line merchant semiconductor manufacturer.
1.
Introduction
The design of multi-million transistor chips requires that the design team have rapid, one-terminal access to all the design data (system specifications; block, logic and transistor level schematic diagrams; plus mask layout graphics) together with access and fast turnaround response from logic simulation, circuit analysis, interconnect checking and design rule checking software. As we exceed the limit of being able to breadboard new designs, the EWS will be the "electronic workbench" that allows engineers to view logic signals and analog waveforms from computer simulations. The hardware necessary to implement an EWS exists; what's lacking is highly functional, easy-to-use sol, ware that accesses a well-managed, integrated engineering design database. The foundations for such a system outlined in this paper include the need for:. (i) public, flexible data formats with the ability to do powerful editing functions; (ii) the system to manage and control design changes and updates (even throughout multiuser, multi-site installations); (iii) work lists of yet-to-be-completed tasks; and (iv) a highly human engineered man-machine interface that supports log analysis and flexible forms of fast, accurate input. These ideas are a starting point for discussions while there's still time for users and developers to talk. The results of these open communications can assure a more useful EWS. A lack of dialog will result in numerous, non-compatible and low functionality systems. The requirements for a full capability engineering work station that will serve the needs of a broad-line merchant semiconductor manufacturer are diverse. We are a number of businesses ranging from discrete devices (small signal transistors, power devices, RF transistors) through VLSI products (MOS and bipolar logic arrays, microprocessors, RAMs and ROMs). These products are produced in a number of technologies: CMOS, NMOS, and numerous Bipolar processes (TTL, LS, ECL, MMT, MOSAIC, and Linear). Our needs range from low volume R&D circuits, government contracts and test vehicles (where fast design time is paramount) to RAMs and ROMs (where every square mil of silicon means thousands of dollars in terms of throughput and yields). The 1990's will bring multi-million device chips and will require design productivity increases ofmore than one order ofmagnitude. We cannot meet the need for a I0 to 100 times productivity increase by trying to coax a few more percentage points of productivity from one or more phases of the design cycle. Indeed, the needs for automation transcend the design phase into pilot runs and high volume production to allow these areas to perform trend analysis and to modify the original design data as may be necessary to improve yields or performance. 30
MICROELECTRONICS JOURNALVo115 No 2 9 1984 Benn Electronics Publications Ltd, Luton
Thus, the engineering work station needs of a broad-line merchant semiconductor manufacturer are a super-set of most other needs. We encompass all technologies; we design complete, multi-chip systems; we perform fast turnaround, custom, low volume designs; and finally (and increasingly important) we interface closely with our customers who are also doing numerous designs in each of the above areas. More and more IC's are being designed by the customer in such areas as automotive, entertainment, photographic, communications, data products and computers. The highly popular gate array products allow even the small customer to rapidly design his own proprietary IC for his high technology product. For volume productions, these designs are transferred to semiconductor manufacturers. 1.1 What is an engineering work station? Some definitions are in order to delimit the issues for future debate. In the months ahead, it will be very popular to claim that a system is an engineering work station. Work station: A term used by personnel, administrators, and non-engineering managers to define a specific work location. The term includes office, cubicle, desk, computer console, table, drafting table and other locations where a person might work while sitting or standing. A work station is often shared when expensive equipment is involved (such as two or three shift production operations). Excluded are halls, aisles, meeting rooms, cafeteria, break areas, dark rooms and all other out-of-plant locations. Engineering work: The various tasks that engineers are paid to perform. Included are design, analysis, communication, breadboarding, documentation, de-bug efforts, testing, planning, organising, programming and other tasks producing sweat from mental effort. Design and analysis,- the traditional tasks for which engineers are educated, account for only 15 to 25 percent of an engineer's work day. Excluded are games, vacations, eating, sleeping, exercise and other physical activities. Engineering work station: Also known as the personal engineering computer, the (hopefully) low-cost designer station, or the database access and modification terminal. An EWS is that combination of raster graphics hardware and software for use by an engineer to aid his productivity in the conduct of his efforts. The EWS provides extensions (by way of computer power and memory) to the engineers' abilities and interfaces his ideas to other computers, an engineering design database, and various output devices that effectively process information in the form of standard engineering documents (drawings, charts, graphs, schematics, specifications and other high level graphics). The key to a full capability EWS is software that is highly functional and easy to use. 1.2 Why engineering work stations? The addition of an EWS to the set of available design tools will help to facilitate communication among the design team, to compile all the appropriate design information in one place, to bring the power of computers to those who have designed computers, to keep track of the massive amounts of data associated with the design process, but most important--to increase productivity. Getting designs completed faster and more error free requires giving each member of the design team the customised tools to aid his work, to extend his capacity, to amplify his abilities. There is a point at which adding members to the design team will not reduce the design time. In some cases, we are already beyond this point. Why is this new tool necessary for LSI and VLSI design? Because, other methods haven't worked to the degree necessary. Our history with computers as aids to engineers dates back into the 1960's with primitive circuit analysis models, 2-state logic simulators, and punch-card based computer graphics systems. There were various in-house software and system development activities to aid portions of the design process. While some of these efforts were quite successful, they tended to be expensive to maintain (or complete) and limited as to extensions across the parameters of complexity, design size, and process technologies. 31
Future applications of a full capability engineering work station continued from page 31
Also, the tasks of interfacing numerous pieces of software into a system is a thankless undertaking which usually takes longer than planned so that it fails to meet the schedules of those who will use the resulting system. Recent efforts have shown the need for a strong central engineering design data base containing all the relevant information to be accessed by members of the design team. Alphanumeric terminal access is not sufficient: graphics is the language of design. The value of graphics increases the speed and accuracy of engineering communications. Whether the information is input specifications (in the form of block, logic or transistor level schematic diagrams); intermediate information (in the form of analog waveforms for voltages and currents, digital signals as a function of time, or diffusion profiles for model analysis); or output information (in the form of interconnect lists or layout graphics)--graphics is the communication medium. Indeed, graphics makes it possible for the design team to communicate with computers in terms understood by both the man and the machine. 1.3 Reasons for buying an engineering work station Often the purchase of a new type of computer system is justified as the only way possible to complete a portion of the IC design task. This was the case for interactive computer graphics systems where the ability to generate a magnetic tape for pattern generators (either optical or electron beam) and the ability to manage large amounts of graphical data for mask layout made the systems a necessity. Similar arguments can be made for logic simulators, circuit analysis programs, and (more recently) design rule check and interconnect check programs. If you're serious about doing IC designs, some forms of these tools are a necessity. In other cases, the use of computer aids is a choice (and a very expensive choice). Printed circuit boards (PCBs) are an example where over 50% of new and modified designs are handled manually (using rubylith, hand taping, photographic, or stick-off techniques). Some PCB work utilises partial " C A D " such as a grease pencil layout to on-line design or the method of draw plus digitize and edit. Few designs (as an overall percentage) use automatic place and/or route CAD tools. For PCB designs in the computer industry, however, the utilisation of CAD tools is well established as the only way to get the job done. The EWS closely parallels the PCB area in that most IC designs can be completed without the use of an EWS. However, if the functionality versus cost ratio is favourable, (if the system really performs as advertised) then more and more ICs will be designed utilising the capabilities of an EWS. For LSI and VLSI designs theremay be no choice; ifthe design is to be completed to meet the market window for a product, the use of a full capability EWS may be a necessity. Sometimes the purchase of a system is a policy decision or (more simply), it's fashionable. Everyone wants one, or needs one to be assured that indeed his job is as important as all the others. (Case in point: Colour raster graphics terminals over 19" green storage CRTs over 11" green storage CRTs.) 1.4 Hardware, software costs of system development The development of an EWS as a product will parallel software development systems (and these are in serious trouble). There are few standards within the various tools available for software development. Each editor, language, debugger, system monitor, command syntax and file control system differs as a function of what hardware and/or operating system it was developed for. Current estimates are that hardware represents only 30% of new system costs with software being the major cost factor at 70%. Trends indicate the software portion may climb to 80% in the next five years. Also, software maintenance is extremely expensive and is often done by less experienced, less motivated workers than those who implemented the original routines. With high-performance hardware becoming available and with the strong needs of the design community, is it reasonable to hope for a degree of sameness of functions as EWS systems are developed. 32
2.
Foundations for an E W S
2.1
Public formats to be complete--flexible--compatible
The lessons to be learned from the development history of interactive graphic systems should be well known and recognised by developers of engineering work stations. Various interactive graphics vendors followed divergent paths: (i) Core, disk, and magnetic tape data formats were identical, documented, made available to users, and (with a few minor exceptions) upward compatible over a ten year period. (ii) Different (and proprietary data formats were used for core, disk, and magnet tape. An "external" magnetic tape format was defined in both binary and ASCII (with several versions). It should be no surprise that the first vendor's format became an informal industry standard. In fact, it is possible to translate layout graphics from vendor X's format to vendor Y's format using the first vendor's format as the interchange medium! The lesson: If data formats are stable and made available to users, the value and number of functions generated by users (both on the system and on other off-line systems) will increase the system acceptance by the user community. The converse is also true: If users are forced to deal with slow-to-generate, ever-changing external formats, the value of the system to the user community is reduced. All of the above fails to address the fact that the only information that can be reasonably converted between systems (and formats) is that which is common among systems. In the case of interactive graphics systems, this consisted of rectangles, polygons, paths, and subfigures. When any of the extremely useful features of any one system (such as stretchable cells, unlimited text fonts, font scaling, true arcs, nodal cells, text nodes, snap nodes and multiple data types or bins) are utilised, it becomes difficult or even impossible to generate an accurate one-toone conversion of the data. One method to prevent a recurrence of this nightmare (or at least reduce its effect) will be for the various developers of an EWS to include more features in their original data formats (even allowing for un-implemented functions or providing hooks for future additions) and to clearly understand the users need to be able to accept designs generated on different systems. Here the merchant semiconductor manufacturers bear the brunt of having to accept customer designs from a number of system's, so we feel the need to simplify (or eliminate) difficult and time consuming conversion tasks. 2.2
Change and update control: a foundation for the data
Current systems offer little to facilitate update control: (i) Copy the file or named sub-structure and then modify the copy. (The system usually maintains no more than five previous versions because of storage limitations.) Often there is no difference between two (or more) backup copies. (ii) Re-name the file or substructure. (This necessitates a manual record keeping of old name, new name, reason for the change, plus having to remember to delete un-needed versions, copies, or names later. (iii) Copy of existing data to another media (floppy disk or magnetic tape) which also requires extensive manual bookkeeping. Having "extra" backups actually generates a false sense of security; the system should keep track of what-is-where. The actual data differences between sequential versions ofthese numerous copies range from zero to only a few percent of the total data content. There is a better way. Maintain the data with fields to show the date and time of additions, deletions, and the command or function. An analogy is a 5000 person payroll file with 33
Future applications of a full
capability engineering w o r k station continued from page 33
numerous updates. What is most often of concem is who was added or deleted in a particular time period of interest. Likewise, engineering data can be handled in a method flagging additions and deletions where A - B + C = D . A is the previous file; B represents any deletions; C represents any additions; and D is the current file. Any modifications can be handled as deletions plus additions. The value of having date-time plus function allows another very useful feature: reversing (or the un-do) of a function at any later time (assuming subsequent modifications have not been made) or the ability to flag the fact that an un-do cannot be automatically completed and the reason (such as a trace of what data has undergone subsequent modification). An example: most graphics systems include an explode or smash function. This removes a reference to a subfigure and inserts as exploded data the contents of the subfigure processed through the placement transform (x and y shifts, rotation, mirror, scaling, etc.) The value ofthis function is unquestioned: it allows a designer to make one-of-a-kind modifications to a standard subfigure. The danger of using the function is extreme: subsequent edits to the subfigure do not propagate throughout the hierarchy of previous references. Each previously exploded occurrence must be individually edited manually. Furthermore, there is no available record of where data currently exists from a particular explode. Despite classroom warnings to always be careful with explode, it all to frequently happens that the need to un-explode arises. The above proposed data structure solves this problem by maintaining information on what was exploded, and the reverse operation is now quite simple. Other useful information to include in the data for history purposes is when major operations are performed such as DRC, P G outputs, layer sizing, shape merging, model extraction, wire list extraction, and off-system backup copies generated. The existence of a small amount of additional information (in the add and delete fields) has another useful function: it simplifies the comparison of data between two backups. It is not necessary to perform a global explode and a total graphical exclusive--or to generate the changes in a useful form. Indeed, the changes expressed in hierarchial form are usually more valuable than the changes in the global, exploded formats. This compare feature is a foundation requirement for analysis of engineering design data. Design, by its very nature, requires extensive editing, additions, and a return to "the way it was when it last worked". If the computer does not or cannot facilitate the bookkeeping of this data, then the computer can often be more a burden than a help. Another useful column in the add and delete fields might be "Why*." But only after we have the basic capability can we intelligently outline a further need and determine its realistic value. In summary, the data base system must support the following operations: (i) comparisons of data between any two times or any two operations; (ii) the un-do of functions--return to the way it used to be; (iii) trial operations; (iv) prevent the need for manual bookkeeping; (v) version control without the need to generate multiple copies of files; and (vi) dual edits (either by using the system's graphics editor or by text edits of a manreadable file).
2.3 Software evolves as needs are defined Examples of successful software includes many systems where the problem is short-term and clearly defined. These include process control, smart traffic lights, and electronic telephone exchanges among others. Where the task is long term (like design projects of 6 to 18 months) and where manual intervention must be allowed (remember Three Mile Island.*), the task of 34
generating successful software is vastly more extensive and the results are not always successful. Also, there is a tendency to forget a basic rule of software: a task must be bounded and well-defined before it can be automated or any software solution can be implemented. Examples of design automation software shortcomings abound. A system questioning a user "Are you sure?" is guaranteed to delay the function for a few seconds.Thereis no guarantee that a thoughtful reconsideration of the function occurs. Powerful, one-way (non-reversible functions) are rampant. In actuality, engineering tasks consist of many "What i f . . . " or "Let's try it" situations. If a system does not support temporary functions, then it does not allow the engineer to work in his familiar ways. Two classes of successful software include those where the function is extremely well defined (and the user can chain functions together) and more complex functions where no manual intervention is allowed. Even route and place algothrims can be implemented until a user demands the ability to pre-route portions, or assist or improve parts of the intermediate results. Software to handle these "assists' is more complex, but its need should be recognised from the beginning. Successful engineering software often is the result of three or four major re-writes (with easy integration of improvements) versus trying to patch and improve an older generation system without a solid base. History also shows that a solid base can support the easy addition of new features with little impact to other routines and data structures. 2.4
Work lists of tasks
A basic feature of engineering stations is the need to maintain work lists oftasks that need to be done. These can be a list of changes made in a logic level diagram that must also be made in a physical (layout graphics) level. These lists allow the man and the machine to work more closely in a more natural relationship. The tendency is for computer programs to expect that all information is current and correct. In reality, there are usually a number of items (from complete blocks to individual interconnects) that are not consistent between the various pieces of a design. This is especially true where the design consists of several equivalent forms (block level, logic diagram level, transistor schematic level, layout graphics, hardware breadboard). The design support system should recognise the differences in these various forms rather than making the incorrect assumption that all forms are equal and correct. Design changes simply do not occur in lockstep fashion. 2.5 Different forms of design data Another need for an engineering work station is the ability to compare logic implementations in different forms: a gate level logic diagram may be converted into several transistor level schematics diagrams as a function of whether the implementation is to be in MOS, TTL, or ECL. This is necessary because each technology provides some functions "free" (such as wired-or, wired-and, multiple inputs, XOR and transmission gates) while other technologies require added components to implement a particular function. Some of the rules for converting logic are clear;, others require extensive manual efforts. 2.6
Multi-user, multi-site update resolution
Arbitration and resolution of multi-user, multi-site design changes need to be managed by the EWS. This requires a high speed communications link between stations and between sites. Current costs for long distance communications at speeds above 9600 baiad often exceed the hardware costs of the EWS. Resolution of changes consists of allowing multiple users to make changes that are mutually exclusive: engineer A can change the input buffers; engineer B can change the random logic; and engineer C can change the ROM programming. After file comparisons (utilising the date-time 35
Future applications of a full capability engineering work station continued from page 35
flags), the differences can be transmitted to each site for inclusion into that copy of the design. Messages at the next user session indicate the extent of the changes and who made them. When changes are detected that are not mutually exclusive (engineer A at one site has changed the input buffers; and engineer D at another site has also changed the input buffers), then the system can flag what has occurred. In this case, either set of changes can be accepted and then the other set of changes can be repeated on the new data. This also provides an extremely valuable communications function.There tends to be more careful planning and co-operation if designers are aware that the task is being overseen with attention to the most minute details. The computer may not guarantee that all the data is always accurate, but it causes designers to be more careful in their tasks. A healthy environment of "Someone really cares" and " I ' m smarter than any machine" allows the designer to compete with the machine on a friendly, non-threatening basis which results in a better f'mal design. The element of competition sets up a Win-Win situation for all members of the design team. 2.7 Log, playback, and log analysis An E W S should support a logging function and a playback of the log (or portions ofit) on either original or different data. This can be extremely effective in tracking down problems: is it a cockpit problem (the user did the wrong thing), a software problem (those last few bugs are quite elusive), or is there a problem in the interaction of the software function and this particular set of data ("Oh, what you really want in this case is different from what the software currently generates"). The playback function will also be useful in early training and demonstrations (and if it aids the functions of marketing, it must surely be of some value to a used). After a log is generated, a log analysis function is needed. This will indicate which commands and functions need to be improved, combined, repaired or eliminated. Also, it will allow managers to determine which users are most efficient in using the system, which need additional training, and which few should not be using the system (due either to carelessness, lack of understanding, or a complete waste of time and resources). A log function without log analysis is like marriage without sex: relationships may continue, but there's no hope for a future generation. 2.8 Flexible forms of input A system should accept multiple forms of user inputs: keyboard commands, macros, menu, programmable menus, hierarchical menus. The key to utility is some simple form of input (such as a structured menu) for the beginner or casual user and a more sophisticated form of input (such as type ahead with edits and programmable menus) for the most advanced user. The system should not reduce the speed of input for the more advanced user by requiring him to wait for prompts, menus, questions, or unusual cases which alter the input required. A further aid to fast, accurate system usage is a good system ofdefaults and modal values that are preset (or remembered from the last usage). User defined macros can allow command chaining for particular cases that occur often. Just as the system supports and encourages hierarchical design, the system should support higher levels of building blocks in the use of system functions. This will be possible if each function is clearly defined and is as independent (as possible) from other functions.
3.
Conclusions
So where are we? The engineer will accomplish his design task with whatever tools are made available to him. If usage of a particular system is mandated, he will use it as best he can (or quit ifthe battle is too st~'enuous). I f a system is made available on a " T r y it" basis, he will use it--if it's learning efforts are reasonable and the functions performed are of sufficient value. For a unified design support system, an engineer will offer numerous requests for new or 36
different functions. Here lies the real road to success: listen to the users ~needs and solve them in a co-operative manner. Such a system will result in increased usefulness to the user and the number of systems in use will increase as the word of their value spreads. The use of early, less-than-complete systems or systems fitting a narrow market need is acceptable if the value-of-use exceeds the costs (efforts to learn and use, time, dollars--in this order). Successful examples of narrow systems include interactive computer graphics systems, D R C sol, ware, logic simulation, circuit analysis programs, and first generation engineering work stations that perform schematic capture as their basic function. 3.1
Where not to cut corners
Since hardware is changing faster than software (and becoming as costly too) it is extremely important that functional software be generated so that it can migrate forward over several future generations of hardware. This will allow a developer to take advantage of cost reductions in microprocessors, memories, disks, hardware function boxes for such applications as routing, logic simulation, matrix operations on graphics, database hardware, and other just-around-thecomer functions. Ifa system is optimised around a specific hardware configuration (limited core, disk or even a specific microprocessor) its future may be dim. The more successful analysis, simulation, and checking software packages currently run on a number of hardware configurations, and no less should be expected of software that creates an engineering work station. So where can comers be cut? Implement fewer functions rather than implement incomplete functions. Solve a problem correctly the first time rather than rewrite or patch software due to incomplete specifications. Rush a product to market and it may be like a flashbulb--very short lived. It is essential that developers listen to users, customers, potential customers and critics. The messages may seem strong, diverse, confusing. Ifso, seek more information to clarify the details rather than rush ahead with no clear destination in mind. If user needs seem to be totally different, then maybe the common points of those needs are not clearly defined and understood.
37