LIBRARY OF THE UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAIGN 5 1 0.&4 Uo. 343-34$) coip. 2 The person charging th^\^XarV?rom latest Date stamped below. ^^^ ^^^^^^^ Thef., -"f..a.-.on. end ---^-"'J^,. ,„ dismisso. fro. for discipr.nary oct.on and may the University. renter 333-8400 TO renew .all Telephone Cente- ^,bANA-CHAMPA|GN^ Li61_O-1095 6 -" ^ ^ 5 '/>7 Report No. 3i|-7 lESLA, A CONTROL LANGUAGE FOR LOGIC SIMULATIONS OF DIGITAL CIRCUITS by Nicole Genevieve Allegre August 8, 1969 OCT 2^ The Dersftp^charorinor +^,^5, »^,*^^;pi ;„ re- I-J61_ 0-1096 Report No. 3^7 TESLA, A COIWROL LANGUAGE FOR LOGIC SIMULATIONS OF DIGITAL CIRCUITS Nicole Genevieve Allegre August 8, 1969 Department of Computer Science University of Illinois at Urb ana- Champaign Urbana, Illinois 618OI * This work was supported in part by the Advanced Research Projects Agency as administered by the Rome Air Development Center under Contract No. USAF 30(602)4lH and submitted in partial fulfillment of the requirements for the degree of Master of Science in Computer Science, August 1969* Digitized by the Internet Archive in 2013 http://archive.org/details/teslacontrollang347alle 11 ABSTRACT The following paper describes the syntax and semantics of a language, called TESLA, designed to easily specify the control of logic simulations on a hardware level. The implementation on the B5500 of a translator from TESLA to an input language to the ILLIAC IV Control Unit Logic Simulator is documented in detail. Ill ACKNOWLEDGEMEm'S I would like to express my deepest appreciation and sincere gratitude to Luther Abel for his continuous help, never failing patience and encouragement, since the inception of this project. I also want to thank Professor R. S. Northcote for his judicious suggestions and corrections on the manuscript and all the TWS group, namely Alan Beals, Jacques LaFrance and Nelson Machado, for their ever available willingness to answer questions on the B5500 and the Translator Writing System, which was essential in the development of the TESLA Translator. I am also indebted to Norma Abel and Robert Trout for their moral support during the hours of discouragement. Finally, many thanks go to Miss Joyce Fasnacht for typing this thesis in time to meet a very close deadline. IV TAELE OF COWTEKTS Page 1. INTRODUCTION 1 2. LOGIC SIMULATION CONI'ROL k 2.1 Input Control 5 2.2 Storage Element State Control 5 2.3 Output Usage Control 6 2.k Global Control 6 2.5 Other Desirable Facilities in the Language 7 2.6 The Necessity for a Nev Control Language 7 3. THE TESLA LANGUAGE 9 3.1 Declarations 9 3.1.1 Simulation Case Limit Declarations .... 10 3.1.2 Group Declarations 10 3.1.3 Data Declarations 11 3.1.4 Digit Declarations 12 3.2 Test Step I3 3.2.1 Input Control Statement 1^4- 3.2.2 Storage Element Control Statement 16 3.2.3 Output Control Statements I7 3.2.4 Simulation Control Commands I9 k. THE TESLA TRANSLATOR 20 4.1 Philosophy of the Translator Design 20 4.1.1 Use of the TWS 20 4.1.2 General Organization of the Simulator-Translator System 22 4.1.3 Different Types of Signals and the Signal Arrays 24 4.1.4 Basic Decisions about the Compiler Design 27 4.2 Object Code Commands: Their Format and Semantic Meaning for the Simulator 37 4.2.1 Simulator Input Commands . 37 4.2.1.1 Initialization Commands .... 37 4.2.1.2 Register Control Conmands ... 42 4.2.1.3 Miscellaneous Commands 47 4.2.2 Print Control Commands 48 5. CONCLUSION 52 V Page REFERENCES 54 APEEKDIX A. THE SYIWAK SPECIFICATION OF TESLA 55 B. A SAMPLE TESLA PROGRAM 6l C. TABLES OF THE INTERNAL CODES OF THE OBJECT COMMANDS . . 65 VI LIST OF FIGURES Figure Page 1. Diagram of a General Logic Circuit 3 2. The Translator Simulator System 23 3. Example of a Possi"ble Circuit . 25 h. A and Q. Arrays with Their Companion Flag and Uncertainty Arrays 29 5. General Format for Simulator Input Data 30 6. The Storage of a Group in GA 31 7. Example of a Data Pattern in DA 33 8. Representation of (Ol)*l6 in DS 35 9. Representation of 8(o6)*l6 in DS 35 10. The Three "Bits" of the Octal ODD 35 11. Format of the CDDARRAY 36 12. Format of an INI Command Block 37 13. Format of an IN2 Command Block 39 14. Format of an IW3 Command Block ^0 15. Format of an IN4 Command Block i|-2 16. Summary of the Correspondence "between Input Control Source and Object Commands ^3 17. Format of an FFl Command kk 18. Format of an FF2 Command Block 46 19. Format of an FF3 Command Block h6 20. Format of an EOI Command Block h'J 21. Format of an EOF Command 48 22. Format of a Print Command Block 51 1 . INTRODUCTION TESLA is a simple test step oriented language designed to allow a simulation user to take advantage of the full range of simula- tion capabilities offered by the ILLIAC IV Control Unit Logic Simulator System^ while keeping coding as simple as possible. A quite general simulator system for synchronous logic has been designed and implemented by Luther Abel and Chiyozl Tanaka. Specific implementational details (e.g.^ data formats) have been oriented towards simulation of both printed circuit cards and entire functional sections of the ILLIAC IV Control Unit. A companion test step control language,, TESLA^ was developed to control the simulation of arbitrary configurations of logical elements. Each interconnected group of logical elements (e.g., a card) may be considered as an entity in the middle of a particular environ- ment represented by the inputs and outputs to the card. This is summarized in the following diagram (Minsky [1]). Environment In a simulation one must not only simulate the entity under consideration (the card), "but one must almost always simulate the environment also, at least in some minimal manner. For example, the electrical signals which are the actual inputs to the card are not also used as inputs to the simulator, but rather some logical or numerical representation of them is used. Further, the actual environment consists of other actual cards, while in the simulator environment it is only necessary to provide the simulated inputs by any convenient means, while the outputs interact with the environment almost always through the intervention of a human observer. Since a card is in general an arbitrary collection of arbitrary interconnected logical elements rather than a complete functional unit, the descrip- tion of its relationship to its environment and meaningful description of inputs and outputs becomes a non-trivial task. It is to this end that TESLA was developed. The arbitrary collection of logic mentioned above may be represented in a more general manner by the model shown in Figure 1 (Hennie [2]). It is obvious from the above figure that there exist major areas which can be controlled in a logic simulation: input values, storage (or delay) element states, output presentation or usage. Memory (or delay) Elements Figure 1. Diagram of a General Logic Circuit Therefore TESLA was designed to provide these three different types of controls as the inputs to the simulator, along with additional facilities to even further simplify the logician-programmer 's task. 2. LOGIC SIMULATION CONTROL The Control Unit Logic Simulator System consists of two major parts: the CU Card Logic Simulator System and the CU Section Logic Simulator System. The purpose of the CU Card Logic Simulator System is to assist in debugging card designs and to calculate the expected responses of the actual logic circuits to various tests which may be applied to them. It will also be used to develop card simulation subroutines for inclusion into the CU Section Logic Simulator. Finally, since the simulator incorporates a capability for modification to simulate the effect of failures of the logical elements, a Diagnostic Generator System will be built using the simulator as a nucleus. This will be used to develop input patterns to be used for production tests and off-line diagnostics. The CU Section Logic Simulator System will be used in a similar manner, except with respect to an entire functional section (e.g., ADVAST, FINST, etc.) of the Control Unit. The basic unit of a simulation is a test step or simulation of one clock interval (50 ns in the ILLIAC IV), which consists of actions occurring in the following order: 1) adjust the input values and storage element contents in response to commands from the simulation input tape; 2) simulate the action of the combinational logic during the interval; 3) record the output values and next storage element states. Three aspects of the simulation can be controlled at each test step: inputs storage element state and output usage. Inputs, storage elements and outputs are all denoted by signal names which are described in chapter h. 2.1 Input Control ¥e will call input values the logical values of the signals present on the input pins of the CU card connector. They are derived from two sources: 1) data provided with the test step to simulate the card with given input connections (a mapping of input data to input wires is presupposed, through a predefined symbol table for each card) ; 2) a subset of the previous outputs from the card. Also the input values can remain unchanged from the previous test step. 2.2 Storage Element State Control Synchronous storage element states can change only at the beginning of a test step. Their values can be derived from four sources : 1) they can remain unchanged from their previous state; 2) they can be cleared (register initialization); 3) they can be preset to some set of logical values given with the input data; k) they can assume their next logical state, i.e., the enahling gate values indicated by the previous test step are transferred to the storage elements. The transfer option of {h) will normally "be used since this corresponds to the actual physical operation of the circuits. 2.3 Output Usage Control At the end of each test step, the simulator provides a com- plete record of the logical values of all the signals on the CU card and also of the logical values of the input to the storage elements on the hoard. These are the states that the storage elements will assume at the next clock pulse if the "transfer" option is used for storage element control. The user may not be interested in all this information, so three options are given: - no printout at all; - unconditional printout with two suboptions : simulation results only, actual and expected results along with indicator pointing to the differences between them; - printout only if the results differ from those expected. The user also has the option of choosing the base in which the results are to be given, i.e., octal or binary. 2.14- Global Control To assist the user in the generation of each test case, some global controls are provided; namely the option of specifying the 7 repetition of test steps or groups of test steps, as well as the simulation initialization and termination. 2.^ Other Desirable Facilities in the Language Most of the time, several signals are used in exactly the same way in the tests. In order to make writing a program easier, it is desirable to allow grouping of these signals together and to refer to all of them by means of one identifier. In the same way, it is quicker and more mnemonically meaningful to write an identifier rather than a bit pattern itself when associating the same bit patterns with the same signals several times. Finally, since the B5500 has the ability to perf02nn boolean operations on full data words, it is possible to associate a different test case with each bit in the ^7 bit data word and simulate up to ^7 different cases in parallel. It is then interesting to have an entity called a case dependent digit (abbreviated as CDD) the value of which varies with the test case in which it is used. These CDD's then may be used in data patterns which will have configurations that vary with the test cases. 2.6 The Necessity for a New Control Language Most simulation input languages are designed to control the simulation of a whole machine, or at least an entire functional section of a machine. However, in order to verify the logical design of single printed circuit cards through the CU Card Logic Simulator, we must have a different type of language to control the simulation 8 of arbitrary logical elements. The level of the instructions must be lower than in previous simulation languages and, for maximal simula- tor efficiency, a simple way to specify parallel simulation must be implemented. For this reason, a new language TESLA (for TESt LAnguage) and its translator have been designed and built. 3. THE lESLA LANGUAGE TESLA is more an assembly-like language than a procedure- oriented language. One unusual feature is the provision offered for simultaneous generation and control of many simulations. Statements of the language pertain to two categories: declarations, and test step commands. Statements are written in free-field format separated by semicolons. A complete syntax specification of TESLA is given in Appendix A. Examples of TESLA declarations and statements given in this chapter are taken from the complete TESLA program which appears in Appendix B. 3.1 Declarations There exist four different types of declarations in TESLA, as described below. The simulation case limit declaration must appear at the beginning of each program, right after the first word which must be BEGIN. The other types of declarations may be freely intermingled with executable statements, provided that all quantities are declared before they are used. Redeclarations are permissible. But if a declaration A uses some other declared quantity B in its definition, every time A is used it will include the value B had at the time A was declared, regardless of later modifications or redeclarations of B. 10 3. 1.1 Simulation Case Limit Declaxatlons This is a declaration of the range of simulation test case inputs to "be generated in parallel. Because of the flag hit in the B5500 48 bit word, this range may not be greater than ^7. Example of a case limit declaration: CASES [1:32]; which specifies that 32 test cases will be generated in parallel through the simulation. 3.1.2. Group Declarations These allow the user to associate a single identifier with a list of signals (e.g., some set of input signals from the connector), or storage elements, for notational convenience. Groups must be typed either SIGNAL or STORAGE. Their respective interpretations within the TESLA translator are quite different. Any legitimate signal name may be used in the signal list associated with a signal group assignment. By "legitimate signal", is meant an existing signal of the simulated CU board, i.e., a signal name appearing in the predefined symbol table of this board. In such a context, the use of the signal name refers to the logical value held by that signal at the time its name is used in a test step. Only storage element output signal names may be used in the signal list associated with a storage group assignment. In this case, the use of the signal name refers to the next state of the storage 11 element^ i.e., the state the storage element vill normally assume at the next clock pulse. Example of a group declaration: SIGNAL GROUP IKLA (ABT-12--G0, ABT-28--GO); associates the identifier INIA to the group of two signal names ABT-12--G0 and ABT-28--G0. A list of group declarations of the same type, separated by commas and terminated by a semicolon, may be made after the reserved words SIGNAL ^ > GROUP . STORAGE I Group declarations may be nested to any depth, provided the types are consistent and the groups used inside the signal list have been previously declared. Mult i- signal identifiers (see paragraph 4.1.1 for the definition of these MSI's) of SIGNAL type are treated and built exactly like groups. The first time such an MSI is met, a group is constructed in the group array (see paragraph 4.1.4) so there is no need to declare an MSI as a group; it is declared when used. Hence MSI's can be freely used in the signal list of any group declarations like signal identifiers and group identifiers. 3'1»3 Data Declarations A data declaration allows the association of single identi- fiers with bit patterns for notational convenience. Bit patterns may 12 Toe expressed either in octal or in "binary form, the base being indicated in front of the opening parenthesis of the parenthesis pair which must surround the bit pattern. If the base specification is empty, the bit pattern will be assumed to be in binary. A CDD may be used in the bit pattern, provided it has been declared previously. A list of data assignments separated by commas may be made after the reserved word DATA, the list being terminated by a semi- colon, e.g. : DATA PAT2 = 2(0A1A0A1A), PAT2 = 8(OBlB2B3Bi+B5B6BTB); associates the octal and binary patterns to PATl and PAT2, respectively. 3.1.4 Digit Declarations A digit declaration is used to declare case dependent digits (CDD), i.e., digits whose values vary with the test case in which they are used. A CDD may be declared in octal or binary, with the (optional) base appearing in front of the opening parenthesis of the pair surrounding the digits of the CDD. The default option for the base is binary. The first digit (octal or binary) of the digit list is associated with the lower limit of the simulation cases declara- tion, the next digit is associated with the next test case, etc. If octal base is used, each octal digit is associated with only one test case; i.e., the three bits represented by each octal 13 digit determine three "bits in one test case rather than one "bit in each of three different test cases. A repeating pattern may be expressed by explicitly stating one repetition and following this "by a repetition factor which indicates how many times the given pattern is to he concatenated with itself to provide the desired case dependent pattern, e.g.: DIGIT A = 2(01)* 16; is a 32 hit pattern of alternating O's and I's. Restriction: CDD's must be denoted by single letters. Again a list of digit assignments separated by commas may be made after the reserved word DIGIT, the declaration being terminated by a semicolon. Note: The "=" signs in declarations are superfluous and may or may not be used according to the user's feelings about program readability. 3.2 Test Step A test step consists of a step label followed by a series of input, storage element, and/or output control statements. The separator between the step label and the statements is a colon, and every statement is terminated by a semicolon. Default options exist for all of these statements so that, if some type of control statement is omitted during a test step, the input to the simulator for that test step will still be completely defined. Ik 3«2.1 Input Control Statement These control statements are used to adjust the values of simulation input variables at the beginning of each test step. By specifying case limits these commands may be restricted to apply only to input variables of specified test cases among those being generated in parallel. Case limits must be contained within the declared range of simulation cases. INSET and INCLR cause specified inputs to be set to a logical "one" and cleared to a logical "zero"^ respectively. The reserved identifier ALL and the (default) empty word both cause the specified action to be applied to all input variables. INPUT causes the values of the members of specified signal groups to be modified to conform to a specified data pattern. The first member of the signal group is assigned the value of the first bit of the data pattern, the second member takes on the value of the second bit, etc. Therefore the order in which members of signal groups and data patterns are stated is important. Note that strings of case dependent data assignments apply to the last encountered pin group designator. If the specified data pattern is longer than the signal group, leading leftmost digits will be ignored. A data pattern which is shorter than the signal group will resiilt in an error condition. INDUT permits input signal values to be set to the values or the complements of the values of signals calculated during the previ- ous test step. Note that the input value will remain constant 15 throughout the test step, irrespective of changes in the fed-hack signal value; the simulator performs the equivalent of a sample-and- hold operation. This instruction has not appeared to be very useful for the simulation tests, so it is not yet implemented. Only signal names which correspond to input connections can he meaningfully used in an input control statement (except as members of the signal group specified by the output group designator in an IiroUT instruction) . Hence any attempt to control the value of a non- input signal will be flagged as a nonfatal error and will not generate any code. Only signal group designators may be used with the IKTUT command. Instructions are followed in sequential order and may be used to modify the results of a previous instruction, even within the same test step. If any input signal is not mentioned (explicitly or implic- itly) by membership in a group in some input control statement for a test step, then the logical value of that signal is unchanged from the value held at the preceding test step. This applies also to unmentioned test cases if input control statements are constrained to apply only to specified test cases. All inputs are initially cleared to a logical "zero" at the start of a simulation. The following are examples of some input control statements: INSET IID.A; will set the signals ABT-12--G0 and ABT-28--GO of group INIA in all 32 cases of simulation. 16 IISET [l:l6] IN3; applies the set command only to cases 1 through l6 of the IN3 signals. INCLR AGO- *^-- GO; resets the 32 cases of the signals of the MSI AGO--^-^--GO (c.f. chapter h for the definition of MSI's). INPUT IN3 2(0101010101010101); resets (sets) the odd numbered (even numbered) signals of the in3 group. 3.2.2 Storage Element Control Statement There are three TESLA commands to control the storage elements. FFX causes the storage elements in the logic under simula- tion to assume their next logical states as determined by the inputs to their enabling gates calciilated during the previous test step. FFOLD causes the previous states of the storage elements to be retained for the new test step, even if the simulated inputs to. these elements call for a change in state. FFIN is analogous to the input assignment statement. It causes the stated storage group value assignments to occur, presetting the specified storage elements to the indicated states. It is possible to use case limits to restrict storage element control statements to apply only to specified test cases. Unless otherwise specified by explicit storage control statements, the 17 transfer command FFX is assumed to apply to all storage elements. It is also implicitly assumed that^ at the start of each simulation, all storage elements will be initially cleared to the "reset" state (i.e., they will show a logical "zero" as their \incomplemented output). Examples of storage element control statements are: FFX; produces a transfer of all the storage elements on the simulated card. It is usually omitted "because of the default option. FFOLD; prevents a transfer of the storage elements which retain their old states. FFIN STO PAT2; sets the elements of the storage group STO according to the value of the hit pattern PAT2. (Cf. chapter k for the assignment mechanism.) 3»2»3 Output Control Statements These statements are used to control the printing of simula- tion results at the end of each test step. All the printing commands may "be constrained, by specifying case limits, to apply to only a portion of the test results that are being generated in parallel. PRIKIT2 and PRIM'S will cause printing of the logical values of the members of the specified output groups in binary or octal form, respectively. The reserved identifier ALL and the default 18 option (empty specifications) will cause the printing of all output variables in alphalDetic order. Both signal and storage groups may be used in an output control statement. PRAC2 and PRAC8 (PRint And ^ompare) cause printing in "binary and octal, respectively, not only of the simulation results but also of programmer specified expected outputs. If differences exist between the expected and the actual outputs pointers are printed which direct the observer's attention to their locations. The requirements for data pattern alignment and ordering are the same as for the INHJT command. PRire and PRIDB (mint If Different) are similar to PRAC, but printout occurs only if there are differences between the expected and actual outputs. If the simulation output is as expected, no printout occurs. All desired printout must be called for explicitly. The default option for the printout command is no printout at all. Examples : PRIKT2 INIA; will print the bit pattern of the signals of group INIA in binary. PRAC2 IN3 2(0101010101010101); will print in octal the bit pattern of the signals of group IN3 at the instant when this command is executed, and \inderneath the bit pattern 19 specified in the command with a marker pointing to the cases showing discrepancies . 3.2.^ Simulation Control Commands These commands allow easy specification of the repetition of a test step;, or a sequence of test steps. The sequence repetition specification LOOP will cause all test steps following the LOOP command up to and including the step with the specified lahel to be repeated. This command has not yet "been implemented in the translator. A step repetition specification^ the REPEAT command^ allows the execution of a given single test step any desired number of times. The default option for these two simulation controls is a specification factor of one (i.e., no repetition). Example : REPEAT 3 STEPIO : ; will cause the execution of the whole of STEPIO three times before continuing with execution of the rest of the program. 20 k. THE TESLA TRANSLATOR ^.1 Philosophy of the Translator Design ^.1.1 Use of the TVfS The TESLA Translator was written with the help of the ILLIAC rv Translator Writing System (TWS). The translator requires only one pass and it is made of essentially three parts: the scanner ; the parser and the semantic routines. The parser is a Floyd Production Language interpretive parser (Beals, LaPrance^ Northcote [3]) generated by the TWS system from the syntax specification listed in Appendix A. The standard TWS scanner (Baker [h]) had to be modified somevhat to meet particular TESLA requirements. A table of identi- fiers denoting the names of each of the signals in a board is created during the simulator generation process. These identifiers are ten characters long and they usually contain the non- alphanumeric char- acter "-"^ although some do not. A typical example of a signal name is ABT-13--G0. Because of the prescribed signal-naming rules, related signals (e.g., the 6k bits of a register) have quite similar names, differing in only one or two characters. It is interesting then to be able to refer to all the signals of such a group by a new type of identifier, called a Multi Signal Identifier (or MSl). These MSI's contain "^" 's as "don't care" characters; that is, in place of characters which may vary among the signals of the group, e.g.: 21 denotes the group of all signals denoted "by identifiers having any character in positions 6 and 7 of the identifier name, and the specified characters A, B, T^ -, etc. in the other positions. Because signal identifiers and MSI's are frequently syntac- tically permitted to occur in the same places as ordinary Identifiers (group designators)^ they must be scanned as special "but legal identifiers in TESLA. When TESLA was applied later to PE card simulations^ it was discovered that EE signal names sometimes used "f" instead of "-", thus requiring another small modification. The standard TWS scanner recognizes identifiers and numbers without the necessity for syntactic specification^ converting the individual characters into a single symbol directly in the scanner. On the other hand, CDD's and bit patterns are specified by strings of numeric and possibly alphabetic (in the case of bit patterns) characters, which must be scanned as strings and not as numbers. This is achieved by switching the scan mode to character mode by executing a semantic action right before the recognition of one of those bit patterns, and restoring it to normal identifier scan mode immediately after.' Hence the scanner tests the value of the variable SCANMODE when a digit is scanned. Other numbers are scanned and evaluated as standard B5500 numbers. Since numeric quantities in 12 TESLA are guaranteed to be less than kO^G =2 , the scanner puts the value of the number directly into the 12 bit field MSTACKt PIMSTACK] • [l8:12], instead of in a location of BIGTAB pointed to by 22 MSTACK[PrMSTACK] • [l8:12]. This avoids one level of indexing in the case of numbers. The actual translation is performed "by the semantic actions which are called during the parsing. ^.1.2 General Organization of the Simulator-Translator System The TESLA Translator belongs to the Data Preparation group of programs of the Simulator System. This subsystem creates two disk files for each simulation. 1) The first file contains the input to the simulator itself. One variable length record (covering a few logical records of the file) per test step specifies the input control^ all new input values (i.e., the symbols of the simulation input (A) array which have been modified in the test step), the storage element control, and any preset values for the storage element states. 2) A second file, also with one variable length record per test step, contains the output control and the output signal values at the end of the test step together with the expected outputs, if any. This file is not used by the simulator itself, but by the results display program for comparison against the simulation results in output editing and printing. It contains a record of all the values of every signal (every element of the arrays) at the end of each simulation step. The general organization of the system is shown in Figure 2. 23 |A/WW^kN^VV.*W\ s -P O •H CO !h O ■P cd H EH EH OJ §) •H 2h ^.1.3 Different Types of Signals and the Signal Arrays The simulator input is the object code for the compiler, so a general idea of what is necessary for the simulator input is required. Because of addressing limitations within the simulator itself, signal values are stored in arrays. Each signal (there are from several hundred to several thousand in a typical simulation) has assigned to it a unique subscript in some array. The different signals in the simulator are divided into three categories according to their function, use and position with respect to storage elements. This categorization is then used to determine to which array the signal is assigned. Within an array (signal category), signals are arranged alphabetically. If any of the connections from a particular signal is attached to a connector pin, then it is a source (i.e., input) or load (i.e., output) signal from the board. Figure 3 shows the different types of signals. 1) Input signals, like ALl, AL2, AL3, Plh, XRl in Figure 3, are mapped in the simulator system into elements of an array called the A array. 2) Output signals, like BKZ, BKY, BKX, are mapped into the elements of another array, B. 3) Intermediate signals, like ARO, are mapped into elements of the C array. Another array, D, is used for overflow if there are more than 512 intermediate signals. A second array is used, rather than Increasing the dimension of C, for efficiency reasons. Two arrays are sufficient because there will never be more than 1023 internal 25 pq PQ Ttr-/: "7F — 7K- "JF — ^ ^ m J- -p •rl pi CJ •H O (D H a oa CO O O (1) H & f^ •H 26 signals. These two arrays C and D have no particular function in the compiler. Hence there exists a one to one correspondence between the signals and the elements of the A, B^ C, and D arrays, as defined in a symhol table kept in the input file named SYMBOL. This file is created for each board by a small program TESLA/MERGE out of the files (board name)/SIGNAL and (board name)/STORAGE which define, respectively, all the signals and all the storage elements. The array locations corresponding to signal names have a symbolic representation of 1^ bits : 5 bits 9 bits T t code for the subscript value array name (range 0-511) This representation is referred to as the SYMBOL of the signal name. Two bits would be sufficient to code the four currently used array names, but five bits are provided for expansion. At present A is coded by 00000 B is coded by 00001 C is coded by 00010 D is coded by 00011 Besides these four arrays another one, the Q array, contains a copy of the values of the storage elements. No special code for this 27 array name is needed because its elements are used in a distinct context where no ambiguity is possible. 4.1.^ Basic Decisions about the Compiler Design A detailed examination of the object code, command by command,, is given in the next paragraph; but a few basic decisions about the compiler must be exposed first. It is desired to optimize the speed and efficiency of the simulator to the greatest possible degree. If any tasks could be performed within the compiler which could result in simpler and faster running input to the simulator , then they should be included in the translator design. Thus, for example , only one object command of a given type is put out at the end of each test step, rather than one object command per source command. To realize this a copy of the A array (or array of the input symbols) and the Q array (or array of the storage elements) is kept inside the compiler. Even if a source command only affects a small number of the total range of test cases for some set of variables, it is frequently possible to put out a more efficient object command affecting all test cases. Recalling the simulation rule that an input remains "unchanged from its previous value unless specifically modified, it can be seen that if a copy of the simulator's input array is kept within the translator itself, it is almost always possible to fill in the values for the remaining test cases. Only when the INOUT command has been used, does this technique break down, since there is no longer any certainty of the values in the simulator's input array for signals which have been affected by 28 this command. (The values which will be assigned to the members of the input group are known only at simulation tinie.) But if these signals are later specifically set to some predetermined value by one of the other input source commands values are again known. Similar reasoning applies to the states of the storage elements, except that their values are generally quite uncertain, unless they have been preset to a certain state by some source command. Thus an uncertainty mask and two flags are associated with each element of the two (A and Q) arrays (c.f. Figure 4). The uncertainty mask is used in relation with case dependent commands: a bit 1 in a given position of the ^7 ti't uncertainty mask signals that the Value of the corresponding bit of the corresponding element of the A (or Q) array cannot be predetermined. As soon as one bit of the uncertainty mask is a "1", the uncertainty flag is turned on, and when all bits of the mask are reset the uncertainty flag is turned off. (The xmcertainty flag can be simply viewed as the inclusive OR of the bits of the uncertainty mask.) Hence the uncertainty flag is the indicator that the uncertainty mask should be used in the • evaluation of the array elements. The other flag is the activity flag; it is turned on each time the configuration of the corresponding A (or Q) array element is modified during a step. This setup requires some bookkeeping in the compiler but allows the emission of condensed object code: one command of each type only per test step. A scan through the flag array is sufficient 29 u u <; >> ■p •H Oj o •a ^^ ^>> H cj !h H O 0) tH O •H O o •H E^ -P •H CO < a? -a 0) •H 30 to decide if an array element has been modified in the test step and which object code command produces this modification. The system can then string together, into a single command, all the A array elements affected by a particular type of command. Another basic point of the compiler philosophy has been that all outputs, i.e., the simulator input and the print control input, will always consist of pairs of words. This decision will lead to the waste of a few words, but not many because most of the time the format of the command covers an even number of words. The general format for simulator input data is shown in Figure 5» bit' 12 26 3^ ^7 ^ Q2 verb Ql Data 1 Data 2 Y//A..e. usea////////// A pair of words always present additional pair of words necessary for some instructions Figure 5' General Format for Simulator Input Data TTie compiler builds and maintains other arrays among which the three most important are : the group array named GA the data array named DA the CDD array or CDDAERAY 31 Other arrays such as the hit pattern array BP the signal list array SL the digit stack DS are temporary^ hut are important in the construction of the permanent ones. The group array GA is an array containing all the elements of all the groups. Each group is a seq^uence of words of GA, each word containing^ right- justified^ the SYMBOL of a signal of the group (i.e., the 1^ bit code), with a heading word containing the length of the group (i.e., the number of elements in the group) in a 1^ bit field and an indicator (called SSI for short) of the type of the group, either signal or storage. This flag SSI is bit 1 of the heading word. (See Figure 6.) < 1 word ■> SSI 3^ ^7 lengtJn sequence of SYMBOL'S in the order of the signal names given when the group was declared. Figure 6. The Storage of a Group in GA 32 A pointer GAPTR always points to the last meaningful entry in the group array GA. As soon as a group is available in GA, the semantic field of the entry in BIGTAB corresponding to the group identifier is used as a pointer to the heading vord of the group built in GA. Hence this group can be accessed again^ if needed, by simple indexing. When a group declaration is recognized, the groups are transferred into the group array, once they have been built in the signal list array SL. The first used word of the SL array always has the index 1, so that the signal list pointer (SLECR) which always points to the last meaningful information in SL, has as its value the number of elements in the group under construction. This value is used in making the header just before the transfer of the group elements in GA. MSI's of SIGNAL type are retrieved exactly like groups except that their first use in any command suffices as a declaration; no special declaration is needed. The Data Array (DA) is similar to the group array. It is constructed according to the same principles, using the bit pattern array (BP) as a temporary array in which to build the bit patterns before transferring them to DA, along with a header containing the length of the bit pattern. Each "bit" of the bit pattern is stored in one full word of the DA, since that bit has some value for each test case, and must be stored as such. CDD's may be used instead 33 of bits, provided they have been previously declared; their "bits are similarly stored across the word of DA, e.g., DIGIT A = (01)^16; DATA PAT = 2(10A0); will generate in DA the hit patterns written from right to left as shown in Figure 7* bit' <- 1 word -> 01 25 34 ki PAT i lvalue of 4 11 11111 1 00 00000 10 01010 A 0__.. _.___.. ._. .____0_0 0_ Figure 7« Example of a Data Pattern in DA The first used word of the BP array always has the index 1 and a pointer BPPTR, always points to the last meaningful information so that when the list is ready to be transferred into DA, BPPTR contains the length of the bit pattern. When the bit pattern is declared in octal instead of binary, it is assigned the binary representation of the octal number. The semantic field of the BIGTAB entry corresponding to the data designator contains the pointer to the header word of the data 3i^ designator specification in DA. In order to differentiate in BIGTAB between the pointers to the arrays GA and DA, the first bit of the semantic field is used as a flag. We call it DDGDF for Data Designator/ Group Designator Flag. DDGDF = (or FALSE) means pointer to GA. DDGDF = 1 (or TRUE) means pointer to DA. The CDD's are also built into an array called digit stack (DS) and are stored in an array called CDDARRAY , at the time of their declaration, so that they may be used later on. They are mapped into a machine word starting from the right and moving towards the left, e.g., bit pattern 00101... is mapped into (Ol)"^l6 is mapped into bit bit- 01 . . . . 1 1 C ■012 1^3 t^5T^T kk k6 1 10.... ... 1 1 1 c l6t 17 46 T ^7 To form the pattern, use is made of the digit stack DS which is, in fact, a list where the sequence of bits is placed one by one as they are recognized. An example is given in Figure 8. The bits are then put, by shifting and concatenation, into the ODD pattern. 35 bit— »01 -DSPTR Figure 8. Representation of (Ol)*l6 in DS A CDD may be specified in octal instead of binary. Then each octal digit is associated with only one test case (i.e., the three bits represented by each octal digit determine three bits in one test case, rather than one bit in each of three test cases). Hence the digit pattern then obtained occupies three words. In fact, an octal CDD generates three binary CDD's. Figures 9 and 10 show the different stages in the construction of the octal CDD 8(o6)*l6. bit-*01 110 110 110 bit— ^01 33 32^ k3 h7 Bitl-. .T T t Bit3 Bit2 10... . . .10 10 10... . . .10 10 0... . . .0000 t t .6 l6 digits Bitl Bit2 Bit3 t f t t 6 6 Figure 10. The Three "Bits" of the Octal CDD Figure 9« Representation of 8(06)*l6 in DS 36 As a CDD is alvays denoted by a single letter, there is a maximum of 26 such digit patterns. In order to access the CDD's in the CDDARRAY "by using as an index the numeric code of the letter representing the CDD, the CDDARRAY has a particular format. There are 12 special characters in the middle of the alphabet (same as Burroughs coding). Hence the CDDARRAY will have 26 f 12 = 38 rows, numbered 38 rows base Bitl Bit2 Bits « — 1 word-» < — 1 word-* < — 1 word-* <— 1 word — > Figure 11. Format of the CDDARRAY from to 37' The numeric code for a letter must have I7 subtracted from it (17 is the numeric value of the code for the letter A) before computing the index. This fixed format for the CDDARRAY leads to some wasted memory in the case of binary case dependent digit, but it allows an easy implementation for dynamic redeclarations in a program; there is no problem when switching from binary to octal for a given CDD. 37 k.2 Object Code Commands: Their Format and Semantic Meaning for the Simulator 4.2.1 Simulator Input Commands The object code input commands are divided into three different groups. 4.2.1.1 Initialization Commands These commands assign data patterns to elements of the A array. According to the circumstances and types of assignment, and uncertainty or not of the "bit values, one of the four following commands is used. The command verhs are, in fact, replaced hy coded values which can he found in Appendix C l) INI command: The format of the TNI command is shown in Figure 12, where n is the number of assignments to be performed while Datal //////////// SIMB2 Data2 Figure 12. Format of an im. Command Block 38 carrying out the INI command^ i.e., n is the niomber of (following) pairs of words in the scope of the INI verb. The action taken by the simiilator on the block in Figure 12 will be (expressed in a pseudo-ALGOL form) A[SyMBl] ^ Datal; A[SYMB2] 4- Data2; Note that the SYMBOL'S present here (SYMBl, SYMB2, etc.) are in fact only subscript values since the signals being set are always elements of the A array;, the array code for which is 00000. Such an INI command block is easy to output at the end of each test step. The translator must merely scan through the flag array AF to detect the activity flags set. If no uncertainties are present, then n is simply the number of those flags set. The SYMBOL'S are the subscripts of the elements whose flags are detected and the data are the patterns to which the A[ index] 's must be set. 2) IN2 command: As soon as one bit of the uncertainty mask Is on, the INI verb must be replaced by the IN2 verb, because an uncertainty mask must also be put out along with the subscript and the data. Figure 13 shows the format of an IN2 command block where n is the number of assignments to be performed in accordance with the IN2 command. The action performed at simulation will be: A[SYMB1] ♦. (A[SYMB1] ANL MASK) OR (DATAl AND NOT MASK); A- I current value of A[SyMBl] given by the simulator. 39 Note: The expression (DATAl AND NOT MASK) can be evaluated inside the compiler "because DATAl and MASK are known at compile time. So^ in fact^ the DATAl put out by the compiler will be the result of the operation (original) DATAl AND NOT MASK and the simulator will^ in fact^ simply perform: A[SmBl] 4- (A[SmBl] AND MASK) OR DATAl. In general the object code consists of a combination of INI and IN2 commands. The uncertainty is created by the use of the TESLA 26 ^ / / / -■' / / / / / / y '/ / // hi IN2 mmm SYMBl Uncertainty MASK^ i.e., AUr SYMBl 1 DATAl / /// . specification of one assignment Figure 13 . Format of an IN2 Command Block 40 source command lEOUT. As certainty about the value of bits of the A array elements is regained; the corresponding bits of the uncertain- ty mask are reset. When the last one is turned off ^ the uncertainty flag bit is also reset. The IN2 command must be used until complete certainty is regained about the A array elements affected by an INOUT command. 3) IN3 command: IN3 is the object order corresponding to the INOUT source command. The IN3 block format is shown in Figure ik, where n is still the number of assignments to perform^ i.e., the length of the list in the scope of the IN3 command. IKV stands for inversion, i.e., the logical (or one's) complement. The whole field IKV (i.e., eight bits) takes the values for no complement 1 for one's complement. v//////////////Z^, Figure l4. Format of an IN3 Command Block 41 The SYMBx's represent elements of the A array only, so their values are only the sulDScripts of these elements. However the SIMBxP's may represent elements of any array, so they include the code for an array name in the five high order bits. The assignment performed by the simulator is then A[SmBx] ♦- n; IW then not signal (SYMBxP) else signal (SYMBxP); ■where SIGNAL (SYMBxP) is a boolean typed procedure giving the current value of the variable designated by SIMBxP. Since we cannot a priori determine the value of SIGNAL, this command makes the compiler lose certainty about the values of the corresponding A array elements. Therefore the bits of the uncertainty mask corresponding to the bits of the A array elements affected by the INDUT (i.e., IN3) command are set on. h) IN4 command: IN4 replaces the IN3 command in the case of an INOUT with case limits, e.g., INOUT GRPl [l:l6] GRP2j . It is not possible in this case to compute, at compile time, the value of the A element using the partial mask as in the INI case, because the values of the GRP2 elements are unknown at compile time. Conse- quently, the mask must be put out along with the two SYMBOL'S, and the assignment will be performed at simulation time when the values of GRP2 are shown. The IN4 block format is shown in Figure I5, where n is the length of the list of pairs of words in the scope of the IN4 verb, i.e., the number of assignments to be performed. 42 12 ^ 3^ ^7 y///Ay/Ay^ i^ //// SYMBIP IIW SYMEl MASK Vn^ Figure 15 . Format of an T^ Command Block The assignment performed at simulation time is: ACSYMBl] «- ((EF INV THEH WOT SIGNAL (SYMBIP) ELSE SIGNAL (syKBlP)) AND NOT MASK) OR (A[SYMB1] AND MASK); where SIGNAL again gives the contents of the array element to be used as input in the assignment. 4.2.1.2 Register Control Commands There are three verbs in the object language to control the storage elements or registers. They are related to the TESLA commands FFX, FFOLD and FFIN^ but there is no one-to-one correspondence. FFl takes care of FFX and FFOLD, and the object commands FF2 and FF3 are needed to take care of FFIN depending on the situation in which that verb is used. l) FFl command: The FFX and FFOLD commands apply to all the storage elements on the board. They are both translated into the FFl command, the distinction between the two being made by means of ^3 H H -:t ■73 d o ■p o 0) •■-3 ,Q O ^3 M gl O pi O CQ H O O O -p I H C! 0) a; a CQ ^ O (1) ■P tH O eg EH CO o o •H kk a flag, vhich is the last bit of the Ql field of the FFl command. The Ql field is not required for any other use; no record of the scope of the command need he kept as in the case of IKL "because , by definition, it applies to all flip-flops. The format of this FFl command is shown in Figure 17- The rightmost hit of the Ql field is used for the FFOLD flag, which is on if there is any retention from the old state of the storage elements, considering all the test cases. The MASK indicates in which cases there must he retention of the old state. 3 26 34 CASE #1 GRPl OUTGRP ALR CASE #2 GRPl OUTGRP ALR CASE #3 There are six print commands in TESLA (c.f. paragraph 2.3-^)' They are in one-to-one correspondence with the object language commands (c.f. Appendix C for the internal coding of these commands). Note that there is no problem in using for the printing commands codes which are identical to some of the control commands because they are used in a different context; they appear in different files which are retrieved by different programs at different times. 50 The TESLA print command may, or may not, include case limits, e.g., PRIEr2 GRPl, GRP2; or ERIWT2 [l:l6] GRPl; Hence the print command "block issued hy the translator must include: the object code for the command; the group names; - the cases for which the printout is desired; the symbolic representation of the signals in the group. The groups are printed in the same order in which they appear in the TESLA program. This is all that is needed for the commands PEINT2 and PRINTS. If the command is a PRAC or a PRID, then the expected outputs must he saved as comparison information. Therefore a print command block has the appearance shown in Figure 22, where Ql contains the number of signal values to be printed, and Q2 contains the number of characters in the group name. The number of signals in the group to be printed comes from the header word of the block corresponding to the groups in the group array. Such a block has to be put out for each group appearing in the print command, which means that the command verb has to be repeated for each group to be printed. The printout control language also includes the two verbs EOI and EOF, which have the same function and format as in the simulator input language. EOI is to be issued when the output file is 51 12 case 47' ^ Q2 26 Verb 3^^ ^7 Ql Case mask (PKEMMASK) I ' G I R 1 U ' P — I Id ; b 20 E 34 ^ smBi SYiy[B2 smB3 z ^ SYMB^ SIMB5 SYMB6 U -y^N -case 1 even number of full computer words containing the name of the group as it appears in BIGTAB (i.e. 6 characters per word) list of the SYMBOLS of the variables in the group, packed 3 per word (filled with ' s to make an even number of words) Expected outputs in the case of PRAC or PRID (filled up with O's if necessary to make an even number of words always ) Figure 22. Format of a Print Command Block completed at the end of the test step. EOF is to be issued when the output file is completed at the end of the whole program. In fact the EOT and the EOF blocks are issued at the same time for the simulator input and the printout control. 52 5 . CONCLUSION Two files are built by the TESLA Translator. These are the file input to the simulator called TESLA/SINHJT and the print control file TESLA/FRINTC. The translator has been tested on a number of test programs but not yet on long real simulations because of delays in the implementation of the simulator itself. On a 60 card program, the compilation speed was 208 cards per minute. But the T¥S implementation requires a fixed amount of time for initialization which is independent of the length of the program. Thus for longer programs, the effective rate of compilation is increased. For instance, a 120 card program was compiled at the rate of 273 cards per minute. There exists another factor which affects the running speed; this is the fact that the TESLA Translator runs on a B5500 on which program speeds are heavily dependent upon the mix of programs in the system. Because of certain language features and because the Translator is tightly linked to the simulator in its design (the translator performs at compile time those operations completely defined then), the TESLA translator deals with large arrays, hence making heavy use of the l/O channels to exchange information between core memory and the B5500 disks. Therefore, if the mix contains another program also requiring heavy use of the l/O channels the performance of the system is significantly reduced. 53 More use of the system is necessary before its performance can "be evaluated^ but the translator itself already has been of some use. It has been used to test some CU boards and in testing the accuracy of the simulator -generator itself. TESLA allows a clear specification of the inputs to signals^ then by following the trace and propagation of these signals on the blueprints of certain known circuits, it is easy to check the real output of the board against the output given by the simulator- generator. This procedure has been a great help in the debugging of the simulator-generator. The systematic test of the CU boards cannot be undertaken before thorough debugging of the translator simulator system as a single entity. More thorough experience in the use of these programs will be necessary to really appreciate their usefulness and performance but, as far as can be ascertained, they appear to serve the purpose for which they were designed. 5^ REI'ERENCES [1] Minsky, M. L. ^ Computation: Finite and Infinite Machines , Prentice-Hall, Inc., Englewood Cliffs, New Jersey, 19^7^ p. 1^. [2] Hennie, F. C, Finite-State Models for Logical Machines , John Wiley and Sons, Inc., New York, 19^8, p. 9* [3] Beals, A. J., LaFrance, J. E. , Northcote, R. S., "The Automatic Generation of Floyd Production Syntactic Analyzers," Department of Computer Science, University of Illinois at Urban a- Champaign. To be published. [h] Baker, A. C, "A Generalized Logical Scanner for a Translator Writing System," M.S. Thesis, Department of Computer Science, University of Illinois at Urbana-Champaign, Au^st 1969. 55 APPMDIX A THE SYN1AX SPECIFICATION OF TESLA 56 THIS IS THE SYNTAX SPECIFICATION ^f TESLA IN 6NF FOR INPUT TO THE ILLIAC IV TRANSLATUR WRITING SYSTEM ; It* fREGIN »l J lt« M« / I ll« »J / #3 I M» iCASES tIJ #4 I H« <*N> #5 J ll« <*N> »6 ; ll» KGROUf* DECLARATION> / / J ll« IGRUUP / / $, I !!■ «DATA / i# t <0IGIT nECLAHATlON> lt» *UIGlT #100 <0I6iT AssIGnMENT> / tf flOU J II* ISIGNAL 97 / iSTORAGE #8 I ll« «1 7 • () #9 / #17 C) #9 I ll« / #* i li» <*I> #10 ; 11* ■ #11 / J 57 li« a «101 NOBACK ) fl02 #12 t It* 113 I II* <> / <*N> #U I <0I61T LIST NITH PAREN> tl« ( ilOO #15 / #lb i ll* <> / * <*N> #16 ; tt« <*I> J H* <*I> #16 I It" <8IT PATTERN LI^T WITH PAREN> ) #102 j il« ( #100 <0IGIT> #20 / ( #1U0 #21 / #20 / #21 ; X****************** END UF DEFINITION OF *******♦*♦♦*****- !«■ I ll« <> / IKEPtAT #22 I lis <> / #LUQP #23 ## #24 / ll« <*N> I H« #25 #1 / #i i H« <*I> I II* / <2ER0S ASSIGNMENT* / / 58 / / / / / / <> ; <0NE:S ASSIQNHENT> tl« «INSET #26 <30 f26 / fiNSET «26 J Its «INCLR 127 #30 #20 / »INCLR #27 I Ms #?8 / #29 / •* #29 I Us »ALL #30 / #31 j lis ( I 1 #32 j Its #INPUT #33 / #. I Its #34 j lis 'ATTErn> #35 / #30 / #' 'ATTERN> #36 I IIS #37 / #38 f its tiNOUT #39 #40 I KOUTPUT FEEOBACK> it #40 i II* 59 f4i I lt« #42 / 1*3 / ## #43 j tl« #44 I »l« <> / iNUT f'S I lt« #46 J lt« #47 I ll» f??t #48 / #FFX #49 I lt« «FFOLO #50 / #FFOLO #51 I ll* #52 / »» #53 j tl« #FFlN #54 / #/ I KSJORAGE GROUP ASSIGNMENT> l»« #55 #56 I ll« #PRINT2 #37 #59 / #PRINT8 #38 #59 ; #PRINT2 #37 / #PRINTB #38 <0UTPUT SPECI F IC ATIONS> J ll» / / ## J its #ALL #59 / 6o T> I lie «60 / *» #60 I li« fPRAC2 #61 / fPKACe #62 / ## KfXPECTED OUTPUT> I ll« #63 #64j l»« #PhID2 #65 / #PHlDa #66 / ## I ll« A/R/C/D/E/F /G/H/I/J/K/L/M/N/O/P/Q/R/S/T/U/V/W/X/Y/Z J lis 0/1/2/3/4/5/6/7/8/9 i 6l APPENDIX B A SAMPLE TESLA PROGRAM S RSWD TIMES ^^ 62 BEGIN CASES (1I32]I SIGNAL GROUP INIA ( ABT-12--G0* ABT-28--G0)* IN2A (ABT-29— 60)1 STORAGE GROUP STO (TR0-12--L1#TR0»13— Ll)> SIGNAL GROUP IN3 ( ABT-**--G0)l DIGIT A a 2(0n*16' B«6(0i234b67)*4l SIGNAL GROUP BIGONE ( ABT-28--60#TR0-12— Ll * ABT-**— 60# INI A )| DATA PAT1 ■ 2C010101)# PAT2«2( OAl AOAl A } I DATA PAT3b6(0B162B3B4BSB6B7B}J STEPII INSET INIA I STEP2I INSET IN3 I STEP3I FFIN STO PAT2 f STEPai INSET Att0-**--60i STEP5I INCLR AS0-**--G0i STEPdl FFOLDI STEP7I INPUT iNlA 2(11)1 STEPSI INPUT IN3 2C0101010101U10101) I STEP9I 63 PRINT2 INIAI REPEAT 3 STEPlOl PRINT2 1N3; STEPllI PRINTS IN1AMN?A*ST0»IN3; STEP12I STEP13I PRAC2 Tn3 2(010101U101U10101)J STEP14t PRIU8 INIA 8(55) ; STEPIbl INSET rni6J iNi ; STEP16I INCLR AdT-**--GU I STEP17I »NSLT f U8] IN3 » [17I24J IN3 ; STEPlbl INPUT IM3 CIiKS] 2(111U111U1111U)« [i7|32] ? ( OUOOOOOOOOOOUUOO) j REPEAT 3 STEP19I INSET ri7l321 In3 J InCLR tltl6j INi t STEP20I INSET [ll8J iNlA f IN2A ; STEP?ll INSET I ' STEP22I INCLR I STEP23I 6k PHINT2 J STEP24I PRINT2 ALL t END, CONGRATULATIONS, NO SOUHCE PROGRAM ERRORS wERE DFTECTEO IN PASS 1 THE TOTAL TIME WAS MINUTES IA,6 SECONDS, TIML FOK INITIALIZATION! U MINUTES 3.6 SECONDS, TIME FOR SCANNING! W MINUTES 2,6 SECONDS, TIME FOrt PARSING! W MINUTES 4.« SECONDS, TIME FOK SEMANTIC ACTIONS! « MINUTES *tl SECONDS, TIME FOR EHROR RECOVERY! '<> MINUTES 0,0 SECONDS, TIME FOR DEBUG PRINTING! W MINUTES 0,0 SECONDS, 60 CARDS READ AT 246 CARDS PtR MINUTE. 65 APPENDIX C TABLES OF THE INTERNAL CODES OF THE OBJECT COMMANDS Tables of the Internal Codes of the Object Commands 1. Input Control Commands 6G Verbs Codes Octal Decimal FFl FF2 FF3 IWl JE2 IN3 inU EOF EOI 001 002 003 010 Oil 012 013 020 021 1 2 3 8 9 10 11 16 17 Print Control Commands 6? Verbs Co des Octal Decimal PRINT2 ooU k PRINTS 006 6 PRAC2 010 8 PRAC8 012 10 PR 102 01^ 12 PRID8 016 Ik UNCLASSIFIED Securitj^ClaMificjtion DOCUMENT COHTROL DATA R&D (SueuHty elmaaltlcmtlon of tlllo, body ol abattmcl and Indmmi^tg mmolmtton mutt fc> f»(«f»d wh»n Ota ovurmll report Is clmfltlmd) I. ORiGtNATiNG ACTIVITY (Cotporata author) Department of Computer Science University of Illinois at Urb ana- Champaign Urbana, Illinois 618OI a«. REPORT SECURITY C L Aisi Fl C A TtOM UNCLASSIFIED 2b. CROUP 3. REPORT TITLE TESLA, A CONTROL LANGUAGE FOR LOGIC SIMULATIONS OF DIGITAL CIRCUITS 4. DESCRIPTIVE NOTES (TYpa ol rapoTt and tneluaira dataa) Research Report 5. AUTHORISI (Ftrat nama, middla Initial, laat naaia) Nicole Genevieve Allegre S. REPORT DATE August 8, 1969 7a. TOTAL NO. OF PAGES 7^ yb. NO. OF REFS k ta. CONTRACT OR GRANT NO. ■ 46-26-15-305 b. PROJECT NO. USAF 30(602)i+l4i| aa. ORIGINATOR'S REPORT NUMBER(S) DCS Report No. 3^7 ab. OTHER REPORT NO(S) (Any otfiar number* that may ba aaalgpad thia raporl) 10. DISTRIBUTION STATEMENT Qualified requesters may obtain copies of this report from DCS. 11. SUPPLEMENTARY NOTES NONE 12. SPONSORING MILITARY ACTIVITY Rome Air Development Center Griffiss Air Force Base Rome, New York 13^40 13. ABSTRACT The folloving paper describes the syntax and semantics of a language;, called TESLA, designed to easily specify the control of logic simulations on a hardware level. The implementation on the B5500 of a translator from TESLA to an input language to the.ILLIAC IV Control Unit Logic Simulator is documented In detail. DO ,?o'r..1473 UHCLASSIFIED Security Classification UNCLASSIFIED Security Classification K EV WORDS Test Language Translator Simulator System Declarations Commands Test Step Input Signals Output Signals Storage Element Signals MOt.K imCLASSIFIED Security ClasBification J UNIVERSITY OF ILLINOIS-URBANA 510 84 IL6R no C002 no 343-348(1969 Internal raport/ 3 0112 088398653 I'k y C'