Abstract Architecture Representation Using VSPEC

Complex digital systems are often decomposed into architectures very early in the design process. Unfortunately, traditional simulation based languages such as VnDL do not allow the impact of these architectural decisions to be evaluated until a complete, simulatable design of the system is available. After a complete design is available, architectural errors are time-consuming and expensive to correct. However, there is an alternative to simulation based techniques: formal analysis of abstract architectures at the requirements level. This paper describes vs,Ec’s approach for defining and analyzing abstract architectures. VSl, EC is a Larch interface language for VHDL that allows a designer to specify the requirements of a vHI entity using the canonical Larch approach, vi-i)i structural architectures that instantiate vs,c entities define abstract architectures. These abstract architectures can be evaluated at the requirements level to determine the impact of architectural decisions. This paper briefly introduces vs,c, provides a formal definition of vs,c abstract architectures and presents two examples that illustrate the architectural definition capabilities of the language.


INTRODUCTION
Architectural design decisions made early in a system's design profoundly affect overall design quality.Unfortunately, architecture decisions are rarely evaluated until late in the design process.Simulation-based design languages such as vHIi [5,12] do not allow evaluation until complete models exist.For large systems, simulatable models appear late in the design process, driving up the cost of error correction.These models include not only architectural decisions, but also component design decisions.The ability to analyze architectural decisions as they are made would significantly reduce this cost.
A solution to late architecture evaluation is the formal analysis of abstract architectures at the requirements level.An abstract architecture is an interconnected collection of components where the requirements of each component are specified *Corresponding author, e-mail: {pbaraona, alex}@ececs.uc.edu without defining their implementation.Thus, an abstract architecture describes a class of solutions with a common structure rather than a single instance from that class.Formally described abstract architectures can be evaluated early in the design process when architecture decisions are made before component designs exist.vspEc [7], a Larch interface language [10] for vnoL [12], is a requirements specification language that includes formal architecture definition support.vsPEc describes the requirements of digital system components using the canonical Larch approach.Each vnoL entity is annotated with a pre-and post-condition to specify the entity's functional requirements, vs,c-annotated entities can be connected together using a vni structural architecture to form abstract architectures.The vHo architecture indicates interconnection in the traditional manner, but the vspc specification defines the requirements of each component instead of a specific design.
The description of a sorting component illus- trates the difference between vnI and vs,Ec.In vH, the simplest way to describe the function of a sorting component is a behavioral architecture that implements a quicksort, bubble sort or some other sorting algorithm.This is actually a descrip- tion of how the sorting component behaves.In contrast, a vspEc specification of this component explicitly describes what the device must do without defining how it is done.A vspc descrip- tion of a sorting component is shown in Figure 1.
It states the output has all the same elements as the input (permutation(output'post, input)) and the output is in order (ordered(output'post)).Any sorting algorithm may be used to implement these requirements, but vspc allows this algorithm to be chosen later in the design process.
Larch interface languages have been developed for a variety of programming languages including C [9], C + + [15] and Modula-3 [14].At the single component level, vspc differs very little from other interface languages.However, defining a Larch interface language for vnI presents a problem not found in these other languages.In traditional programming languages, a language construct executes after the construct immediately preceding it terminates.In vH, there is no implicit execution order among process level constructs and thus no means of determining when a component's pre-condition should hold.
VSl,EC addresses this problem by allowing a user to define an activation condition in addition to the pre-and post-condition for an entity.When an entity's state satisfies its activation condition, its pre-condition must hold and the entity must perform its specified transformation.This paper describes VS'EC, concentrating on the language's facilities for describing abstract archi- tectures.The next section provides a brief sum- mary of the VSPEC language.After this, we describe VSpEC abstract architectures, including a definition of the VSpEC state model and a description of how a process algebra (CSP [11]) is used to provide a semantics for the VS'EC activation condition.Next, two example VSpEC specifications are presented that illustrate the abstract architecture representation capabilities of the language.Finally, the paper concludes with a discussion of related work and a brief summary.

VSPEC
VSPEC is used to describe what a digital system should do.It adds a requirements definition capability to VHL entities analogous to the requirements definition capability that Larch interface languages add to traditional procedure and function signatures.As shown in Figure 2, the requirements of a vHoi entity can be defined by describing a relationship from the current inputs and state of the system to the outputs and the next state.This section describes how F(x, s) and s are defined in VSPEC and contrasts these definitions with VHOL definitions of F(x, s) and s.
As shown in the find entity of Figure 3, a VHOI entity defines an interface.The output of find should be the element from the input array with the same key as the key input.A vHe entity does not describe functional information such as this.The entity only defines the component's interface.
The vI4I architecture construct describes the function of a component by associating behavior and/or structure with an entity.Figure 4 is a behavioral vHoe description of the find compo- nent's function.In terms of the state model in Figure 2, this architecture describes F(x,s) as a linear search algorithm.This looks very similar to a C or Pascal function describing how the system behaves.Unfortunately, this operational descrip- tion biases the system towards a particular implementation.Since VSpEC'S purpose is requirements specification, it is undesirable to bias the system to a particular implementation this early in the design process.VSPEC eliminates this problem by allowing a user to declaratively specify the requirements of a digital system.Seven clauses annotate the entity construct to allow the specification of what a component should do instead of vH's descrip- tion of how the component performs this function.The requires, ensures and sensitive to clauses are used to specify the device's functional requirements.Non-functional constraints are described in the constrained by and modifies clauses.The component's internal state is declared in the state clause and the includes clause is used to make types and operators from a Larch shared language description visible in a VSPEC component.The remainder of.this section briefly summarizes these clauses.For a more complete description of the VSPEC clauses, see one of the other VSPEC references [1,7].
Component function is described in the requires and ensures clauses.The requires clause defines a pre-condition over inputs and state variables while the ensures clause defines a post-condition over inputs, outputs clause defines legal outputs and the next state when the requires clause is satisfied.A compo- nent's user is responsible for making certain the requires clause is satisfied whenever the component is in use.When the requires clause is satisfied, the described entity is responsible for making the ensures clause true.
Let cr be the state of a VSpEC entity as defined by its ports and state variables.If I(cr) is the requires predicate and O(cr, cr ) is the ensures predicate, then the vsPEc annotation defines the following requirements: F(cr) is an implementation of these requirements if the following condition holds: V7.I (cr)==:>O(r, F A VSPEC description of a find component is shown in Figure 5. Notice that the requires clause predicate is true, meaning this entity will function correctly for any set of inputs of the proper type. The ensures clause predicate states that the output element has the same key as the key input and output is in the input sequence.In terms of the state model in Figure 2, the ensures clause predicate defines the requirements of F(x,s), but unlike the VHDL description, it does not describe how to implement the component.
The VSPEC sensitive to clause is used to define when a component in an abstract architecture is active.When the sensitive to clatise predicate is true, a component's pre-condition must hold and an implementation must satisfy the post-condition.
Performance constraints are described in the constrained by and modifies clauses.Constraints define requirements, such as clock speed or layout area, that are not part of the functional description.The constrained by clause defines relations over constraint variables.Currently, the defined constraint variables include power consumption, clock speed, area, pin-to-pin timing, and heat dissipation.Constraint theories written in the Larch Shared Language (LSL) [10]  element constraints and theories if desired.The modifies clause lists variables, ports and signals whose values may be changed by an architecture that implements the vseFc entity.This clause is useful when specifying whether an entity modifies a shared variable.The list of objects an entity modifies is not a traditional performance con- straint, but this list does restrict the set of potential solutions.Examples of the constrained by and modifies clauses are shown in Figure 5.
The state of a vseEc entity is described by the port definition and variables in the state clause.In VnDL, ports maintain their values between entity invocations so ports are part of a vsPEc entity's state.The state clause is used to define internal state variables that are used only in the vsPc definition.These variables maintain state informa- tion that is not recorded in port values.When a vsPc specification is refined into a VHDL archi- tecture, these internal state variables will be refined into signals or variables that represent the same information.The state clause variable declaration represents this information during the require- ments specification phase of the entity's design.An example of the state clause can be found in the Move Machine example.
The includes clause is the final vsPc clause. 2  This clause is used to include LSL definitions in a vsPc description or VHDL package declaration.
(See the Move Machine example.) 3 LSL is used to define the types and functions used in a vsPEc specification.An example of the includes clause is shown in Figure 5; its syntax is the keyword includes followed by a list of trait references.The syntax of a trait reference is similar to a trait reference in LSL.It consists of the trait name followed by an optional parameter list.The parameter list is used to rename LSL names to a name visible in the vsPc entity.Thus, an integer stack is included in a vsPc specification with this includes clause: includes Stack(integer, int_stack).

ARCHITECTURES
The previous section briefly described how VHDL and vsPc are used to define the requirements of a single device in a digital system.The behavior of a device can also be described by decomposing it into smaller pieces and connecting these pieces together to form an architectural description of the device.This architectural description represents a refinement of the device's behavioral VHDL/VSPC description.VrtDL provides convenient facilities for defining architectural descriptions.This section briefly discusses these facilities and then describes how VSPFC uses them to form an abstract architecture.

VHDL Structural Architectures
VHDL uses structural architectures to represent component composition.A structural architecture describes how sub-components are connected together to form a larger component.Figure 6 shows a structural architecture for find.Unlike the behavioral representation in Figure 4, this archi- tecture indicates that a sort component connected to a search component implements the find function.This structural architecture should per- form the same function as that specified in the behavioral description.
The VHDL component construct defines each component used in a structural architecture.The structure architecture of find in Figure 6 declares two types of components that are used in this architecture: sorter and searcher.One instance of each of these components (named bl and b2) is created in the body of this architecture.The port maps of these component instances are used to indicate how the components are connected together.In the structure architecture for find, the system's input array is connected to the sorter input and the sorter output is connected to internal Previous versions of vsec [1, 2, 7] also contained a based on clause.The modified syntax of the includes clause described here made the based on clause obsolete.
Allowing includes clauses in package declarations is a change from previous versions of vsec [1,2,7].architecture signal y.The signal y and system input key are inputs to the searcher component.The output of the searcher is connected to the device output.
The vHox configuration construct is used to bind entity-architecture pairs to component instances.
In this example, the test_struet configuration binds the bubble sort defined by entity sort with architecture behavior to the bl instance of the sorter component.Similarly, the binary search defined by entity bin_search with architecture behavior is bound to the b2 instance of searcher.If there were other architectures for these two entities (such as a structural architecture), a different configuration could have been specified stating that the components in structure mapped to these architectures.Entirely different entities could even have been defined.
Since a structural architecture only defines dataflow between components, an additional mechanism must be provided to define when a component activates.VHDL accomplishes this with sensitivity lists and wait statements.A sensitivity list is a list of signals.Whenever an event occurs on one of these signals, the process resumes execution.The behavior architecture for sort is sensitive to its single input, while bin_search is sensitive to its input array and key value.This means the sort component sorts its input only when new input arrives.Likewise, a search occurs only when the key value or input array changes.A wait statement achieves the same result by waiting on signal events, conditions or for a specific time interval.In this example, wait statements could replace sensi- tivity lists by removing the sensitivity lists and placing wait statements referencing the same signals at the end of the process definitions.

VSPEC Abstract Architectures
vimi structural architectures containing vsPEc- annotated components specify abstract architec- tures.The VHDI architecture remains unchanged, indicating component instantiation and connec- tions.However, a vHo architecture is not assigned to each component instance in the architecture.Instead, the configuration defines that each com- ponent references an entity with an architecture called vsPEc.This architecture signifies that at the current point in the design, the requirements of this component are known (via the vspEc description) but no implementation has been defined. 4 The structure architecture of find, shown in Figure 6, becomes an abstract architecture by refe- rencing vspc definitions of the instantiated com- ponents.Figure 7 shows vsec entity definitions end for; end for; end test_struct; FIGURE 7 vseEc definitions for the sort and bin_search components in the find architecture.This is different than leaving the entity open.When a VHDL entity is left open, the design is being deferred.At the current point in the design, nothing is known about the function of the entity.In contrast, the requirements of a vsPEc entity are known, even though an implementation is not.
for the sort and bin_search components in Figure 6.A new configuration, test_vspec, has been defined for the find entity.It specifies that the VSeEC descriptions of sort and bin_search should be used instead of a specific architecture for these two entities.This configuration describes an abstract architecture for the find component.Any imple- mentation satisfying the VSPEC requirements of sort and bin_search may be associated with the entity definitions.The architectures specified in Figure 6 represent one such solution, but there are many others.
The VSPEC description of sort specifies the requirements for a sorting component: the input and output must have all the same elements (i.e., the output is a permutation of the input) and the output must be in order.In a similar fashion, the bin_search specification states that whenever the component input is sorted, the component must ensure that the output element contains the same key as the key input and this element is an element of the input array.The requires and ensures clauses of these entities use two predicates (permutation and ordered) to define these requirements.These pre- dicates are defined in the LSL trait SortPredicates, which is included in both vspEc entities.
Although a VnDL architecture referencing VSPEC definitions defines components and interconnec- tions, additional information must be added to specify when the VSPEC components activate.In traditional sequential programming, a language construct executes following termination of the construct preceding it.For correct execution, a construct's pre-condition must be satisfied when the preceding construct terminates.In hardware systems, components exist simultaneously and behave as independent processes.No predefined execution order exists, thus there is no means for determining when a component's pre-condition should hold.Consider the find example.The precondition of bin_search need hold only when sort has completed its transformation.At all other times, bin_search need only maintain its state.VHDL provides sensitivity lists and wait state- ments to synchronize entity execution, vsPEc achieves the same end using the sensitive to clause.The sensitive to clause contains a predicate called the activation condition that indicates when an entity should begin executing.Effectively, the activation condition defines when a VS'EC anno- tated entity's pre-condition must hold.When the sensitive to predicate is true, the pre-condition must hold and the implementation must satisfy the post-condition.When the sensitive to predicate is false, the entity makes no contribution to the next state of the system.Like the requires and ensures clauses, the sensitive to predicate is defined over entity port definitions and variables defined in the state clause.
Recall that the structural VHOL architecture for find (Fig. 6) specified that the sort component should only activate when its input changes and the binary search component activates when one of its inputs changes.Specifying this behavior in VSPEC would not be possible without the sensitive to clause.Note the sensitive to clauses defined in the VSPEC description of find in Figure 7.In VSPEC, a signal's' event attribute is true if and only if the signal changed value from the previous state.Thus, both components activate whenever any of their inputs change value.

Architecture Model Semantics
The previous section provided an informal de- scription of how VSPEC can be used to define an abstract architecture.This section provides a more precise, formal definition of the concepts presented above.First, the state of a VSPEC description is defined.After this definition, a precise definition of how the sensitive to, requires and ensures clauses define a transformation over this state is presented.
The section concludes with a simple example that illustrates these points.

State Definition
The state definition for an entity is a map from port, signal and variable names fo their values.
There are three different views of an entity state: (1) abstract; (2) component; and (3) concrete state.
The abstract state is defined by a VSpEC description of an entity.The component state is the state of a single component in an abstract architecture, and the concrete state represents the state of all components of an abstract architecture.
The abstract state includes the ports and state variables of an entity.The vsPEc sensitive to, requires and ensures clause predicates are defined over elements of the abstract state of the entity.The component state applies to an entity included as a component in a structural architecture.The component state is formed by taking the entity's abstract state and subjecting it to the renaming imposed by the signals the component is connected to in the architecture.This component state is used to construct the concrete state of the structural architecture.The concrete state is the union of the component states for all of the components in an architecture.This structural architecture represents a refinement of the vspEc definition of the entity.There is an abstraction function mapping the concrete state of the structural architecture to the abstract state defined by the vseEc description of the entity the structural architecture refines.
Consider the vseEc entity in Figure 8.The abstract state of the three entities in this figure are the inputs, outputs and state variables of the entities.Thus, the abstract states of these entities where i0, il,..., i9 are all integers.As shown, the state is a map from names to values.However, for the purpose of clarity we will show just the names that form the various states throughout the rest of this paper.
Within the struct architecture for the system entity, A's component state (the first instance of eompl) is found by taking eompl's abstract state and performing the renaming defined by the signals the component is connected to.In this case, inl is connected to sys_in and result is connected to signal x.Thus, in the context of the struet architecture, inl of component instance A should be replaced by sys_.in and result replaced by x.A similar renaming can easily be found for the inputs and outputs of the other components in the struet architecture.The renaming for the other components is shown in the definition A and B's component states below.
Since the struet architecture has more than one instance of the eompl entity, the state variables of eompl must be renamed to form the component state.This renaming avoids conflicts when forming the concrete state of the struet architecture.To simplify matters, we will always rename a compo- nent's state variables even if there is only one instance of an entity in the architecture.A number of renaming functions could be chosen, but the one used here is the state variable name in the abstract state subscripted with the instance label from the architecture.The component states of the components in the struet architecture are: We are now ready to form the concrete state of the struet architecture for the system entity.The concrete state is simply the union of the compo- nent states for each component in the architecture: Since an abstract architecture represents a refinement of the requirements specified by vspc, an abstraction function can be defined to map the concrete state of the architecture to the abstract state defined by the vspc description.
Together, the abstract, component and concrete states represent the state of a vsPc component.The examples in this paper use these definitions to describe how a vsPc description behaves.

Transform Definition
The transform performed by a vs,c architecture is defined by the sensitive to, requires and ensures clauses.The formal definition of the requires and ensures clauses was discussed in the section titled "vspvc".This definition is very similar to the transform defined by a traditional Larch interface language.As described in the section titled "vspc Abstract Architectures", the sensitive to clause is used to synchronize components and define when the requires clause predicate must be satisfied.
Formally, synchronization is easily represented using a traditional process algebra such as csP [11].Events are defined as changes in the state of the entity.Assume that F(St) is a function between two states of entity P that implements the requirements specified in P's requires and ensures clauses (i.e., F(St) satisfies Eq. ( 2)).The process defined by entity P with a sensitive to predicate of S(St) in any state St is: process that represents architecture 7 2 is: P PollP, ll IIP (4) Thus, each component in the architecture executes in parallel.Since a component activates only when its sensitive to clause predicate is true, this predicate is used to synchronize component execution.
where SEN is the set of states that satisfy P's sensitive to clause: SEN {t[S(t)}.Thus, a process in state St first waits for its sensitive to clause to be satisfied and then behaves like the same process in the state defined by applying F to the current state.Equation 3 defines a csP process that describes the behavior of a single VSPEC entity, cse's concurrency operator (1]) is used to define a process that describes the behavior of an archi- tecture of VSPEC components.Let P0, P,.P be the processes represented by Eq. (3) for the set of VSPEC component instances in architecture 72.The transformation performed by an architec- ture is defined from the components comprising it.Formally, the component requirements for el and e2 are defined as: Vx: integer, z: integer.11 (x) O1 (x, z'post) Vx: integer, z: integer.I2(x) 02(x, z'post) The renaming defined by the architecture that is used to create the component state from the abstract state of an architecture can also be applied to these two equations.In this example, this renaming defines the following logical requirements for bl and b2: Vi: integer, y: integer, h(i) = 01(i,y'post) Vy: integer, o: integer.I2(y) = O2(y,o'post) The renaming function is also applied to the modifies, state and sensitive to clause of el and e2.After this renaming, the logical definitions of each component are expressed in the same name space as the concrete state of the system.
Assume that a, b and c are integer constants and that f(x) and g(x) are functions that satisfy requirements for el and e2 respectively.Let the initial concrete state of the system be ,S'0 {i a, y b, o H c} and let/'event be true and y'event be false.This means that el's sensitive to clause is satisfied and el's pre-condition must hold.el will then make its post-condition hold in the next state.Instantiating the requirements for el gives: z: integer.I1 (a) = O1 (a, z) (5) Knowing that f(x) satisfies el's requirements and assuming I1 (a) is true implies that O1 (a,f(a)) is also true.Additionally, y'event is known to be false so e2 maintains its state and o does not change in the next state.Thus, one potential next state for this system is $1 {iHa, yf(a), o -, c}.Because the function f is one of potentially many functions satisfying el, we cannot claim that this is the only possible next state.
Since y changed values from $0 to $1, the predicate y'event is true in $1. Additionally, did not change values in $1 implying that /'event is false in ,5'1.Thus, only component e2 activates in state $1.
Using the same reasoning used for $1, values for $2 can be produced.Assuming that f(a) satisfies I2(f(a)) and knowing g(x) satisfies e2's require- ments makes O2(f(a), g(f(a))) true.The input value has not changed, el maintains its state implying y does not change, and g(f(a)) satisfies e2's output condition.Thus, $2 {i a, y f (a), og(f(a))} is a potential next state for the system.

An interesting exercise is defining what happens
when the input value changes between states S0 and S1.Assume that changes value from a to d making $1 {i -+ d, y f(a), o c}.Now i'event is true in -1 and both components execute on values from $1.In this case, $2 {id,yf(b), og (f(a))}.Note the value of o does not change from the previous example because the next state is defined only on variables defined in the current state.Using this model eliminates difficulty caused by instantaneous feedback and "pipelined" update functions.VHDI solves this same problem by allowing an infinite number of delta delays between changes in the modeled simulation time.

Generating Proof Obligations
The vspEc formal model can be used to verify that a system's abstract architecture description satis- fies the requirements described by the vspEc specification of the system.This verification provides evidence that the abstract architecture description satisfies the abstract vspuc specification.Finding such evidence depends on: (1) having the system requirements I and O; and (2) relating a concrete state produced by the abstract architec- ture with the abstract state specified for the system.
A system's vs,uc description provides I and O.
The abstraction function from the concrete to the abstract state provides the means for comparing the abstract and concrete states.
Weak bisimulation [19] is used as the correctness criteria when attempting to verify that an abstract architecture satisfies a VSPEC description.As shown in Figure 10, weak bisimulation requires that some sequence of state changes in the concrete state of the system result in the correct single state change in the abstract state.Only the first and last of the concrete states are significant.The system may pass through any concrete state as long as the abstraction function applied to the final concrete state results in the correct abstract state as defined by the abstract specification.
In csP, the sequence of states a VSPEC entity passes through is called a trace.A csP trace of process P is a finite sequence of symbols represent- ing the events processed by P. vspEc events are changes in state and they are represented in a trace by the state the entity changes to.Thus, a vsPEc entity satisfies the weak bisimulation criteria if two conditions hold for all traces of the abstract architecture.The first condition is that the abstraction function applied to the initial element of each trace must result in an abstract state that satisfies the abstract pre-condition.The second condition is that the final element of each trace must either have an abstract projection that satisfies the abstract post-condition or there must be some legal sequence of states that can be appended to the trace to form another trace.This ensures that the concrete state eventually reaches a state where the abstract specification is satisfied.
Weak bisimulation is a useful criteria for evaluating an abstract architecture decomposition of many systems.However, weak bisimulation may not be suitable for all systems.Some systems may require more than just the first and last states of the abstract and concrete traces to be equiva- lent.Defining other correctness criteria for vsPEc abstract architectures is currently an open area of research.

EXAMPLES
This section presents two examples that illustrate how vsPEc can be used to describe an abstract architecture.The first example is a simple tri-state buffer description that is used to define a simple two input multiplexor.This example illustrates what happens when multiple sources drive a single value in a VSPEC abstract architecture.The second example is the description of a simple CPU called the Move Machine.This example illustrates shows a VSPEC description that is decomposed into an abstract architecture.

Buffer and Multiplexor Example
A VSPEC description of a simple buffer is shown in Figure 11.In this example, input and output are both integers, but the specification could also be used if input and output were of any other type.When control is true, this device passes input to output.When control is false, the device places no requirements on the value of output in the next state.The specification allows for output to maintain its current value in the next state, but the specification also allows an external device to  change the value of output.Consider using this buffer as a component in the abstract architecture description of the multiplexor in Figure 12.
This figure shows both a vspEc description of a multiplexor as well as a refinement of this description into an abstract architecture.The vspEc entity mux is a straightforward description of a multiplexor.The struet architecture uses two instances of buffer and a not gate to decompose the multiplexor into an abstract architecture.
Careful examination of this description reveals a very subtle but important point about vspc specifications and multiply driven signals.If a component description does not restrict the value of an output signal in the next state, other components in the system can still change the value of this signal without violating the compo- nent description.Suppose that the concrete state of the architecture is: CONCRETEstructmux {inl 7, in2 3, select true, output 7, select_inv false} so that the abstract state of buffer instance bl is: ABSTRACTb {input -7, control -+ true, output 7} Assume that some external device changes the select input to false.This causes buffer instance bl's control input to change to false which activates the buffer.This device must now make its ensures clause true in the next state.Since control is false, the ensures clause will be true in the next state for any value of output.Thus, buffer instance b2 can change the output signal of the architecture to 3 without violating bl's specification.The next state of the device is: Thus, the output signal has changed values even though the bl buffer instance does not cause it to do so.Even though bl does not force a change in state, it does not prohibit one either.An external entity mux is port (inl, in2: in integer; device (buffer instance b2) has caused the output signal to change values.The specification of bl allows this change to occur.This description may not seem correct to an experienced VHDL user because the output signal is driven by two sources, but no resolution function is specified.Although this is illegal in VHDL, it is allowed in VSPEC.In most cases, the csP statement that defines a vspE entity's contribution to the next state of the system will define a single value for every signal, but a vsPc description may allow more than one value for a specific signal.This is legal vsec because vsPc is a specification language, not a simulation language like VHDL.This implies that a vsPc specification does not need to deterministically define a single value for every signal in the system.It is certainly possible to do this with vspEc by defining the requirements of resolution functions, but a vspc specification could allow a signal to be driven to two (or more) different values.In these cases, a designer implementing the specification may chose to drive the signal to any of its allowed values.The Move Machine A more complex example is the specification of a Move Machine [22].The Move Machine is a simple CPU that moves data from one memory location to another.It uses four instructions: jump, load register from memory, store register to memory, and halt, and four addressing modes: absolute, immediate, indirect and relative.Although the Move Machine is a simple device, its structure reflects how a more complex system might be represented.
The first step in specifying the Move Machine is representing it as a simple instruction interpreter (Fig. 13).At this level, only one vspc annotated entity describes the execution of each instruction and addressing mode.This entity contains state variables to store the current register contents and the value of the instruction pointer.The sensitive to clause states that the machine activates when its start or reset input is on or when the value of the instruction pointer changes.The rather complex ensures clause predicate defines how the machine behaves for each instruction and addressing mode.
An external entity would use this component by first applying the reset signal and then the start signal.This causes the machine to begin executing the instruction in memory location 0. The result of each instruction (except halt) cause the contents of the instruction pointer to change which activates the machine again in the next state.This continues until a halt instruction is processed, causing the machine to stop.One thing to note about this specification is the use clause on the first line.In VHDL, types and functions can be declared in separate packages.These packages are then included in entity and architecture descriptions with the use clause.The mm_types package referenced in this example is shown in Figure 14.An interesting aspect of this package is the use of incomplete types to specify address and word.VHDL uses incomplete types to allow references to a type before the type is completely defined (such as in an access type).One use of this is to allow a record to contain a pointer to another record of the same type (i.e., to construct a list).
In VSPEC, incomplete types are used for a slightly different purpose.The type definitions for address and word are incomplete because no implementa- tion is defined.They are declared to be types, but no additional information is provided.These incomplete types will be given characteristics by the specification, but no specific implementation is implied or mandated.Thus, the designer must select an implementation at a lower abstraction level.Using incomplete types allows the designer to specify a type's characteristics without specify- ing its implementation.
The characteristics of the address and word types are defined in the LSL Instruction trait.This trait is included in mm_types using a VSPEC includes clause and the trait is shown in Figure 15.The Instruction trait provides definitions for conversion functions that allow instructions, register numbers and addresses to be obtained from memory words.In the final format of the Move Machine instructions (not shown in this paper), this would be imple- mented by defining which bits of a memory word encode the instruction, register number and address.However, when specifying the initial requirements of the device, such details should not be considered.All that must be specified is that instructions, register numbers and addresses can be obtained from memory words.This is exactly what the LSL description allows us to say.
Once the Move Machine's initial requirements are defined, the device can be broken up into an abstract architecture and each of the components can be synthesized individually.For a CPU such as the Move Machine, one such architecture is the canonical fetch-decode-execute structure.An instruction is retrieved, the addressing modes are decoded and dereferenced, and the instruction is executed on its operands.Effectively, the Move Machine is now three components that execute in sequence.
Figure 16 shows the fetch-decode-execute architecture for the Move Machine.The signals mere, reg, IP, IR, EA and CNTL exchange memory, registers and control values between components.The requires and ensures clauses for each component describe transformations per- formed on memory and register values while the sensitive to clauses uses the control value indicates what component(s) should be active.Each component's sensitive to clause indicates that it should be active when its execution phase begins.As with the instruction interpreter, the machine starts by turning on the reset signal.This causes the fetch component to activate and sets the instruction pointer to 0. After reset turns off, all components are inactive until the start signal is asserted.Feteh's sensitive to clause is the only sensitive to clause satisfied by this action, so fetch is the only component that activates.All other components have no affect on the concrete state of the architecture.The fetch component retrieves the current instruction from memory and places it in the instruction register (IR).It also sets the entl signal to decode.
The only component whose sensitive to clause is satisfied at this point is decode.This component calculates the effective address based on the addressing mode specified by the instruction in the IR and sets the cntl signal to execute.The execute component then manipulates the registers and memory based on the current instruction.When a load, store or jump instruction is executed, execute sets the cntl signal to fetch which causes the fetch component to activate and the process starts again.If the halt instruction is processed, execute sets cntl to halt.This makes all three component's sensitive to clauses false and the concrete state of the architecture does not change again until something (such as activating reset) outside of mm changes it.

Software Architecture
The research area most closely related to abstract architecture representation in vsPEC is software architecture [8].Research in this field has led to the development of several architecture description languages, including UniCon [23], WRIUT [3, 4]  and RAPIDE [16, 17].Each of these languages allow the definition of components and connectors to define a software architecture.This is similar to the VI-IDL notion of a structural architecture described in this paper.Shaw's UniCon language [23] is one example of an architecture description language.A UniCon description consists of component and connector definitions.Each of these definitions gives the type (such as Filter or Process for components and Pipe or FileIO for connectors), association units (component players and connector roles) and an implementation for the component or connector.The primary product of the UniCon compiler is Odinfiles, something similar to makefiles that can be used to construct executables for the described architecture.Thus, one of the main products of a UniCon description is a facility that is used to construct an executable version of the described  architecture.This is very different from a VSPEC abstract architecture, which is used to verify that the class of solutions defined by the architecture implements the requirements specified by the VSPEC description of the component.
The WRnx architecture description language [3, 4] by Allen and Garlan is of particular interest when discussing abstract architectures in VS'EC.A WRIGHT description consists of a collection of components interacting via instances of connector types.Each part of a WRIGHT description is defined using a variant of csp [11].Unlike VSPEC'S use of csp to define only communications between components, WRIanX descriptions use csp to define the behavior of components as well.WRIUX'S CSP descriptions define the sequence of events that occur in a component or connector.
Components and connectors interact when one component/connector observes an event provided by another.This may cause the second compo- nent/connector to provide events that cause further interactions.These interactions are all described using csP.RAPIDE [16,17] is an executable architecture description language designed for prototyping architectures of distributed systems.A RAPIDE architecture consists of a set of module specifications (called interfaces), a set of connection rules defining communication between interfaces and a set of formal constraints that define legal patterns of communication.A RAPIDE architecture is executed to produce a partially ordered set of events (poset) that represents the dependencies between events inthe architecture.The RAPIDE tools can then verify this poset does not violate the formal constraints defined in the architecture.
A major difference between RAPIDE and VS'EC is that VS'EC descriptions are not executable.They are intended for formal analysis.
Other VHDL-Related Specification Languages Odyssey Research Associates (ORA) is developing Larch/vii)i, an alternative Larch interface lan- guage for vn)I [13].Larch/vIDL is targeted for formal analysis of a vi-iii description and ORA is defining a formal semantics for vn using s.The isi representations are used in a traditional theorem prover to verify system correctness.
Larch/vm)L annotations are added to a specific vu description to represent proof obligations for the verification process.In contrast to this approach, a VS'EC abstract architecture represents the requirements of a class of solutions that satisfy a specification (also given in VS'EC).
Augustin and Luckham's VA [6] is another attempt to annotate vu).The purpose of a VA annotation to a vut)L description is to document the design for verification.VA provides mechan- isms for mapping a behavioral description to a structural description.Two VA/VU) descriptions of a design can be transformed into a self-checking vI4i program that is simulated to verify that the two descriptions implement the same function.This differs from VSpEC because it does not allow the description of a class of solutions that implement a specification.Instead, it allows the verification that a structural description correctly maps to a behavioral description for the entity.

Larch Interface Languages
Larch interface languages have been developed for a variety of programming languages, including Lc [9], Larch/C + + [15] and LM3 [14], interface languages for C,C+ + and Modula-3, respec- tively.Each of these languages allow the descrip- tion of the pre-and post-conditions for procedures and functions in a sequential programming lan- guage.The portions of these languages that allow this type of specification (i.e., requires, and ensures clauses) are also found in VSpEC, where they are used to specify the transformation performed by a single component.However, since C,C + + and Modula-3 are sequential languages, their Larch interface languages do not have to deal with how the Larch-specified procedures and functions interact when two procedures are executing con- currently as is the case with VSPEC entities.At the present time, we are not aware of other work in the Larch community where pre-and post-conditions are used to specify the behavior of components in an abstract architecture.

CONCLUSION Summary
The ability to evaluate architectural decisions early in the design process enhances overall design quality by allowing architectural errors to be discovered when they are less expensive to fix.Unfortunately, VHUL does not allow evaluation until a simulatable model exists.For many complex systems, simulatable models appear late in the design process making architectural errors difficult to correct.An alternative to simulation for evaluating architectural decisions is formal analysis of abstract architectures at the requirements level.An abstract architecture is a set of inter- connected components where the requirements of each component are known but the implementa- tion is not.This paper presented YSPEC'S support for describing and evaluating abstract architec- tures during requirements specification.
A vspEc abstract architecture is formed by instantiating each component in a VHuL structural architecture with a vseEc entity.The vsPc description of an entity includes a pre-condition, post-condition and an activation condition that describe the entity's functional requirements.If the current state of the system satisfies the activation condition for one of the components in the abstract architecture, that component's pre-condi- tion must hold and the component must satisfy its post-condition in the next state.A refinement of a vsec entity can be compared with the vsec specification using weak bisimulation.If some sequence of state changes in the refinement yields the correct single state change in the higher-level description, weak bisimulation holds.This method can be used to formally determine if a vsPec abstract architecture is a refinement of the vsPEc description of the entity it implements.

Status and Limitations
VSPEC provides a specification capability most appropriate for high levels of abstraction.It is anticipated that designers will represent system requirements with VSPEC, gradually refining re- quirements into architectures and eventually a VHUL design.During requirements specification when a designer is defining the essential requirements of a system, VSeEC is useful for evaluating the impact of architectural decisions.When design details are available, VHUL simulation is a more suitable analysis activity.Although VSPEC can model design detail, formal analysis is far less pragmatic than vuuL simulation in such situations.
A potential limitation to the VSPEC approach is verifying the refinement of VSPEC requirements into VHUL design representations.Formalizing the tie between VSpEC and vm)t.to support verification and comparison with simulation results is the subject of current investigations.In addition, techniques for automatically synthesizing VHUL from VSPEC are currently under development [21,20].Studies of error analysis reports for safety-critical software systems suggest that over 90% of safety related errors arise from incorrect or incomplete specifications, not transformation of requirements into implementations [18].This suggests that the use of techniques such as those proposed here are warranted even before a complete verification path between VSPEC and VHDL exists.
FIGUREvs,c description of a sort entity.

FIGURE 4 A
FIGURE 4 A behavioral VHOL architect.redefining the find component's behavior.

FIGURE 6 A
FIGURE 6 A vHoI architecture representing the composition of a sorting component and a binary search component implementing the find function.
These constructs allow VHOI to support archi- tecture representation.Component declarations describe the inputs and outputs of each component type used in the architecture.Instances of these components are created in the architecture body and configurations are used to map component instances to an entity/architecture pair.Net lists indicate signal flow between component instances while sensitivity lists or wait statements synchronize component actions.

FIGURE 11 VSPEC
FIGURE 11 VSPEC description of a simple buffer.

FIGURE 16
FIGURE 16 High level fetch-decode-execute architecture for the Move Machine CPU.
and state variables.The ensures Example VSPEC entity used to explain the differences between abstract, component and concrete state.