WO1991020032A1

WO1991020032A1 - Integrated development and maintenance software system

Info

Publication number: WO1991020032A1
Application number: PCT/US1991/004063
Authority: WO
Inventors: R. Stanley Bailes
Original assignee: Supercomputer Systems Limited Partnership
Priority date: 1990-06-11
Filing date: 1991-06-10
Publication date: 1991-12-26

Abstract

An integrated development and maintenance software system is used for the development and maintenance of a computer processing device. The integrated software system implements a target concept, where a target (16) can be actual hardware version (30) of the computer processing device under development, or a simulation (36) representation of the computer device. Applications can execute development and maintenance functions against any one of the multiple targets (16), without the application programmer having tailored the application to any specific target (16).

Description

INTEGRATED DEVELOPMENT AND MAINTENANCE

SOFTWARE SYSTEM

TECHNICAL HELP

This invention relates generally to the field of development, maintenance, and control of computers and logic systems. More particularly, the present invention relates to a method and apparatus for a set of integrated software programs exercised against a computer or logic system design, allowing for a common interface to multiple targets including hardware implementations and simulation representations of the design.

PACKGROUNP ART

The design, verification, construction, maintenance and operation of computer processing systems has become an extremely complicated task. This is especially true for high-performance multiprocessor systems, a class of supercomputers, that require the management of billions of pieces of information relating to both the hardware and software aspects of such computer processing systems. Traditionally, the design, verification, construction, and maintenance of computer processing systems was accomplished using paper designs and maintenance documentation. Hardware checkout was accomplished using external diagnostic instruments. Software debugging was usually a trial and error process performed with very few support tools. As computer processing and electronic logic systems have become more complicated, some of the control and maintenance functions were incorporated into both the hardware and software for the computer processing system. Presently, virtually every computer processing system offers some type of automated control and maintenance functions. Unfortunately, there has not been a completely integrated solution to providing the necessary control and maintenance functions for computer processing systems as complicated as supercomputers, nor has there been a software system which integrates the development and maintenance functions.

In the ETA-10 supercomputer developed by ETA Systems /Control Data Corporation, but now abandoned, the maintenance system utilized a Built-in Evaluation and Self-Test (B.E.S.T.) system which provided dedicated software and hardware to detect problems in the ALSI-20K gate array boards that comprised the logic unit for the ETA-10 supercomputer. The B.E.S.T. system used on-chip maintenance logic to perform array- level, board-level and board interconnection tests. The software for the B.E.S.T. system featured options for testing arrays, editing test output, controlling some aspects of the array operation and analyzing array and board logic. ETA-10 System Reference Manual, Technical Publication 1005, Rev. A, (Dec. 1987).

The related and co-pending application entitled CONTROL AND MAINTENANCE ARCHITECTURE FOR A HIGHLY PARALLEL MULTIPROCESSOR SYSTEM, PCT Serial No.: PCT/US91/0xxxx describes a new control and maintenance architecture for highly parallel multiprocessor systems. This architecture creates an integrated hardware and software solution to the control and maintenance of supercomputers, including a complete set of scan path diagnostic mechanisms integrated into every level of the hardware design of the computer processing system and a system of maintenance control units that monitor all aspects of the operation and performance of the system. Because of the tremendous amount of information that is managed by this architecture, traditional methods and systems for interacting with the maintenance and control systems are inadequate for dealing with the type of maintenance and control architecture that is described in the related application.

Although existing maintenance" software allows for some manipulation of maintenance and control information, it is very limited in scope. In addition, design verification is usually accomplished by a different method than hardware checkout and diagnosis. Typical, y, design verification is performed on simulators prior to actual hardware being available, while hardware checkout requires that actual hardware be built. Simulators provide for complete access to internal state information, while most maintenance hardware does not. The result is that existing design verification routines cannot be used to checkout hardware when it becomes available, and new hardware verification routines must be written. Consequently, there is a need for a single integrated interface to all the maintenance and control information for a computer processing system, during design verification, hardware checkout, and the capture and manipulation of state information used for debugging and maintenance and control purposes.

SUMMARY OF THE INVENTION The present invention provides a method and apparatus for creating an integrated Maintenance Software System (MSS). The MSS is an object oriented set of sof ware programs that can be run on a computer processing system to provide a single common interface to multiple "targets", including simulation representations and hardware implementations of a computer system. The maintenance routines of the MSS access all of the maintenance and control information for the computer processing system, regardless of whether the "target" is actual hardware, or a simulation of all or a portion of the hardware. This effectively allows the diverse tasks of design verification, hardware checkout, and the capture and manipulation of internal state information to use the same maintenance programs or "applications". The invention has the capability of applying code, tests, and data to all of these multiple environments and transferring internal states among them. The term "maintenance", as used in reference to the present invention, is intended to include design development and verification, hardware debug, and any other function capable of being performed on the MSS against any of the multiple targets.

In order to integrate diverse maintenance functions such as design development and hardware debug, the tools for each maintenance function operate on the same level and use the same command interface. By providing a common interface to all maintenance tools and run-time translation of target specific parameters, the compiled test program or routine will operate in any of the supported maintenance environments. An appropriate set of functions is provided so that any application is able to operate on any target by manipulating "objects" of the computer processing system design, and without requiring any "target specific" knowledge. New target environments (such as a new simulator) can be added to the integrated system by coding a few simple modules, and are immediately usable by existing applications. in addition to its use as a design verification and hardware checkout tool, the MSS provides a level of abstraction to the user of a simulation or hardware interface. This is particularly important in a highly parallel multiprocessor system, where the low-level parameters are so numerous as to make their manipulation very cumbersome without simplification to some level of abstraction. This is accomplished by providing a high- level "object-oriented" interface to the diagnostic and maintenance components of the computer processing system, while manipulating low- level parameters such as machine state registers.

The MSS according to a preferred embodiment of the present invention provides commands to support a variety of functions, including scan path sensing and setting (scan interface tests, scan functional tests), initiation of module self-test (module Built-In-Self-Test [BIST]), and application of test vectors. Other functions include: embedded array tests, functional tests (low level, code fragments, test programs), machine debugger (set/read/initialize state, start/stop/burst clock, etc.), system configurator (module on/off line, peripheral configuration, dead start, halt/continue, etc.), system monitor/logger (performance, error, o/s), and state dump (and reload from dump). The targets which these application functions support include, architectural simulation (with and without timing), software based gate level simulation (e.g. AUSIM, VERILOG), simulation via hardware accelerator, test fixtures (substrate, module, and brick), system environment (prototype, manufacturing, and field), and state dump analysis.

The central architectural feature of the MSS is the State Access Manager (SAM). For each particular target, there is a State Access Adaptor (SAA), which is written according to the specific internal features of the target. Maintenance functions are executed in two parts, a generic part handled by the SAM, and a target specific part performed by the State Access Adapters. The SAM provides functions to connect or attach a specified target, to read, write, or clear named state items, and to provide system clocks with start and stop means. The SAA modifies or senses the internal machine state parameters according to how they are defined in the selected target. A state dictionary is provided which includes parameter information for each component of the computer processing system, as defined by each of the supported targets. The state dictionary contains the pertinent information on all internal machine state parameters and any other observable or controllable parameter as desired. The state dictionary is accessed by the SAM through the State Dictionary Manager (SDM) during execution of maintenance functions.

Accordingly, it is an objective of the present invention to provide a method and apparatus for use by designers and developers of highly parallel multiprocessor computer systems for verification means in the design process. A MSS is used to develop and run software for system test, system level diagnostics, and low level design analysis. It also provides a level of abstraction to the user of a simulation/hardware device, thereby simplifying the programmer's task of manipulating internal machine states.

Another object of the present invention is to provide a basic set of common functions needed to control or test simulation and hardware systems, allowing any application to operate on any target, without requiring any "target specific" knowledge. Another object of the present invention is to provide an integrated maintenance software system, where additional target environments can be added by coding a few single modules and then will be immediately usable by existing applications.

Another objective of the present invention is to provide means for configuration of stand-alone and networked computer systems, especially highly parallel multiprocessor computer systems.

A further objective of the present invention is to provide a control means for computer systems, especially highly parallel multiprocessor computer systems. An additional objective of the present invention is to provide a maintenance means and interface for computer systems, especially highly parallel multiprocessor computer systems.

Still another objective of the present invention is to provide a diagnosis and troubleshooting means and interface for computer systems, especially highly parallel multiprocessor computer systems. These and other objectives of the present invention will become apparent with reference to the drawings, the detailed description of the preferred embodiment and the appended claims.

DESCRIPTION OF THE DRAWINGS

Fig. 1 is a functional block diagram of the of the Maintenance Software System (MSS) from a user perspective.

Fig. 2 is a block diagram of the architectural structure of the Maintenance Software System (MSS), showing the relationship of the various parts.

Fig. 3 shows a hierarchical block diagram of a portion of a system, relating C++ objects to the parts of the system they represent.

Fig. 4 shows an example code structure for implementing a state dictionary. Fig. 5 shows an example of the hierachical tree structure of a state dictionary.

Fig. 6 shows an example of a look-up table, easing traversal of the state dictionary tree.

DESCRIPTION OF THE PREFERRED EMBODIMENTS The following description of the preferred embodiment of the present invention assumes a working knowledge of UNIX shell commands, with commands according to the present invention being described by MAN pages (manual pages) appearing in this specification as Appendix A. Referring now to Fig. 1, a Maintenance Software System (MSS) 10 according to the present invention is shown. The MSS 10 includes a user interface 12, the Maintenance Command Execution Routines (MCER) 14, and multiple targets 16. The user interface 12 provides the user with a presentation of available user commands, shown here organized into operational catagories.

Although any appropriate complement of functions could be provided, depending upon the particular type of system involved, the preferred embodiment is directed toward a computer processor device in the complement of functions provided. The commands provided by the user interface 12 and the MCER 14 are preferably implemented as an application running under Unix, however, those skilled in the art will recognize that they may be implemented in any appropriate manner without departing from the scope of the present invention.

The environmental control functions 18 enable the MSS user to connect to or disconnect from a desired simulator target 16 for the purpose of executing native simulator commands (mssdirect), or to set or display the currently selected machine state node within the target 16 (msscnode). The transfer state functions 20 allow internal machine states of the target to be set by loading a machine state file into the target (mssloads), or to dump a state from a target to a machine state file (mssdumps). Session control functions 22 allow the user to attach to a desired target 16 (mssattach), or detach from the current target 16 (mssdetach). The examine state functions 24 allow the user to list values and attributes of internal machine state nodes (msslist). The modify state functions 26 allow the user to assign actual values to internal machine state nodes (mssassign). The dock control functions 28 allow the user to issue a clock burst of a specified number of cycles (mssburst).

Note that this complement of functions is illustrative only, and that one skilled in the art will be able to substitute an alternate complement of functions or add additional functions according their specific needs. A summary of each of these functions and an introduction to the User Interface 12 (mssintro), appears in Appendix A of this specification.

Still in reference to Fig. 1, the MCER 14 contains the necessary software routines for executing commands as requested by the user through the user interface 12. These commands operate on the desired target, manipulating the target's operating parameters in a manner appropriate for that target. The MCER 14 will be more fully described in reference to Fig. 2.

The targets 16 shown in the preferred embodiment include a complete hardware implementation 30 of a computer processing system such as a highly parallel multiprocessor computer system, hardware subsystems 32 such as equipment testers and independent components of a highly parallel computer system, test fixtures 34 such as board testers and chip testers, an architecture simulator representation 36 of the system, software based gate level simulation representations such as by using VERILOG 38 (available from Gateway Design Automation Corporation) and AUSIM 40 (available from CAD Artisans), and a hardware accelerator 42, used to design, test, and verify the simulations of the computer processing system.

Those skilled in the art will recognize that additional or different targets 16 can be added as desired to the MSS 10 without departing from the scope of the present invention.

Referring now to Fig. 2, the architectural structure of the maintenance software system (MSS) 10 is shown. An application 50 can be an interactive presentation of function commands to a user, or can be an automated test sequence. The application 50 is linked to a library of functions libmss 52, which includes all the routines necessary to execute a command received from the application 50 against the desired target 16.

Functions included in the library libmss 52 include several high level functions indicated as state dump routines 54. These state dump routines 54 perform file services associated with the maintenance system, including dumping machine states to a disk file, reloading a machine state from a file, and comparing a machine state to one stored in a file. These functions in turn call lower level functions within libmss 52 as required.

The lower level functions found in libmss 52 are generally divided into one of two groups, the State Access Manager (SAM) 56 and the State Dictionary Manager (SDM) 58. The SAM 56 operates as an interface between the application 50 and the various targets 16, performing functions such as read, write, and clear for named machine state items; start, stop, and step of system clocks; and attachment to the various targets 16. The functions supported by the SAM 56 are more fully described in Appendix A of this specification. The SAM 56 operates on a target 16 through a State Access Adapter (SAA) 60 associated with a particular target 16. The SAA sets or reads machine states of its associated target 16 in the manner required by that target 16. For example, if a hardware target is selected, the associated SAA 60 may set a machine state by passing data through scan paths, and writing the data into actual machine state registers. If the target is a software simulation, the same machine state initialization might occur by setting software variables internal to the simulation software.

The target-unique information used by the SAM 56 in operating on a specific target 16 is contained in a state dictionary 62. The embodiment shown depicts a single state dictionary 62 containing all of the necessary target-specific information for all the targets. Alternatively, there may be advantages to having multiple dictionaries 62. For example, a separate dictionary could be provided for each target 16, allowing incremental compilation of dictionary information in the event that a target definition is changed. Access to information within the state dictionaries is managed by the state dictionary manager 58, using functions such as opening and closing dictionaries, finding a particular machine state item, and retrieving attributes of a machine state item particular to the given target. This information is the used by the SAA 60 to operate on the target in the manner required for that target. A maintenance function is thus able to perform transformations of the machine state on the particular target being used without the high level maintenance program specifying any target-unique parameters.

In order to provide a user interface that is target independent, the target specific parameters must be hidden from the application programmer. According to the preferred embodiment of the present invention, this is accomplished in part by choosing a programming language that provides support for operations on user defined data types, as well as providing powerful and convenient tools in a familiar implementation. The language chosen according to the preferred embodiment is C++ (developed by AT&T, and available from AT&T and others). C++ is an enhancement of the C programming language, and provides the additional facility of type checking, data abstraction, operator overloading, and object oriented programming. The notion of 'class', which is a user defined variable type, is a key concept in C++, and in the present invention allows the target-specific parameters to remain hidden from the application programmer. With the class concept, programming support is available for data hiding, guaranteed initialization of data, implicit type conversions, dynamic typing, user-controlled memory management, and operator overload. An important feature of C++ is that it retains the important familiar programming style of C, especially the ability to deal with defined hardware features, which is important when executing against a target implemented in actual hardware. An in-depth discussion of C++ is beyond the scope of this specification. For more information on C++ programming, the reader is referred to a book entitled: The C++ Programming Language, authored by Bjarne Stroustrup and published by Addison-Wesley Publishing Company.

By using the C++ class concept and defining appropriate objects, unwieldy state parameters are easier to manipulate by the maintenance application programmer, while the target-specific details of the machine state remain hidden. The objects defined in the preferred embodiment of the SAM 56 include unit, reg, ram, and others which are more fully described in the MAN page for libmss 54, which appears in this specification as Appendix B. These objects are used to uniquely describe each state parameter of the entire system, be it actual hardware or a simulation of actual hardware.

Referring now to Fig. 3, a hierarchical block diagram of a portion of a system is shown, relating C++ objects to the portions of the system they represent. A single CPU is shown, called CPU_n 64, which contains multiple chips. One of these chips, CH-P_m 66 is shown, which contains a Program Counter (PC) 68 and an Instruction Cache (IC) 69. A state dictionary 62 will be constructed in a hierarchy analogous to that of the system. The PC 68 will be represented in the state dictionary by a "reg" object named PC, and the IC 69 by a "ram" object named IC. CPU_n and CHIP_m are represented by "unit" objects named CPU_n and CHIP_m, respectively. These objects are identified in the state dictionary 62 in such a way as to retain their relative hierarchy as shown in Fig. 3. The structure of state dictionaries 62 will be discussed in further detail in reference to Figs. 5 and 6. As is seen from Fig. 3, the "unit" object is the basic building block of the hierarchical design, corresponding to various sub-parts of the system, with the "reg" and "ram" objects referring to specific machine state parameters or other controllable or observable components. Regs and rams differ in that a reg has only a single dimension (the number of bits wide) and a ram has two dimensions (both width and a depth). In the preferred embodiment of the present invention, regs can be of different types, depending upon the type of information they observe or control. For example, a reg could be a scanned register or test point pins on a particular chip. A ram could be an embedded memory on a particular chip, or could be any other machine parameter having two dimensions. In addition, both regs and rams can be of a "rename" type, where the object is a rename of another object. For example, a rename type reg might be one location in a ram object, but expressed as a reg for convenience. In addition, a rename type ram might be a grouping of several reg objects, expressed as a single ram due to their collective significance. The unit, reg, and ram objects are also described in the MAN pages located in Appendix B of this specification.

Those skilled in the art will recognize that other objects could be added without departing from the scope of the present invention. Specifically, objects referring to multi-dimensional components of the system could be added. This might be advantageous if there is design significance to treating a complex or multi-dimensional construct as a single object.

Target specific information concerning a given machine state parameter is retrieved from the state dictionary by having the parameter identified in terms of the hierarchical units it is contained within, passing down the analogous hierarchy in the state dictionary until the desired reg or ram is located, and then retrieving the desired information.

The hierarchy depicted in Fig. 3 is an example only, and those skilled in the art will recognize that modifications can be made without departing from the scope of the present invention. Specifically, the hierarchy can be depicted from a physical or a logical view of the design of the system, or some combination of the two. For example, if a design engineer is debugging the hardware design of a particular portion of the system, he or she is likely to identify machine state parameters in terms of the physical location of the register or memory. The hierarchical identity of the register or memory might include physical "units" such as cabinet, circuit board, and chip, all leading to identification of a specific register or memory. The specific physical partitions are not important, only that the physical portions chosen have significance to the engineer in uniquely identifying the register or memory desired. In addition, the hierarchy could be from a logical perspective. An operating system engineer may be interested in manipulating the contents of the same register or memory, but doesn't know (or care) where the register is physically located. Rather, he or she may refer to the register as PC_n in CPU_n (for example), without wanting to be bothered by the fact that it is located in CHIP_m. Thus, a hierarchy that partitions the system into hierarchical layers from a logical viewpoint can also be used to uniquely identify each machine state parameter. In the preferred embodiment of the present invention, both a physical and logical hierarchy are provided in the state dictionary 62, each hierarchy providing an identification path to every machine state parameter in the system.

Within the C++ programming environment, an expression in the test code which involves a reg or ram object causes the MSS 10 to actually read the indicated machine state parameter. Referring again to Fig. 2, assigning a value to a reg or ram object will cause the maintenance subsystem to set the specified machine state to the specified value. This operation is performed by interaction of the application 50 with the various parts of libmss 52. The operations come from the application 50 in the form of a function calls, which cause the SAM 56 to select the SAA 60 corresponding to the desired target 16, and to translate the operation into a command in the form required by the particular target 16. Information on the particular parameter being operated on by the operation from the application 50 is requested from the SDM 58, which searches the hierarchy of the state dictionary 62 for the desired information. The translated command is then issued to the target 16 through the appropriate SAA 60.

The full complement of arithmetic and logical operations can be supported for regs and rams, and are defined in a manner known to one skilled in C++ programming.

Referring now to Fig. 4, an example of source code for a state dictionary representing the hierarchy of Fig. 3 is shown. In this example, the unit named CPU_n (defined between lines 1 and 17) contains parameters corresponding to CPU it represents, as well as a lower level unit. The lower level unit is named CHIP_m (defined between lines 4 and 16) and corresponds to a particular chip within CPU_n. If CPU_n contains multiple chips, the state dictionary would of course contain multiple chip definitions within the CPU_n definition. Within CHIP_m are two machine state parameters, PC (defined between lines 7 and 10), and IC (defined between lines 11 and 14).

The resulting state dictionary can be" represented in the tree diagram of Fig. 5. Each node (represented by a circle) contains the pointer to the block of descriptive information shown in the code of Fig. 4. This block of information also can contain pointers to related nodes, such as parent to child, child to parent, and sibling to sibling. In this example, the CPU_n node 70 is at the top of the hierarchy, and contains the child node CH-P_m 72. Movement within the dictionary from parent to child 74 and from child to parent 76 occurs by operation of the pointers relating the two, in a manner known in the art. In a lifce manner, movement can occur between siblings such as from PC node 78 to IC node 80. In the preferred embodiment, pointers relating the nodes are contained in a singly linked list, as depicted with arrows in the tree diagram of Fig. 5. A structure corresponding to each node contains a pointer to the parent node, a pointer to one child node, and a pointer to one sibling node. By proper selection of the sibling node pointers, all siblings become part of the chain of pointers and are accessible to state dictionary management tools. In a preferred embodiment of the present invention, every node in the state tree is an "sd_item" object, and C++ allows the unit, reg, and ram objects to be derived from the sd_item object, as is known to one skilled in C++ programming. This arrangement allows for the development of state dictionary management tools which operate on sd_item objects, without needing to know whether the object is a unit, reg, or ram object. This may reduce the number of state dictionary management tools needed, depending upon the specific application of the present invention.

Referring now to Fig. 6, a reference table is shown corresponding to the tree diagram of Fig. 5, but with the addition of a CHLP_p node (reference number 3) not shown in Fig. 5. Although the tree structure of the state dictionary contains all the information necessary to manipulate any machine state parameter, and all the information describing how the parameters and hierarchical portions of the system interrelate, the tree may be quite large, and task of traversing the tree locating the desired parameter could be time consuming. Under these circumstances, the reference table of Fig. 6 can be used to speed up the task of locating specific parameters in the state dictionary.

As seen in Fig. 5, each node 70, 72, 78, 80 has associated with it a unique reference number, which can be used to more quickly access the desired node. If the parent node of the desired node is known, and the name of the desired node is known, then the reference number of the desired node can be found in the reference table. The reference table is implemented as an "ndbm" database, which is a standard Unix library providing keyed data retreival using user-defined keys and data. In operation, the database is provided with the parent reference number and the desired node name as search keys, and the reference number and a state dictionary offest is retreived. The state dictionary offest is then used to index into the state dictionary to located the desired node information. Note that this procedure will work^* only if no parent node has two children with the same name.

Appendix A NAME mssassign - assign values to SSI REG & RAM state nodes

SYNOPSIS mssassign reqnamelramname[range] val [val...]

DESCRIPTION mssassign is one of the commands that compose the MSS "user interface." Its purpose is to enable an MSS user to assign new values to SSI state nodes (as used in this context, SSI means either a simulated or physical, complete or partial SSI system.)

OPTIONS regname

The name of a REG state node that val is to be applied to.

A regname has the same syntax and semantics as a node ame described in msscnode(l).

ramname The name of a RAM state node that 'val [val...]' is to be applied to. A subrange of a RAM state node may be assigned to by appending a range specification to ram- name.

A ramname has the same syntax and semantics as a nodename described in msscnode(l).

range

A specification of a subrange of a RAM state node to be operated on.

A ranqe spec is of the form '[mln]' or '[mln..max]' where min is the smallest RAM index to start operating on, and max is the largest RAM index to operate on. All RAM elements between mln and max will be operated upon.

val A value to be applied to a REG or a RAM cell.

If regname is supplied, the first val is assigned to it, and any others supplied are ignored.

If ramname is supplied and the number of val's supplied is egual to or more than the number of RAM elements to be assigned to, the val's are assigned to RAM elements in increasing index of RAM element number from left to right, as supplied. Excess val's are ignored.

If ramname is supplied and the number of val's supplied is less than the number of RAM elements to be assigned to, the val's are assigned to RAM elements in increasing index of RAM element number from left to right, until exhausted. All remaining RAM elements will be assigned the value of the last val supplied.

SEE ALSO

X mssattach(l), msscnode(l), mssintro(l)

EXAMPLES

To assign a new value to a REG state node

% mssassign <regname> <val>

To set all elements of a RAM state node to O

% mssassign <ramname> O

To assign new values to a subrange of a RAM state node

% mssassign <ramname>[3..8] 3 4 5 6 7 8 DIAGNOSTICS

'regname' not found

No REG state node, corresponding to regname. could be found.

'ramname' not found

No RAM state node, corresponding to ramname, could be found.

can't assign a field to this type of unit.

An attempt has been made to assign a value to a non-REG or non-RAM state node.

can't assign a vector to this type of unit. An attempt has been made to assign values to a non-RAM state node.

only <values>[0..<valcount>] assigned to 'ramname' More val's were supplied than needed.

'ramname' [<x>..<y>] assigned <value>[<last>]

Less val's were supplied than the number needed, so the elements <x> through <y> of ramname were assigned the last supplied val.

NAME mssattach - attach to an SSI

SYNOPSIS mssattach [[[attach id] dictionarv] target [target opts]]

DESCRIPTION mssattach is one of the commands that compose the MSS "user interface." Its purpose is to enable an MSS user to attach to an SSI (as used in this context, SSI means either a simulated or physical, complete or partial SSI system.) Attaching to an SSI involves making a connection to one of several State Access Adapters (SAA). A State Access Adapter provides a consistent interface between programs that manipulate SSI internal state, and various simulators and device dr~ivers that contain or provide access to SSI state. A program written to work with one representation of an SSI, via an SAA, will work with the same representation of an SSI via another SAA. The SAAs operate on a representation of an SSI's state that has been compiled, by sdlc(l) into a state dictionary. In addition to needing -he name of the state dictionary to operate on, the SAAs themselves may need special options when they are first attached to. All of this information is supplied to an SAA with the mssattach command.

If no options are provided, a list of current attach instances, and their attributes (dictionarv, target, target optS. and if currently attached) is printed to standard output.

If only an attach id option is supplied, and an attach instance by that name exists and is not currently attached to its target, a re-attach to the instance's target is attempted. (An attach instance can be detached from its target using mssdetach(l).)

If only attach id and dictionarv are supplied, dictionarY is opened for browsing. Using other MSS commands, the hierarchy and attributes of the nodes in the state dictionary can be examined (this can also be done when an attach instance is attached to its target).

If an attach instance exists and is not currently attached to its target, supplying dictionary, target, or target opts will replace previous options with the new ones. To simply re-attach to a previous attach instance, use mssattach attach id.

OPTIONS attach id

A user selected name that identifies an attach instance.

dictionary The name of a particular state dictionary, that represents an SSI.

target The name of a particular SAA to connect to. The possible values of this option are:

sim - logic simulator

scan - Level Sensitive Scan Design (LSSD) hardware access

simlpty - SSI Architectural Simulator (SIM1) via pseudo-tty connection

simlrpc - SSI Architectural Simulator (SIM1) via rpc connection

If this option is not supplied, dictionary is opened for browsing only.

target opts

A list, possibly empty, of options that affect a particular SAA. Refer to information about a particular SAA for its specific options and their purpose. The SAAs are described in man pages named saa <target> in manual section 3 (e.g. saa sim(3)).

SEE ALSO X mssdetach(l), mssintro(l), sdlc(l)

EXAMPLES

To list the currently active attach instances

% mssattach

To open and browse a state dictionary % mssattach <attach id> <some dictionary>

To connect to an SSI logic simulation

% mssattach <attach id> <some dictionary> sim <sim opt>...

DIAGNOSΗCS a dictionary name must be supplied

It is necessary to supply at least a dictionarY name with an attach id if this is the initial attempt to create an attach instance.

dbm open failed for 'dictionary'.

The supplied ~ uld not be opened by the MSS library. Double check to see that the dictionary exists, has been compiled by sdlc(l), and is readable by the process from which mssattach is being invoked.

unit 'attach id' attach failed.

An error was reported by the MSS library in the process of trying to create this attach instance. Another error message should have been reported to standard error just prior to this one. This is the report generated by the MSS library routine that encountered the error and should point to the source of the trouble.

Invalid target An invalid target name was entered.

NAME mssburst - step an SSI dock by a count

SYNOPSIS mssburst fpulsenamel fcount] DESCRIPTION mssburst is one of the commands that compose the MSS "user interface." Its purpose is to enable an MSS user to step an SSI's docks by a specific count (as used in this context, SSI means either a simulated or physical, complete or partial SSI system.)

If no pulsename option is provided, and the current node (see msscnode(D) is a PULSE state node, then count is applied to the current node.

If no count option is specified, a count of 1 is used.

OPTIONS pulsename The name of a PULSE state node that count is to be applied to.

A pulsename has the same syntax and semantics as a nodename described in msscnode(l).

count The number of dock steps to apply to the SSI.

SEE ALSO

X mssattachd), msscnode(l), mssintro(l)

EXAMPLES

To step an SSI 1 clock.

% mssburst <pulsename>

To step an SSI 10 dod s.

% mssburst <pulsename> 10

DIAGNOSTICS 'pulsename' not found

No PULSE state node, corresponding to pulsename, could be found. NAME msscnode - set/display the 'current' SSI state node

SYNOPSIS msscnode fnodenamel

DESCRIPTION msscnode is one of the com~ands that compose the MSS "user interface." Its purpose is to enable an MSS user to set and display the "current" SSI state node (as used in this context, SSI means either a simulated or physical, complete or partial SSI system.) The current state node is simply a point of reference for other commands to use.

rf no options are provided, the name of the current state node is printed to standard output.

OPTIONS nodename

The name of an SSI state node to set as the current state node.

SSI state nodes are related to each other via a hierarchical binary tree structure. A particular state node can have several direct descendants (children), but can have only a single direct ascendant (parent). Each state node has its own identifier, and a nodename is made up of a, possibly empty, dot ('.') separated list of state node ids, optionally preceded by carets C~'), e.g. a.b.c, ~ d.e.f. The search for a state node id corresponding to nodename always starts at the current state node. If no state node is currently set, then each attach instance is searched.

Each caret preceding the node ids, causes the search start reference point to be raised one ascendant level prior to starting the search (this is similar in concept to the '..' filename in UNIX(tm)). For purposes of constructing a nodename, attach instance names (see mssattach(l)) are treated as spedal state node ids that can occur only as the first node id in a nodename.

The search for the state node corresponding to nodename proceeds as follows:

1. The initial search reference point is set to the current node.

2. Leading carets are processed as described above and stripped from nodename.

3. If a state node corresponding to nodename is a descendant of the current reference node, then current node is set to that state node and the search exits successfully. Otherwise, step 4 is performed.

IL the current reference node has a parent, the search reference node is set to it and step 3 is repeated, otherwise the search aborts in error.

SEE ALSO X mssintro(l), mssattach, mssassign(l), mssburst(l), msslist(l)

EXAMPLES

To list the current state node

% msscnode

To change the current state node

% msscnode <nodename>

DIAGNOSTICS

'nodename' not fcund No node, corresponding to nodename, could be found. NAME mssdetach - detach from an SSI

SYNOPSIS mssdetach [attach id]

DESCRIPTION mssdetach is one of the commands that compose the MSS "user interface." Its purpose is to enable an MSS user to detach from an

SSI (as used in this context, SSI means either a simulated or physical, complete or partial SSI system.) Detaching from an SSI involves breaking a connection to an attach instance's target (see mssattach(l).) If this command is executed on an already disconnected attach instance, that instance is removed from the attach instance list.

If no options are provided, a list of current attach instances, and their attributes is printed to standard output.

OPTIONS attach id

The name of the attach instance to disconnect from its target. If the attach instance is already disconnected, it will be removed from the attach instance list.

SEE ALSO

X mssattach(l), mssintro(l)

EXAMPLES

To list the currently active attach instances

% mssdetach

To disconnect an attach instance from its target (or remove it from the attach instance list if already disconnected) % mssdetach <attach id>

DIAGNOSΉCS no attach name 'attach id' found There is no attach instance named attach id in the current list.

unit 'attach id' detadi failed.

An error was reported by the MSS library in the process of trying to disconnect this attach instance. Another error message should have been reported to standard error just prior to this one. This is the report generated by the MSS library routine that encountered the error and should point to the source of the trouble.

NAME mssdirect - interact directly with an SSI simulation

SYNOPSIS mssdirect [attach id]

DESCRIPTION ' mssdirect is one of the commands that compose the MSS "user interface." Its purpose is to enable an MSS user to interact directly with an SSI simulation (as used in this context, SSI means a simulated, complete or partial SSI system.) Interacting directly with an SSI simulation involves executing native simulator commands, such as the SSI Architectural Simulator (SIM1). In this mode, standard input from the user's terminal is directed to the simulator and standard output from the simulator is delivered to the user's terminal.

If no options are provided, an attempt is made to use the simulator assodated with the current node (see msscnode(D).

To terminate a direct connection session, enter either the simulator's normal guit or exit command or EOF (usually CNTL-D). OPTIONS attach id

The name of the attach instance whose simulator is to be directly interacted with.

SEE ALSO

X mssattach(l), msscnode(l), mssintro(l), siml(l)

EXAMPLES

To interact diredly with the current node's simulator

% mssdirect

To interact directly with a specific attach instance's simulator.

% mssdirect <attach id>

DIAGNOSTICS saa::do cmd() not implemented for this target

The SAA associated with this attach instance does not support direct interaction with its underlying simulator.

no attach name 'attach id' found

There is no attach instance named attach id in the current list. NAME mssdumps - dump SSI state to a file

SYNOPSIS mssdumps [attach id] filename

DESCRIPTION mssdumps is one of the commands that compose the MSS "user interface." Its purpose is to enable an MSS user to dump machine state from an SSI to a state file (as used in this context, SSI means either a simulated or physical, complete or partial SSI system.) A state file is loaded back into an SSI with the mssloads(l) MSS command.

If no attach id option is provided, machine state is dumped into filename from the SSI associated with the current node (see msscnode(D).

filename The name of an SSI machine state file.

OPTIONS attach id

The name of the attach instance whose SSI is to be dumped into filename.

SEE ALSO

X mssattach(l), msscnode(l), mssloads(l), mssintro(l)

EXAMPLES

To dump machine state from the SSI associated with the current node

% mssdumps <statefile>

To dump machine state from the SSI assodated with a specific attach instance.

% mssdumps <attach id> <statefile>

DIAGNOSTICS no attach name 'attach id' found

There is no attach instance named attach id in the current list. NAME mssintro - Maintenance Software Subsystem Commands Introduc¬ tion DESCRIPTION

The Maintenance Software Subsystem is designed to facilitate design verification, diagnosis, and maintenance of the SSI (as used in this context, SSI means either a simulated or physical, complete or partial SSI system.) The MSS Commands compose the MSS

"user interface", and enable MSS users to:

X Connect to or disconnect from an SSI

X Examine or set state within an SSI

X Dump or load state from one SSI to another

X Step, run, or halt docks of an SSI

The MSS commands, each of which is described in its own man page, are:

mssattach - attach to an SSI

mssdetach - detach from an SSI

msscnode - set/ display the 'current' SSI state node (a point of reference for other commands)

mssdirect - interact directly with an SSI simulation /hardware device driver

msslist - list attributes/values/children of SSI state nodes

mssassign - assign values to SSI REG /RAM state nodes

mssburst - step an SSI clock by a count

mssloads - load SSI state from a file

mssdumps - dump SSI state to a file These particular MSS command^* names, verbose as they are, were selected to avoid potential name collisions with other command/utility or alias names.

The mss option uses 'set' to enable/ disable all MSS commands, except mssversion (which is always enabled.) When mss is 'on', the MSS commands are enabled. Two additional compiled-in aliases are supplied to better support this feature. These aliases, which can be unset or redefined, are:

mssoff='set +o mss' msson='set -o mss;mssver'

The MSS commands are disabled by default.

SEE ALSO

X mssassign(l), mssattach(l), mssburst(-), msscnode(l), mssdetach(l), mssdirect(l), mssdumps(l), msslist(l), mssloads(l), mssversion(l)

NAME msslist - list a~tributes and values of SSI state nodes

SYNOPSIS msslist [-almprRtuvV][dlx] fnodelist]

DESCRIPTION msslist is one of the commands that compose the MSS "user interface." Its purpose is to enable an MSS user to list attributes and values of SSI state nodes (as used in this context, SSI means-either a simulated or physical, complete or partial SSI system.)

If no nodelist is supplied, then the current node is operated on.

If no '-' arguments are supplied, the following defaults apply: X If there is no current node, then the names of the attach instances are printed to standard output.

X If the state node being operated on is a UNIT, the node's children UNIT, REG, RAM, and PULSE names, and their types are printed to standard output.

X If the state node being operated on is a REG or a RAM, and that state node's attach instance is connected to an SAA, then the state node's value is printed to standard output.

X If the state node being operated on is a REG or a RAM, and that state node's attach instance is not connected to an SAA, then the state node's attributes are printed to standard output.

X If the state node being operated on is a PULSE, its attributes are printed to standard output.

OPTIONS nodelist

A space separated list of one or more nodenames (see msscnode(D) to operate on. Each node is listed in the order supplied.

a List state r.ode attributes.

1 List a state nodes attributes and values (-1 is eguivalent to - av).

m Operate on RAM state nodes.

p Operate on PULSE state nodes.

r Operate on REG state nodes. R Recursively operate on all nodes from the starting node.

-» t Operate on all state node types (-t is eguivalent to -mpru).

u Operate on UNIT state nodes.

v List state node values.

V List information verbosely.

d List values in dedmal (when possible — fields larger than

Ox7fffffff currently can only be displayed in hexadedmal). If d is spedfied, and a field larger than Ox7fffffff is encountered, a diagnostic will be printed. If neither x or d are specified, values will be printed in decimal format whenever possible.

x List values in hexadedmal. If neither x or d are spedfied, values will be printed in dedmal format whenever possible (fields larger than Ox7fffffff currently can only be displayed in hexadedmal).

SEE ALSO

X mssattach(l), msscnode(l), mssintro(l)

EXAMPLES

To list the current state node's attributes

% msslist -a

To list all children of a current node that is a UNIT, or to list the value of a current node that is a REG or a RAM

% msslist

To Hst all PULSE state nodes in an attach instance. NOTE: this operation will also list each UNIT state node, because each one has to be visited to check for the existence of PULSE state nodes. This is more a bug than a feature and may go away in future releases.

% msslist -pR <attach id>

To list several REG or RAM node's values, in hex

% msslist -vx rega rama regb regc ramb ramc ...

DIAGNOSTICS

'<nodename>' not found

One of the <nodename>s in nodelist could be found.

Not attached An attempt was made to Hst the value of a REG or RAM state node, but the attach instance assodated with that node is not connected to a SAA.

ios::dec not implemented for fields > Ox7ffffff The -d option was specified and a field > Ox7fffffff was encountered. The current libmss does not support displaying these fields in decimal. NAME mssloads - load SSI state from a file

SYNOPSIS mssloads [attach id] filename

DESCRIPTION mssloads is one of the commands that compose the MSS "user interface." Its purpose is to enable an MSS user to load machine state from a state file into an SSI (as used in this context, SSI means either a simulated or physical, complete or partial SSI system.) A state file is created with the mssdumps(l) MSS command. If no attach id option is provided, machine state is loaded from filename into the SSI assocfated with the current node (see msscnode(D).

filename

The name of an SSI machine state file.

OPTIONS attach id The name of the attach instance whose SSI is to be loaded with the state contents of filename.

SEE ALSO

X mssattach(l), msscnode(l), mssdumps(l), mssintro(l)

EXAMPLES

To load machine state into the SSI assodated with the current node

% mssloads <statefile>

To load machine state into the SSI assodated with a specific attach instance.

% mssloads <attach id> <statefile>

DAGNOSTTCS no attach name 'attach id' found

There is no attach instance named attach id in the current list. Appendix B

NAME

Hbmss - Maintenance Software Subsystem

SYNOPSIS

Classes: object, fidd, vector, number, string, sd item, unit, ram, reg, pulse, sd iterator, INFO, SDNODE, program, msserror.

DESCRIPTION Hbmss implements the functions of the SSI Maintenance Software

Subsvstem. Broadly speaking, this subsystem consists of three main parts - The State Dictionary Manager, the State Access Manager, and Utility functions.

The interface to this Hbrary is through a set of C++ classes. These classes are briefly outlined in this document; more detailed descriptions can be found in the man pages for each class.

Most Hbrary functions return either objects (derived from class obiect) or results of type STATUS (defined as part of msserror.) This allows the user of the Hbrary to check the results of aU maintenance software functions. Alternately, the user can define an error handler which gets control when an error is detected by a Hbrary routine.

object -

This is the base class from which almost all other classes are derived. The primary operations defined for this class are statusO, which is used to return error values resulting from dass operations.

field -

This class implements arbitrary precision unsigned integers, and arithmetic operations on such integers.

vector - This dass implements arrays (one or two dimensional) of arbitrary predsion unsigned integers (i.e., arrays of fields.)

5 number -

This dass is basically a long variable with an statusO, to aUow functions which return longs (typicaUy retreived from a State Dictionary) to have a completion status which can be checked by the caUer.

10 string -

This class basically implements "pointer to const char*". As with the number class above, the main reason for this dass is the assodation of a completion

15 status with the string data.

sd item -

An sd item is a node in the state tree of some State Dictionary. The root level sd item is constructed (found) by 20 supplying a State Dictionary name and mode (read, write, or update). Other sd items are dedared by supplying the parent sd item and the new sd item name.

unit -

25 A unit is an sd item which is associated with a particular simulation or hardware under test. The root level unit is constructed by supplying a State Dictionary name and a hardware address. Subseguent units are constructed by supplying the parent unit, and

30 the new unit name.

reg

This class implements operations on objects which represent register (i.e., latch, ^.ipflop)

35 items. Assignment, arithmetic, and conversion functions are implemented for reg objects. ram -

This class implements operations on objects which represent RAM or memory items.

Indexing, assignment (element and block assign), and conversion functions are implemented for ram objects.

pulse -

This class implements operations on objects which represent clock seguences which can be applied to hardware or simulation units.

INFO -

This dass is a general container dass which is used to hold objects which are to be written to or read from a

State Dictionary file. Each class which implements objects which need to be stored in a State Dictionary must implement the virtual object function passivate(INFO&), and must implement a constructor fundion which allows an object of that class to be constructed from an INFO.

program -

This dass implements operations whidi aUow another program to be executed so that the standard input and standard output of that program can be written and read (respectively) from the calling program.

sd iterator - This class implements operations which allow traversal of the state "tree which comprises a State Dictionary. Given a node in the state tree, the sd iterator::next() function returns successively all of the direct children of that node in the tree.

msserror - This class encapsulates various types of error information and provides several functions to allow customization of error handling strategy when using Hbmss.

FILES

/usr/nseenv/Hb/Hbmss.a /usr/nseenv/indude/*.h

SEE ALSO objed(3), field(3), vector(3), number(3), string(3), sd item(3), unit(3), ram(3), reg(3), pulse(3), sd iterator(3), INF0(3), SDNODE(3), program(3), msserror(3).

Although the description of the preferred embodiment has been presented, it is contemplated that various changes could be made without deviating from the spirit of the present invention. Accordingly, it is intended that the scope of the present invention be dictated by the appended claims rather than by the description of the preferred embodiment.

We daim:

Claims

CLAIMS-.

1. In a computer based development and maintenance system, a method of executing maintenance instructions against any desired target of a pluraHty of targets, the method comprising the steps of: providing a target-independent user interface; receiving a command from an operator via the user interface; translating the command to a target-specific form as reguired by the desired target; and executing the translated command against the desired target.

2. An integrated development and maintenance architecture, enabling tests written in a common language to be applied to a plurality of targets, the architecture comprising: a user interface means for providing a plurality of development and maintenance commands; a plurality of targets against which at least one of said plurality of development and maintenance commands can be executed; and command execution means for converting a command issued through said user interface means into a target-specific form, and executing the resulting converted command against a desired one of said pluraHty of targets.