a i m LI B UHY OF THE UN IVE.RSITY OT ILL1 NOIS 510.84 iJfcr no. 226- 236 cop 2. The person charging this material is re- sponsible for its return to the library from which it was withdrawn on or before the Latest Date stamped below. Theft, mutilation, and underlining of books are reasons for disciplinary action and may result in dismissal from the University. UNIVERSITY OF ILLINOIS LIBRARY AT URBANA-CHAMPAIGN MAY 3 JUN 7 MAVi3 MAY 4 19 38 L161 — O-1096 133 ff Report No. 233 /TuLUi COO-1018-1119 ?9 W THE WEB SYSTEM Part III* WEB Change Orders by W. D. Bond E. S. Davidson June 19, 1967 DEPARTMENT OF COMPUTER SCIENCE • UNIVERSITY OF ILLINOIS • URBANA, ILLINOIS PISTERZI Report No. 233 THE WEB SYSTEM Part III* WEB Change Orders by W. D. Bond E. S. Davidson June 19, 1967 Department of Computer Science University of Illinois Urbana, Illinois 618OI ^Supported in part by Contract AT(ll-l)-10l8 with the U.S. Atomic Energy Commission and the Advanced Research Projects Agency Digitized by the Internet Archive in 2013 http://archive.org/details/websystempartiii233bond 1 . INTRODUCTION This report is a discussion of the types of commands which should be available in the operating WEB System. These commands enable a designer to simply and quickly make modifications to a particular design. Provided with these tools, the designer can readily compare different designs, and on this basis select a pro- duction design. It is assumed that the designer will have access to a console of a time-sharing information system. As such, the language herein described is an interactive command language for use within the WEB system. The structure of WEB change orders is actually quite similar to any file manipulation system in which files can be created, deleted, and otherwise revised. As such, it is anticipated that file manipu- lation routines will be available within the time-sharing system, so that the implementation of change orders should only require an adaptation of existing file manipulation routines. It is assumed that the reader is familiar with "The WEB System, Part II: A Formal Description of the WEB Language." 2. BLOCK DEFINITION CHANGES DELETE- If a defined block is not used as a block component, this change command simply deletes the definition of the speci- fied block. Otherwise, a BLOCK NOT DEFINED message is printed for each occurence of this block as a block component and the definition is deleted. EXCHANGE- Exchanges one or more block components within the specified block definition for new block components. Any revision more complicated than this, e.g., one which involves the terminal list or one which adds more blocks than it deletes, or vice versa, must use the REVISE command. REVISE- The definition of the specified block is first deleted, and then the new definition added. All current usages of the block are automatically updated by the system, with the consequences followed through to wiring changes. Note that the usages of this block may need to be modified to be compatible with the new definition. ADD- A new block which has not previously been used is defined. Unnamed blocks can be modified in the same manner as named blocks by referring to these unnamed blocks as NONAME (n), as discussed in The WEB System, Part IV. Sub-blocks deleted from the definition of a block will not cause reassignment of index numbers for the remaining block components in the definition. Added blocks will be given an index number one more than the last remaining block in the definition. 3. BLOCK COMPONENT CHANGES The consequences of all the following changes are followed through to the wiring automatically. DELETE- One or more signal names are deleted from the terminal list of the specified block. These signal names may occur anywhere in the original terminal list. Remaining names are then collapsed to fill the spaces left by the deletions. This command should only be used to make the terminal list of the block component correspond to the terminal list in the definition of the block component. EXCHANGE- One or more names in the terminal list of the block component may be replaced with a new name. REVISE- The original terminal list is deleted and the newly specified terminal list is added. ADD- A signal name or names is added to the end of the terminal list of the specified block. h. MODULE DEFINITION CHANGES DELETE- This command deletes a module definition which has been completely deleted from the assignment description. EXCHANGE- One or more units of the specified module are exchanged. REVISE- Revises a module definition, having the effect of a delete and add. Revisions will be automatically updated and the consequences followed through to the wiring. ADD- Adds a new module which has not been previously used in the assignment description. 5- MODULE ASSIGNMENT CHANGES The consequences of all the following changes are followed through to the wiring automatically. DELETE- Deletes a module from an old location. Logic which has been placed on this module by a FILL statement must be deleted or moved, otherwise a MODULE NOT ASSIGNED or a NO MATCH message will be printed for each logic unit not deleted or moved, unless a module is added to that location, with which the logic FILL statement is compatible. EXCHANGE- Not available. REVISE- Changes the name of a module in a location. The old module is first found and deleted. Since original logic may no longer match the new module, additional statements might be necessary to update the desired correspondence. ADD- A module is assigned to a new location. 6. UNIT ASSIGNMENT CHANGES The consequences of all the following changes are followed through to the wiring automatically. DELETE- An old logic unit is deleted from a location. EXCHANGE- Not available. REVISE- Same effect as a delete and add* Used to move a logic unit from one location to another. ADD- Assigns a new logic unit to a location. 7. WIRING CHANGES For purposes of wire minimization, files will be processed in one of two modes: The PROTOTYPE mode is the normal mode for WEB processing, and is intended to correspond to an unwired assembly which is still in the design phase; the PRODUCTION mode is to be used when updating a file for an assembly which has already been wired, and is intended for debugging changes, etc. In the PRODUCTION mode, no attempt at full wire minimization will be made, rather the signal path will be made to correspond to the rest of the file with the fewest number of wire changes. Minimization does occur under these constraints. i) INTERCONNECT ADD- The wire minimization algorithm is constrained to find a minimal path with the wires herein mentioned as part of the path. The points listed here must be points which actually do occur in the signal path as defined. DELETE- The above constraints are removed from the wire minimization algorithm. The path is automatically reminimized according to any remaining constraints still in effect. EXCHANGE- Not available. REVISE- Not available. ii) FORCE ADD- This statement forces a wire to be listed between the points mentioned. This is done no matter what the con- sequences! 1 The statement should be used only in des- peration. As no indication of forced wiring is explictly indicated in output from the processor, suitable com- ments should be attached with this statement. DELETE- This statement forces the removal of the indicated wires from a signal path. EXCHANGE- Not available. REVISE- Not available. Force statements must be specifically deleted if at some later date they are no longer necessary, as otherwise they will remain wired as ordered. 8. DISPLAY COMMANDS An important part of any interactive system is the displays made available to the user. The following reports are proposed as necessary for an effective system: a) ASSIGNMENTS A listing (by location) of modules assigned, with unused lo- cations flagged. Also, a listing (by module) of locations at which a particular module occurs.; UNUSED being considered a module type. b) FILL A listing (by location) of units assigned to a module, with unused locations flagged. Also, a listing (by units) of module locations at which a particular unit occurs. UNUSED is considered a unit type, as above. c ) WIRING A listing (by signal path or by connector) of wires now in the file. The choice of format is to be suitable for wiring technician and logic designer (See The WEB System, Part IV: Implementation) . d) MODULE A listing of module definitions now available in the file. e) LOGIC A statement of the expanded logic now in the file. f) BLOCK A listing of all blocks now defined in the file. g) UNIT A listing of all units now defined in the file. It is anticipated that the foregoing displays would have to be explicitly requested. The following reports would be auto- matically provided: h) ERROR SIEVE A list of items in the file which are in error. Appropriate comments should be included. i) TRANSACTIONS REPORT A listing of the "first level" consequences of an update, available only immediately after the update is processed. Errors are flagged. j) CHANGE REPORT A statement of all changes which are caused by an update. These changes would have to be performed on an existing assembly to make the physical device correspond to the current file. Both previous and current items are listed. There is to be one section for each type of change command (other than < Display Command>) . 6 9 • ERRORS Since this system is to be primarily used to remove design errors from an assembly before it is wired, it is hoped that the user will not be bogged down with the mechanics of using the system. Certainly, however, errors in the usage of the change orders will occur. To this end, error messages should be liberally generated to guide the user in the correct utilization of the system. Accordingly, the following list is intended as a partial list of possible errors in file manipulation and usage of the system: NOT IN FILE - for a REVISE, DELETE, or EXCHANGE statement which refers to something not in the file. ALREADY IN FILE - for an ADD statement which refers to something already in the file. FORMAT CHECK - for a statement which uses improper or unintelligible format. DUPLICATE CHANGE - for two statements in the same update which refer to identical items. Some conflicts of this sort may be resolved by the order of execution, which should be: DELETE, REVISE, EXCHANGE, ADD. Priority levels of information are: BLOCK DEFINITION *- BLOCK COMPONENT . FILL MODULE DEFINITION ^ ASSIGN ^ Violation of priority leads to such errors as: BLOCK NOT DEFINED - block was called but not defined. MODULE NOT DEFINED - module was assigned but not defined. MODULE NOT ASSIGNED - a fill statement was given for a location to which no module was assigned. NO SUCH INDEX - a fill statement was given for a logic unit with a non-existent index number. 7 In addition conflicts can arise such as: NO MATCH - logic unit does not match module unit. NO CIRCUIT - logic unit was assigned by a fill statement to a module which does not contain a unit position as designated in the fill statement. TERMINAL CHECK - signal list of component block does not correspond in length to terminal list in definition of block. DUPLICATE ASSIGN - two modules assigned to the same location. DUPLICATE FILL - two logic units assigned to the same unit of a module . ILLEGAL LOCATION - cell or pin number is illegal. DUPLICATE PIN - two pin numbers of a module definition are the same . In cases of DUPLICATE ASSIGN or FILL, the earliest chrono- logical statement is executed, the latter one or more statements are ignored. In the case of any other error mentioned so far the er- roneous statement is ignored. Note that ignored statements if desired must be resubmitted after suitable modification to the file. Other errors resulting from Wiring Changes are: PATH DISCONNECT - a signal path has been broken into two or more unconnected pieces. LOOP - a signal path contains a loop (or cycle). TOO MANY' CONNECTIONS - three or more wires have been connected to the same point. These statements in supposed error will be executed but noted, if as a result of a FORCE statement. If as the result of an INTERCONNECT statement, however, the statement in error is ignored. 8 10. SYNTAX FOR WEB CHANGE ORDERS Syntactic variables not defined within this section are to be found in section 6 of "The WEB System, Part II: A Formal Description of the WEB Language." Notation introduced there is used here , <- : ( ) ; <- *- PROTOTYPE | PRODUCTION <- WEB UPDATE ; _ _ END UPDATE ; «- OPEN ; CHANGE _ _ CLOSE [ ] ; *- | I [ | *- | +- BLOCK DEFN ; <- DELETE ; | EXCHANGE : - | REVISE | ADD 9 <- BLOCK CCMP ; ; <- | - DELETE ; | EXCHANGE J|_ = j | REVISE ; | ADD ; «- MODULE DEFN ; «- DELETE ; | EXCHANGE JJ_ Module component> ; | REVISE | ADD «- | <- MODULE ASSIGN J *- DELETE | REVISE [ ADD <- UNIT ASSIGN J 10 *- DELETE ; | REVISE | ADD «- WIRING ; { INTERCONNECT | FORCE } ; «- { DELETE | ADD } : = ; 11