Version 3.0
April 1, 1999
http://www.atl.lmco.com/rassp/taxon
http://rassp.scra.org
1. Modeling Taxonomy
2. Internal/External Concept
3. General Modeling Concepts
3.1 Primary Model Classes
3.1.1 Behavior
3.1.2 Function
3.1.3 Structure
3.2 Specialized Model Classes
3.2.1 Performance Model
3.2.2 Interface Model
3.2.3 Mixed-Level Model
3.2.4 Virtual Prototype
3.3 Distinguishing Structure/Behavior/Interface Models
4. System Models
4.1 Executable Specification
4.2 Mathematical-Equation Model
4.3 Algorithm Model
5. Architecture Models
5.1 Data Flow Graph (DFG)
5.2 Token-Based Performance Model
6. Hardware Models
6.1 Abstract Behavioral Model
6.2 Detailed-Behavioral Model
6.3 Instruction Set Architecture (ISA) Model
6.4 Register Transfer Level (RTL) Model
6.5 Logic-Level Model
6.6 Gate-Level Model
6.7 Switch Level Model
6.8 Circuit Level Model
6.9 Pure Structural Model
7. Software Hierarchy
7.1 Data Flow Graph (DFG) Task Primitive
7.2 Pseudo-code
7.3 High Level Language (HLL)
7.4 Assembly Code
7.5 Micro code
7.6 Object-Code
8. Supporting Terms
8.1 Abstraction Level and Hierarchy
8.2 Design Object Classes
8.2.1 System
8.2.2 Component, Module
8.2.3 Architecture
8.2.4 Hardware
8.2.5 Software
8.2.6 Firmware
8.3 Information Classes
8.3.1 Data
8.3.2 Control
8.4 Design Process Terms
8.5 Design Tools
8.6 Test Related Terms
8.7 Requirements and Specifications
8.8 Reusability and Interoperability
Appendix A: Background
Appendix B: Prior Taxonomies
Appendix C: Additional Attributes
Copying and distributing verbatim copies of this document is permitted provided that the working group author's credits and this notice appear intact on each copy. Modifying copies of this document is not allowed without consent of the RTWG. Portions of this document may be included in other documents provided proper accreditation to the original document and the RTWG is cited.
Carl Hein Todd Carpenter
Lockheed Martin Honeywell Technology Center
Advanced Technology Laboratories MPLS, MN 55418-1006
Camden, NJ 08102
chein@atl.lmco.com
Vijay Madisetti Allan Anderson
School of Electrical & Computer Eng. MIT Lincoln Laboratory
Georgia Institute of Technology Lexington, MA 01273-9108
Atlanta, GA 30332-0250
Arnold Bard J.P. Letellier
US Army CECOM Navel Research Laboratory
Fort Monmouth, NJ 07703 Washington, DC 20375-5336
Robert Klenke Capt. Greg Peterson
Dept. of Elect. Eng. Wright Labs
Charlottesville, VA 22903-2442 WPAFB, OH 45433-7319
Mark Pettigrew Perry Alexander
Sanders - A Lockheed Martin Company U.Cincinnati, Elect. & Comp Dept.
Hudson, N.H. 03051 Cincinnati, OH 45221-0030
Geoffrey Frank
RTI Center for Systems Eng.
Research Triangle Pk, NC 27709-2194
The following have been past contributors to the working group:
Anthony Gadient Randy Harr
SCRA Advanced Research Projects Agency
North Charleston, SC 29418 Electronic Systems Technology Office
Arlington, VA 22203-1714
Paul Kalutkiewicz
Lockheed Sanders
Advanced Engineering & Technology
Nashua, NH 03061-0868
Figure 1 - Taxonomy Axes
Another convenient method for specifying a particular model's information content is to use the textutal notation of (temporal, value, function, structure, program).
For example, a token-based performance model interprets instructions which represent major tasks or subroutines such as matrix invert, vector multiply, or Fourier transform. Though the primitives may represent hundreds of lines of source code, they are interpreted as a single instruction in terms of a time-delay by a network performance model. An Instruction-Set-Architecture (ISA) model interprets individual assembly instructions. In this sense, the ISA model is programmable at a much finer granularity, or higher resolution, than the network performance model.
At the lower extreme, a model of a microcode programmable processor is programmable at an even lower level of granularity than the ISA model because it allows control of individual-register and multiplexor structures within the device during execution of an assembly-level instruction. Software design components or non-programmable models are at the opposite extreme because neither interprets programmable instructions.
The RASSP Taxonomy specifies each of the first four axes from both an internal and external viewpoint. Consequently, the taxonomy effectively contains eight attributes:
Internal resolution references how a model describes the timing of events, functions, values, and structures of the elements that are contained within the boundaries of the modeled device.
External resolution describes how a model describes the interface of the modeled device to other devices. The external aspects refer to the input/output or I/O details at the boundary of the modeled device. The external details relate to how the model describes a device's interaction with devices to which it connects. External details may include timing and functional aspects, commonly refered to as protocol, as well as port structure and signal values. All of which may be abstracted to various levels in a model.
A convenient method for specifying a particular model's information content is to use the Internal / External (temporal, value, function, structure) notation. For example, the content of a particular RTL model could be specified as:
Internal(time=uS, value=boolean, function=full, structure=register), External(time=clock, value=boolean, function=full, structure=pin), SW-Program(assembly)For contrast, an example of a particular algorithm model could be specified as:
Internal(time=none, data=composite, function=full, structure=none), External(time=none, data=composite, function=none, structure=none), SW-Program(none)
The internal/external distinction is also known as the white-box/black-box distinction.
To better understand the internal/external concept,
consider viewing an integrated circuit chip (IC-chip) from outside its package
as shown in figure 3 below.
When viewed from outside, or externally, we can observe only the structure and behavior of the ports, (for example: how many pins there are, and what values they have when driven with various stimuli), but we cannot observe any details about how the IC-chip is implemented inside the package, or internally.
In contrast, we can think of seeing an internal view if we were to pop the
lid off the IC package as shown in figure 4 below.
Notice that now we can see some detail about how the IC-chip's insides, or internals, are implemented. This view contains internal implementation detail.
External structure is the structure of the externally viewable features, which
is the structure of the externally viewable ports, or interface.
Figure 5 below depicts an abstract model of the external ports (interface) of
the chip. The external implementation detail is resolved as two signals
which are of abstract type, integer. They are abstract because they do not
reveal the bit-level implementation detail.
Figure 5 - Abstract model of external features.
A less abstract model of the external interface of the component could show the
actual bit-level implementation detail of the signal ports as shown in figure 6 below.
This more detailed view shows the hand-shaking lines and the data port resolved as individual pins at the bit level.
Similarly, the internal details can be depicted at various levels of abstraction.
Virtual prototypes can be constructed at any level of abstraction and may include a mixture of levels. Several virtual prototypes of a system under design may exist as long as each fulfills the role of a prototype. To be useful in a larger system design, a virtual-prototype model should define the interfaces of the component or system under design.
In contrast to a physical prototype, which requires detailed hardware and software design, a virtual prototype can be configured more quickly and cost-effectively, can be more abstract, and can be invoked earlier in the design process. A distinction is that a virtual prototype, being a computer simulation, provides greater non-invasive observability of internal states than is normally practical from physical prototypes.
In contrast, figure 8 below depicts a behavioral model of the same component
as above. Notice that this model contains information about the internal
data values, functions, states, and timing aspects of the component, but no
information about how the internal structure is implemented. Therefore,
the internal view is said to be represented behaviorally.
In contrast to the above model, the figure 9 below depicts a model that
describes the internal structure of the component to some level of
detail. Remember that structure is inter-connection information.
Notice that this diagram shows a decomposition into internal blocks.
Because it shows how the blocks are connected to each other, at some
level of abstraction, it is called a structural model, or internal structure.
The internal blocks of a structural model can be described either behaviorally, or can themselves be further decomposed structurally, etc.. If behaviorally described blocks exist at the bottom (leaf-level) of a structural hierarchy, then the model can be simulated. Note that the behavior of such a composite model is provided by the underlying behavioral blocks: not by the structure. The structural descriptions merely provide means for combining separate behavioral pieces. A different behavior would be exhibited if the underlying behaviors were changed.
If behavioral blocks do not exist at the bottom (leaf-level) of a structural hierarchy, then the model is a purely structural model. No behavior can be inferred if the behaviors of the underlying blocks of a structural model are unknown.
The level of abstraction of the internal view depends on the level of implementation details. The structure could be described abstractly as the interconnection of high-level blocks, or concretely as the interconnection of logic gates. Independently, the timing and functional abstraction can be described for the high-level blocks abstractly as coarse events or concretely as specific times, or for the gate-level model abstractly as the stable per-clock boolean values, or all switching rise and falls resolved to pS (intra-clock events) and signal levels and strengths.
The primary purposes of an executable specification are:
y = sqrt( x ) or y = sin( x )
These functions represent well-defined mathematical relationships but do not indicate methods for
their computation, for which there are many, such as lookup table, Newton's method, or Taylor-series
expansion.
The primary purpose of a mathematical-equation model is to test that the mathematical equations and parameters developed to solve a design challenge do satisfy a system's numerical performance requirements.
The primary purpose of an algorithm model is to test how well an algorithm designed to implement a mathematical task satisfies the system numerical performance requirements. Algorithm models are also used for determining the numerical effects of finite precision and the parameters of floating or fixed formats.
The primary purposes of a data flow graph are to express algorithms in a form that allows convenient parallelization and to study and select optimal parallelization or execution strategies through various methods involving the aggregation, decomposition, mapping, and scheduling of tasks onto processor elements.
The primary purposes of a token-based performance model are to determine sufficiency of the following selections in meeting the system processing throughput and latency requirements: the number and type of processor elements, the size of memories and buffers, network topology (bus, ring, mesh, cube, tree, or custom configuration), network bandwidths and protocols, application partitioning, mapping, and scheduling of tasks onto processor elements, and flow control scheme.
The primary purposes of an abstract behavioral model are:
The primary purpose of a detailed behavioral model is to develop and comprehensively test the structure, timing, and function of component interfaces, especially of a board level design. Also to examine the detailed interactions between hardware and software (drivers), and to provide timing values that are used to replace initial estimates in the higher level models to increase their accuracy.
The primary purposes of ISA models are for efficient development of uni-processor resident software prior to hardware realization, optimization and design of application specific instruction sets and register architectures, documenting the functionality of processor's instruction set, and for measuring software routine runtimes, to increase the accuracy of the more abstract models.
The primary purpose of RTL models is for developing and testing the internal architecture and control logic within an IC component so that the design satisfies the required functionality and timing constraints of the IC. The RTL model is also used for specifying the design in a process neutral format that is retargettable to specific technologies or process lines through automatic synthesis. It is often used for the generating detailed test vectors, gathering timing measurements to increase the accuracy of more abstract models, investigating interactions with closely connected components, and it unambiguously documents the design solution.
The primary purpose of logic models is to develop logical expressions for reduction into logic gates, and to test that these expressions implement the required functionality, usually for a portion of an IC component. Also to support re-use of a detailed design by documenting the logic in a fairly process neutral format that can be retargettable to specific technologies or process lines through automatic synthesis.
The primary purpose of a gate level model is to document the particular implementation of an IC component in terms of the interconnection of elements from a specific logic family library, for fault- grading and the production of operational test-vectors, to determine the precise timing response of the circuit to stimuli to increase the accuracy of more abstract models, to test that the design meets all timing and functionality requirements, and to optimize the gate-level implementation of the logical design.
The primary purpose of a switch-level model is to efficiently determine the response of a portion of an IC, usually a gate or set of gates, to increase the accuracy of more abstract models. This determination is more efficient though coarser than circuit level models.
The primary purpose of a circuit model is to determine the response of a portion of an IC, usually a gate or set of gates, to optimize its design according to its requirements, and in particular to most accurately determine its minimum and maximum propagation, switching times and loading and driving capabilities in terms of transistor and conductor properties and configurations, to increase the accuracy of more abstract switch and gate-level models.
The abstraction levels form a hierarchy. A design at a given abstraction level is described in terms of a set of constituent items and their inter-relationships, which in turn can be decomposed into their constituent parts at a lower level of abstraction.
For example, the function:
c = a convolved with b
Is more abstract than:
c := idft( dft(a) * dft(b) );
which shows more information about how to compute (or implement) the function. The
function could have been implemented in other ways (such as c = 
), so the second
equation provides details that are not contained in first equation.
An even lower level of abstraction for the example would be an implementation of the equation in the form of a multiplier/accumulator with a finite state machine controller. This description provides more constraining information about the implementation, since the second equation could have been implemented and described in other ways, such as a software programmed computer.
A still lower abstraction level would be a logic-gate netlist for the finite state machine and/ or multiplier/accumulator. It would resolve more details about, for example, how to implement the adder function, and therefore it constrains the implementation further.
An even lower abstraction level would be the polygon layout for the logic, since more details would be resolved and constrained.
It should be evident that many intermediate levels of abstraction were skipped in the above example.
It should be noted that abstraction level does not indicate accuracy. Abstraction and accuracy should be distinguished in the same sense that precision is different from accuracy. For example, an abstract behavioral model of a deterministic processing element could describe the execution of a given function as consuming 100.288-uS, while a much less abstract RTL model would concur with exactly the time in terms of 10288 10-ns clock cycles. Thus, both can be equally accurate but differ in abstraction.
In RASSP, several hierarchies are important, namely: the functional or logical hierarchy and the structural or physical hierarchy. Often there is correspondence between these hierarchies, but not always.
The functional hierarchy decomposes a system according to functions. For instance: receiver, product detector, convolver, multiplier/accumulator, register/mux, logic gate.
A structural hierarchy often decomposes a system according to the physical structure, such as racks, frames, chassis, boards, modules, chips, cells, gates, transistors. Structure may also refer to logical relationships, such as data-structures.
The functional to structural mapping tends to shift with model year as integration levels increase.
Examples of systems are:
1). Carrier battle group defense system, composed of sub-systems:
a.) command, control, and communications systems,
b.) navigation systems such as GPS and inertial gyro,
c.) weapons systems,
d.) counter measures systems,
e.) sensor systems such as search-radar and sonar,
2). Weapons system, composed of sub-systems:
a.) tracking radar system,
b.) guidance system,
c.) telemetry system,
d.) propulsion system,
e.) fusing system.
3). Tracking radar system, composed of sub-systems:
a.) antenna system, and mechanical control system
b.) transmitter and receiver system,
c.) analog preprocessor,
d.) digital signal processing system
e.) data processing system (track interpretation & navigation fusion)
f.) operator control and display systems
4). Digital signal processing system, composed of sub-systems:
a.) I/O system,
b.) network communication system,
c.) local and distributed operating systems,
d.) runtime command processing and control systems,
e.) processor clusters, or multi-node board systems
f.) power supply system
5). Multi-node processor board system, composed of sub-systems:
a.) processor element subsystems,
b.) shared memory system,
c.) scan chain control system
6). Processing element system (CPU system) composed of sub-systems:
a.) local memory system
b.) local node operating system
c.) processor unit subsystem
d.) inter-PE communication system
e.) runtime node control system
Notice that the above examples follow a system hierarchy from 1c to 2, 2a to 3, 3d to 4, 4e to
5, 5a, and 5a to 6. Note that RASSP is concerned particularly with the type of systems below
3d; namely digital signal processing systems and all their subsystems.
To disambiguate the term system, it is recommended that the appropriate qualifier be stated before its use , such as "CPU memory system", "radar system", "DSP system", etc..
Most systems are a component of a larger system. The terms "system" and "component" can therefore be used to refer to the same item, but from different view-points: the former when speaking of the item and its constituent parts, and the later when speaking of the item as a constituent of a larger system.
Often the word component has been used to specifically designate an IC chip, as in a board component, which indicates a specific structural partitioning. However, since terms such as "IC- chip" adequately describe such devices, the RTWG prefers to not relegate the usage of the word component to that single structural level.
Similarly, the word module has often been used to designate a multi-chip substrate that is a board component such as the Multi-Chip Module (MCM). However, the word module has also been used to designate larger systems such as the Lunar Module and other non-hardware items such as software code modules. Therefore, in RASSP the synonyms component and module are used in a recursive/hierarchical terminology that may correspond to either the functional or structural implementation.
Every complex component is itself a system. The terms system and component (or module) can therefore be used to refer to the same item, but from different view-points: the former when speaking of the item and its constituent parts, and the later when speaking of the item as a constituent of the larger system.
Because decisions as to what to include in a model often pertain to portions of the design defined as control or data, an orthogonal classification must be made to distinguish between control versus data. The challenge in making this classification is that data is control to some and control is data to others; it is "view" specific. For example, all the "signals" used to control a protocol to transfer data over a bus may be viewed as control by a bus designer. But another designer may view any clocked input as data for a synchronous design.
An example of a top-down design process would be one that consists of the following steps:
Top-down design has in the past been interpreted by some designers literally as the time order of abstraction focus, such that the abstract design would be completed prior to the detailed design in sequence. The RTWG recommends avoiding that interpretation because it does not apply to realistic design situations in which top-levels could specify unattainable requirements for the lower sub- modules. The RTWG instead prefers the interpretation where multiple levels of the design process are active concurrently, but the flow of requirements is from top to bottom, with feedback on how well the requirements can be met flowing from bottom to top.
The purpose of a prototype is for testing, exploration, demonstration, validation, and as a design aid. It is used for testing design concepts and exploring design alternatives. Prototypes are also used to demonstrate design solutions or validate design features.
Examples of physical prototypes are: bread-boards, mock-ups, and brass-boards. Physical prototypes are characterized by fabrication times that typically require weeks-to-months and that typically require days-or-weeks modify. Construction usually involves detailed design, lay out, board or integrated-circuit fabrication, ordering, and mounting via solder or wire-wrap. Additionally, programmable systems or parts require detailed target-software design of drivers and operating system, or programming PLAs, FPGAs, PROMS.
The RTWG attempted to use the refined nomenclature to define how the various types of models are implemented in VHDL and how interoperability between models of the same and differing types is obtained, as well as to identify what design risks and benefits they address.
Feedback and comments are encouraged to maintain a comprehensive taxonomy that supports electronic industry needs. Please direct comments to the RTWG in care of Carl Hein, at chein@atl.lmco.com, or by phone at 609-338-3924.
Differing terminology created confusion among the RASSP organizations. Some organizations used common modeling terms with divergent meanings, while others used different words to describe the same type of models. Clearly communicating ideas about modeling techniques and model types among organizations was essential in achieving the goals of RASSP. Without a common language, the RASSP community could effectively communicate, and the simulation model compatibility would be hindered.
The Terminology Working Group (RTWG) was formed at the January 10, 1995 RASSP Principal Investigators meeting in Atlanta, GA., to address the modeling and terminology challenge. The core working group consists of members representing the two prime contractors, a technology base developer, the educator facilitator, and the government.
The RTWG's mission was to develop a systematic basis for defining VHDL model types and to use this basis for concisely and unambiguously defining a terminology that describes the models that are used within a RASSP design process. One crucial requirement for the basic taxonomy is that it must be useful for selecting, using, and building appropriate interoperable models for specific roles in a design process. Models are used for several purposes, which include specifying or documenting design solutions and for testing and simulating proposed designs. The terminology is based on the commonly documented and applied vocabulary in the digital electronic design and modeling industry, and it draws heavily from related previous and ongoing efforts by the EIA [1], ESA [2], Army [3], Navy [4], and from the annals of related literature from Design Automation Conference (DAC), VHDL International User's Forum [5], and text books[6].
Previous efforts focused on narrower domains than RASSP. RASSP spans many domains, including: parallel processing; multi-board and multi-chassis systems; software; digital signal processing; digitical circuit design, and application functions, with strong interaction with other domains such as analog, mechanical, physical, and RF [7].
Though the RASSP program focused primarily on digital signal processor (DSP) systems design, much of the results are applicable to the design of any complex digital system, such as control systems or multiprocessor systems.
For a given domain, there are many possible vocabularies. The coverage and overlap depend on the domain to which it applies. The pre-existing vocabularies were the result of many disconnected vocabulary generation processes. They contained many ambiguities.
In Figure A1, the working group's initial modeling terms were categorized according to major area, such as: abstraction levels, system levels, hardware levels, software levels, structural hierarchy levels, and general modeling-type terms.
Vocabulary words represent concepts and allow us to share and communicate ideas. Unambiguous communication requires not only that we have a common mapping of words to concepts, but that we have the right set of words to accurately describe the concepts we are dealing with. Developing, agreeing to, and using a concise common terminology are therefore vital to advancing the state of the art in design methods.
In defining the vocabulary terms, attempts were made to defer to the general English meaning of words as defined by the Webster's New Collegiate Dictionary so that outsiders and new-comers may be more likely to rapidly understand and adopt the terminology.
Some terms may have multiple meanings (due to historic overloading) which can be differentiated by context. We try to recognize and define each of them.
To avoid the problem of vague or circular definitions, a heavy emphasis was placed on providing examples to accompany the definitions. These examples should provide a level of understanding and concreteness to any discussions regarding the terms. The examples also tend to associate the terms to their intended uses and domains. To reduce the tendency of examples to limit or over-constrain the definitions, a range of typical and extreme cases are given and identified wherever possible.
To further avoid ambiguous definitions, attempts were made to eliminate definitions based purely on relative terms, such as "high", or "abstract", since their interpretation would be subject to one's point- of-view or experience. Instead, definitions should be based on absolute, concise, and testable statements, with special emphasis on differentiating related terms (i.e. hardware, software, firmware).
Reaching the consensus on terminology required compromise from everyone. The RTWG made a conscious attempt to borrow evenly from many sources.
The development of the more efficient vocabulary, where a minimal set of words were assigned to span the appropriate concepts, was an orthogonalization process. The process developed a set of terms that represent all of the concepts to be distinguished. Separate words were selected for distinct concepts. Words for classes of concepts were selected to represent useful generalizations.
The RTWG modified and augmented the previously defined terminology sets, broadened parochial definitions, distinguished overlapping definitions, equated close synonyms, removed non-applicable terms, added needed or missing terms, clarified poorly defined or misunderstood terms, and suggested new terms as replacements or synonyms to outdated terms. When appropriate existing definitions were not available for significant terms used within the RASSP community, the RTWG attempted to create them.
The refined nomenclature identifies the models developed within the RASSP process that document design information, their purpose in the design process, and the practices for developing interoperable versions of those models. The RASSP program developed broad consensus for a modeling vocabulary that is readily adopted by engineers and students. The vocabulary promotes the requirements of rapid design processes for interoperable models.
The Ecker and Madisetti spaces share two axes, while their remaining axes do not directly correspond. Both have an axis for Time resolution and a second axis representing the resolution of data Values in a model.
Ecker calls the second axis Value, while Madisetti calls it Format. The Y-chart's Functional- Representation axis expresses some information that is similar to the value-format axes. However, the Y- chart's Functional-Representation axis does not exactly correspond to the value-format axes because it contains information about functionality as well.
The third axis of the Ecker cube is similar to the Structural-Representation axis of the Y-chart but has no corresponding axis in the Madisetti case. (The latter situation arises intentionally.)
None of the remaining axes of the taxonomies directly correspond. The Y-chart seems limited to only the logic level. None of the taxonomies appear to directly address the hardware/software codesign aspect.
Other potentional attributes included model maturity or validation level, simulation efficiency portability, complexity/ size/lines-of-code, maintainability, flexibility, modifiability, expandability, and licensing cost.
Although the additional attributes appear to be useful in selecting, building, or using models for appropriate purposes within the design process, some are less easily quantified than others. For instance, simulation efficiency could be specified in events, cycles, or instructions per simulation-host CPU cycle, with memory requirements for the model's program code and data. Comparably objective units for portability or maintainability are less obvious.
A balance must be struck between the taxonomy's expresiveness and its ability to be comprehended widely. Additional attributes should be considered in future efforts, but were beyond the scope of the current version.
[2] Preliminary VHDL Modeling Guidelines, European Space Agency / ESTEC
[3] Army Handbook - The Documentation of Digital Electronic Systems With VHDL
[4] TIREP (Technology Independent Representation of Electronics Products) NSWC
[5] Madisetti, V., " System-Level Synthesis and Simulation VHDL: A Taxonomy and Proposal Towards Standardization", VIUF Spring, 1995 Proceedings.
[6] "Modeling and Simulation", Texas Instruments Semiconductor Group, 1990.
[7] Armstrong, J., "High Level Generation of VHDL Testbenches", Spring 1995 VIUF Proceedings.
[8] Ecker, W., Hofmeister, M., "The Design Cube - A Model for VHDL Designflow Representation", Proceedings of the EURO-VHDL, 1992, pp. 752-757.
[9] Famorzadeh, S., et.al., "Rapid Prototyping of Digital Systems with COTS/ASIC Components", Proceedings of RASSP Annual Conference, August, 1994.
[10] Blahut, R., Fast Algorithms for Digital Signal Processing, Addison Wesley, New York, 1985.
(Questions, Comments, & Suggestions: chein@atl.lmco.com)