Browse Prior Art Database

Universal MONITOR Package Architecture

IP.com Disclosure Number: IPCOM000046337D
Original Publication Date: 1983-Jul-01
Included in the Prior Art Database: 2005-Feb-07
Document File: 5 page(s) / 39K

Publishing Venue

IBM

Related People

Barzilai, Z: AUTHOR [+2]

Abstract

The HASHTEST Universal Monitor Package is a family of programs for running simulation experiments, both to validate the approach to VLSI testing and to support the design within the approach. The architecture of the package is explained below.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 37% of the total text.

Page 1 of 5

Universal MONITOR Package Architecture

The HASHTEST Universal Monitor Package is a family of programs for running simulation experiments, both to validate the approach to VLSI testing and to support the design within the approach. The architecture of the package is explained below.

A series of overall design decisions yield an unusual combination of flexibility, maintainability, efficiency, and friendliness. The kind of simulation problem posed by the project is explained. Other problems of this general kind are solved by the architecture described here.

This disclosure exhibits program fragments in the syntax of PL/I and operating system commands in the syntax of VM/370 CMS/SP. Other programming and command languages could be used, so long as they provide the appropriate facilities.

Given a means for generating a procedure of the form

SIMUL : PROC (INPUT, OUTPUT,...);

. . .

. . .

. . .

END SIMUL ;

The input parameter INPUT specifies inputs to the device that will be simulated, the output parameter OUTPUT will receive the outputs of the device, and there may be other parameters. To exercise the simulator SIMUL in a useful way, many values of INPUT must be prepared, each corresponding OUTPUT must be examined, and results must be accumulated and eventually reported to files that the user can examine. Fig. 1 shows the design loop employing the instant architecture. The number of calls on SIMUL and the volume of data associated with each call are such that manual control is impossible.

To exercise SIMUL and monitor the results, at least one more procedure is required: MONITOR : PROC (...) OPTIONS (MAIN);

DCL SIMUL ENTRY (...);

...

DO WHILE (...);

...

CALL SIMUL (...);

...

END;

...

END MONITOR;

In general, there can be more than one call on SIMUL and there can be more than one loop. The simplest appropriate structure has been exhibited.

At first glance, it may appear that there are no architectural decisions to be made. Whoever wishes to perform an experiment should

1

Page 2 of 5

write MONITOR, compile it, and write a file of the form

FILEDEF ...

FILEDEF ...

...

LOAD MONITOR Simul_Name (START

where "Simul_Name" is a place holder for the CMS filename of the TEXT file for SIMUL. In general, "Simul_Name" would not be chosen to be "SIMUL" because simulators for more than one device may be of interest.

There is a great deal of variety in the kinds of MONITOR run that are needed. There is qualitative variety (for example, in the ways that values of INPUT will be prepared) and quantitative variety (for example, in the maximum number of SIMUL calls to be executed.) Any two runs may have much in common, but very little is common to all runs. Rewriting MONITOR for each run would be an intolerable programming burden. Instead, a single universal MONITOR must be flexible enough to perform all the desired experiments without undue loss of efficiency time. The time and space required for a run of type A should not be severely affected by the fact tha...