A Brief Summary of VSPEC

A Brief Summary of VSPEC? Perry Alexander 1 , Murali Rangarajan 1 , and Phillip Baraona2 1 Department of Electrical & Computer Engineering and Computer Science PO Box 210030 The University of Cincinnati Cincinnati, OH 2 falex,rmuralig@ececs.uc.edu Chrysalis Symbolic Design, Inc. 101 Billerica Ave 5 Billerica Park Billerica, MA 01862 phil@chrysalis.com Abstract. This paper provides an overview of the vspec behavioral in- terface speci cation language for vhdl. Although operational speci cation language such as vhdl provide exceptional speci cation capabilities, at the systems requirements level the operational style is a hindrance. vspec provides vhdl users with a declarative mechanism for de ning functional requirements and performance constraints. In the tradition of behavioral interface speci cation languages, vspec adds clauses to the vhdl entity construct allowing axiomatic speci cation of functional requirements. Because system constraints play an ever increasing role in systems design, vspec also provides performance constraint speci cation capability. This paper presents the basics of vspec, its semantics, semantic analysis, and brie y describes current and future applications. Keywords: systems level design, notations, languages, VHDL, Larch 1 Introduction Requirements analysis is a critical activity in any systems design process. However, it is poorly supported by tools and languages. Although operational, simulation centered, hardware description languages such as vhdl [1] provide excellent support for design, they are less appropriate for requirements analysis. The operational style tends to introduce implementation bias into requirements. Furthermore, simulation-based analysis is not always appropriate for evaluating highly declarative, frequently incomplete requirements. To address such problems, vspec [2{5] augments vhdl to provide a declarative requirements speci cation capability that support rigorous, formal analysis. ? Support for this work was provided in part by the Advanced Research Projects Agency and monitored by Wright Labs under the RASSP Technology Program, contract number F33615-93-C-1316 and by Air Force MANTECH, contract number F33615-93-C-4303 vspec is a Larch interface language [6, 7] for vhdl. The Larch family of speci cation languages supports a two-tiered, model-based approach to specifying software. A Larch speci cation is written in two languages: a Larch Interface Language (lil) and the Larch Shared Language (lsl). Larch Interface Language de nitions specify the inputs and outputs of a program component and the component's observable behavior. Typically, input and output parameters are de ned in the host programming language. Then, rst order predicates de ne component behavior using a traditional axiomatic style. Larch Interface Languages exist for a variety of programming languages, including C [8, 9], C++ [10] and Ada [11]. lsl is a formal algebraic language that de nes the underlying sorts and operators used in interface language de nitions. As the name implies, lsl is common among all Larch Interface Languages. Speci ers use lsl to de ne reusable domain theories for speci cation activities and to de ne semantics for interface languages. vspec describes the requirements of a digital system using the canonical Larch approach. Each vhdl entity is annotated with a pre- and post-condition to indicate the component's functional requirements. The operators used in a vspec description are de ned with lsl. vspec also allows a designer to describe non-functional requirements and the internal state of a device. vspec semantics is de ned by providing a translation of vspec language constructs and vhdl types into lsl enabling formal veri cation using Larch tools. vspec-annotated components can be connected together to form an abstract architecture. An abstract architecture is an inter-connected collection of components where the requirements of each component are speci ed without de ning their implementation. This describes a class of solutions with a common structure. A standard vhdl structural architecture referencing vspec annotated entities de nes an abstract architecture. The vhdl architecture indicates interconnection in the traditional manner, but the requirements of each component are de ned instead of their implementations. Abstract architectures speci ed with vspec present a problem that other Larch interface languages do not have to address: when is a component in an abstract architecture active? In traditional sequential programming languages, a language construct executes after the construct immediately preceding it terminates. For correct execution, a construct's pre-condition must be satis ed when the preceding construct terminates. In a vspec abstract architecture, each of the components behave as independent processes. There is no prede ned execution order so there is no means of determining when a component's pre-condition should hold. vspec solves this problem by allowing a user to de ne an activation condition for a component. The activation condition de nes what causes the component to begin processing its inputs. When the component state changes to one that satis es the activation condition, the pre-condition must hold and the component performs its speci ed transformation. This paper describes the semantics of vspec, concentrating on the language's facilities for describing abstract architectures. The opening section provides a brief summary of the vspec language. Section 3 describes vspec abstract ar- chitectures, including a de nition of the vspec state model and a description of how a process algebra (csp) [12] is used to provide a semantics for the vspec activation condition. Section 5 discusses how these semantics can be used verify that an abstract architecture satis es the speci cation of the entity. Finally, the paper concludes with a discussion of vspec applications and some related work. 2 The vspec Language vspec's declarative speci cation style complements the traditional vhdl oper- ational style by providing a requirements speci cation capability. As a requirements speci cation language, vspec is used very early in the design process to describe \what" a system should do. The operational style of vhdl makes vhdl alone ill-suited for requirements speci cation. It forces a designer to describe a system by de ning a speci c design artifact that describes \how" the system behaves. When attempting to use vhdl as a requirements speci cation language, this forces a designer to deal with unnecessary detail at a very early point in the design process. In contrast to vhdl's operational style, vspec allows a designer to declaratively describe a component. Together, vspec and vhdl support modeling from requirements acquisition through veri cation and synthesis. As a working example, a vspec description of a sorting component is shown in Figure 1. Three basic clauses de ne functional requirements for an entity: (i) the requires clause de nes the component precondition; (ii) the ensures clause denes the component postcondition; and (iii) the sensitive to clause de nes the component activation condition. E ectively, the requires and ensures clauses de ne component function while the sensitive to clause de nes component control. The requires and ensures clauses are used to de ne an axiomatic relationship between current and the next state. Speci cally, they specify the pre- and post-conditions of the component. Any component that makes the postcondition true in the next state given that the precondition is true in the current state is a valid implementation of these requirements. More precisely, given a component with requires clause ( ) and ensures clause ( )1 , ( ) is a correct implementation of the requirements if the following condition holds: 0 I St O S t; S t post f St ( ) ( ( )) (1) The sensitive to clause plays the same role in a vspec de nition that sensitivity lists and wait statements play in a vhdl description. It de nes when a component is active. The sensitive to clause for sort in Figure 1 states that the entity activates (and sorts its input) whenever the input changes. The sensitive to clause contains a predicate indicating when an entity should begin 8s
I S t 1 ) O S t; f S t The St post notation references the value of St in the state after the transformation described by the entity is performed. This is analogous to the variable notation of lcl [8, 9] 0 0 entity sort is port (input: in integer_array; output: out integer_array); includes sort; modifies output; sensitive to input'event; requires true; ensures permutation(output'post, input) and inorder(output'post); constrained by power <= 5 mW and size <= 3 um * 5 um and heat <= 10 mW and clock <= 50 MHz and input<->output <= 5 Ms; end sort; Fig. 1. H sort y input output x Vcc Clk Time vspec description of a sorting T component. executing and the next section contains a more precise de nition of the meaning of the sensitive to predicate. In the example speci cation from Figure 1, the sort component is de ned to operate correctly in any initial state whenever its input changes and produce an output that is ordered and a permutation of the input. The requires clause de nes a precondition of true. As true holds in any state, the component must execute starting in any state. The ensures clause de nes a postcondition of permutation(input,output'post) and ordered(output'post) requiring that after execution the output should be an ordered permutation of the input. Note that ordered and permutation are de ned in the included trait sort. The sensitive to clause de nes an activation condition of input'event. Event is a prede ned vspec predicate that is true whenever its associated signal changed values in the previous state change. In addition to allowing a designer to describe functional requirements, vspec also allows speci cation of performance constraints. The vspec constrained by clause is used for this purpose. As shown in Figure 1, this clause de nes relations over constraint variables. Currently, the de ned constraint variables include power consumption, layout area (expressed as a bounding box), heat dissipation, clock speed and pin to pin timing. Constraint theories written in lsl de ne each constraint type. Users may de ne their own constraints and theories if desired.2 The state clause contains a list of variable declarations that de ne the internal state of a component. These variables maintain state information that is not 2 constraint speci cation is not presented in detail in this paper. For further exposition, please see the Language Reference Manual [13]. vspec entity find is port (input: in element_array; k: in keytype; output: out element); includes Element(element,keytype, element_array); modifies output; requires true; ensures forall (e : element) (output = e implies (e.key = k and elem_of(e,input))); constrained by power <= 5 mW and size <= 3 um * 5 um and k<->output <= 5 Ms and heat <= 10 mW and clock <= 50 MHz; end search; entity bin_search is port (input: in element_array; k: in integer; value: out element); modifies value; sensitive to k'event or input'event; requires sorted(input); ensures output = e iff (e.key=k and element_of(e,input)); constrained by power <= 1 mW and size <= 1 um * 2 um; end bin_search; (b.) (a.) Fig. 2. vspec descriptions of find and binary search components. visible outside the component. A state clause is not needed in the speci cation of a sorting component in Figure 1 as no internal state is stored. The modifies clause lists variables, ports and signals whose values may be changed by the entity. Most other Larch interface languages contain a modifies clause, and the de nition of vspec modifies clause is very similar to the de nitions found in these languages [8{10]. The includes clause is used to include Larch Shared Language de nitions in a vspec description. The sorts and operators de ned in the lsl trait named by the includes clause can be used in the vspec de nition. 3 Abstract Architectures vhdl structural architectures composed only of vspec annotated components specify abstract architectures. The vhdl architecture syntax remains unchanged indicating component instantiation and connections. However, the con guration does not assign an entity/architecture pair to each component instance in the architecture. Instead, the con guration de nes that each component references an entity with an architecture called VSPEC. This signi es that at the current point in the design, the requirements of this component are known (via the vspec description) but no implementation has been de ned. Consider the vspec description of a find component shown in Figure 2a. The output of find is the element from the input array with the same key as architecture structure of find is configuration test_vspec of find is for structure component sort port for b1:sort use entity (input: in element_array; work.sort(VSPEC); output: out element_array); end for; end component; for b2:search use entity component search port work.bin_search(VSPEC); (input: in element_array; end for; key: in integer; end for; value: out element); end test_struct; end component; signal y: element_array; begin instance b2 of instance b1 of searcher component b1: sort port map(input,y); sorter component y input input input output b2: search port map(y,k,output); output value end structure; k key find entity Fig. 3. A vspec abstract architecture representation of the find component. the k input. This requirement is represented by find's ensures clause predicate. One possible way to meet this requirement is to connect the output of a sorting component to a binary search component as shown in Figure 3. The speci cation for sort is the same as the one in in Section 2, while the bin search speci cation is shown in Figure 2b. The only di erence between this structural description of find and a vhdl structural description of find is that the con guration speci es that the vspec descriptions of sort and bin search should be used instead of a speci c architecture for these two entities. This con guration describes an abstract architecture for the find component. Any implementation satisfying the vspec requirements of sort and bin search may be associated with the entity de nitions. This abstract architecture for find actually de nes a class of solutions with a common structure. Although a vhdl architecture referencing vspec de nitions de nes components and interconnections, 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 satis ed when the preceding construct terminates. In hardware systems, components exist simultaneously and behave as independent processes. No prede ned execution order exists so there is no means of implicitly determining when a component's pre-condition should hold. Consider the find example. The pre-condition of bin search must 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 statements to synchronize entity execution and de ne when a component in a structural architecture is active. 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. E ectively, this activation condition de nes when a vspec annotated entity's precondition 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 state of the system. In the find example, both components activate when any of their input signals change. Formally, the contribution of the sensitive to clause to the transformation speci ed by vspec is easily represented using a traditional process algebra such as csp [12]. Components become processes and events are de ned as the states the entity enters. Thus, any vspec component can be described by a process that consumes states and generates a process in a new state. To de ne such state changes, a component state is de ned along with a means for combining component states into an architecture state. The formal vspec model of the state of a component is based on Chalin's state model [8, Chapter 6] for lcl. This model partitions the computational state of an lcl description into an environment and a store [14]. The environment maps (variable) identi ers into objects and the store binds objects to the values they contain: Env: Id -> Obj Store: Obj -> Value Separating the environment and the store is common among formal models of programming language semantics. In a language such as lcl, one of the motivating factors for this is to allow multiple names for the same element of memory. For example, two C pointers can obviously reference the same memory location. The program state model above represents this situation by mapping each of these pointers to the same object in the map. This partitioning of the state of a component is used in the vspec semantics to model component communication. For a single vspec-speci ed component, contains a map from each port and state variable in the vspec description to an object. maps each of these objects to their current value. We call this the abstract state of the vspec component. When vspec components are connected together to form an abstract architecture, the elements of and are slightly di erent. The contains objects for each port in the architecture's entity, for each signal in the architecture and for the state variables of each component in the architecture. The maps each of these three types of elements to the proper object, but it also maps the ports of each architecture component to the object that represents the architecture signal the port is connected to. We call the state model of an abstract architecture the concrete state of the component. In the simple two component example of Figure 4, the abstract state of system, A and B are: E nv E nv S tore E nv S tore S tore E nv E nv system = f sys in 7! obj sys in ; sys out 7! obj sys out g architecture struct of system is component A port (x : in integer; y : out integer); end component; component B port (w : in integer; z : out integer); end component; signal c; entity A is port (x : in integer; y : out integer); requires IA(x); ensures OA(x,y'post); modifies y; end A; entity B is port (w : in integer; z : out integer); requires IB(w); ensures OB(w,z'post); modifies z; end B; begin c1: A port map(sys_in,c); c2: B port map(c,sys_out); end struct; entity system is port (sys_in : in integer; sys_out : out integer); end system; Fig. 4. Example of two entities connected serially. Storesystem = EnvA = StoreA = EnvB = StoreB = fobjsys in 7! vsys in ; objsys out 7! vsys outg fx 7! objx; y 7! objy g fobjx 7! vx; objy 7! vy g fw 7! objw ; z 7! objz g fobjw 7! vw ; objz 7! vz g The concrete state of the struct architecture is: f 7! !7 7! 7! 7! 7! Envstructsystem = sys in objsys in ; sys out objsys out ; c objc ; x objsys in ; y objc ; w objc ; z objsys out Storestructsystem = objsys in vsys in ; objsys out vsys out ; objc vc f 7! 7! 7! g !7 g Notice that x, y, w and z now map to the objects that contain the values of the signals that these component ports are connected to in the architecture. Using a component's state, its semantics are de ned using a csp process and its requires and ensures clauses. Let f (St) be a function between two states of entity C that implements the requirements speci ed in C 's requires and ensures clauses (i.e. f (St) satis es Equation 1). The process de ning entity C with a sensitive to predicate S (St) in any state r is: Cr = r : ! Cf r ( ) (2) where is the set of states that satisfy C 's activation condition: = ft : TC j S (t)g. The traces of the process de ned by a vspec entity is a sequence of abstract states the entity enters. When the abstract state changes to an abstract state that satis es the entity's activation condition (r in Equation 2), the transformation de ned by the requires and ensures predicates (f (St)) is applied to r. This generates a new abstract state and the entity behaves like the process de ned by Cf (r) . The abstract states that satisfy C 's activation condition form the alphabet of C . Thus, every trace of C contains only elements from . csp's concurrency operator (k) combines component processes to de ne the behavior of a vspec architecture. Let C1 ; C2 ; :::; Cn be the processes represented by Equation 2 for the set of vspec component instances in architecture A. The process representing architecture A is: A = C k C k ::: k Cn (3) When a state change occurs that satis es some component's activation condition, the component performs its speci ed transformation to its abstract state. This change is propagated to the concrete state of the architecture where the activation condition of another component may be satis ed. This causes the process to repeat until the system changes to a concrete state where no component's activation condition is satis ed. The system then waits until some external device changes the concrete state to one that activates some component in the architecture to start the process again. In the csp model of a vspec process, this notion can be understood by examining the possible traces of A from Equation 3. Hoare [12] de nes traces over parallel composition, traces(C1 k C2 ), as: 1 ft j (t " 2 C1 ) 2 traces(C1 ) ^ (t " C2 ) 2 traces(C2 ) ^ t 2 ( C1 [ C2 ) g (4) Recall that in csp [12], t " P restricts the trace t to contain only events that appear in the alphabet of P . Thus, the traces of a parallel composition of components are all traces that when restricted to the alphabet of each component yield a trace of that component. Furthermore, traces of C1 k C2 only contain events from the alphabet of the two components. This means that every trace of A contains only elements that satisfy the activation condition of at least one component in A. 4 Generating Semantic Models vspec semantics are used to verify requirements by transforming vspec into Larch Shared Language equivalent representations and using the Larch Prover. The savant vhdl parser [15] has been extended to recognize vspec components and generate lsl representations. To support translation, background theories representing: (i) vhdl data types; (ii) the store model; and (iii) the CSP semantics were implemented to provide underlying semantics. The resulting lsl models are suitable for various veri cation activities using the Larch Prover. Extending the savant parser to recognize vspec and generate lsl required extending the language recognizer and the aire intermediate form. The parser was extended in the canonical fashion to recognize and type check vspec components. To generate lsl representations, the aire intermediate form has been extended to include: (i) vspec constructs; and (ii) \publish" methods to generate lsl traits representing components and architectures. Generating lsl representations for vhdl data types, the store model and csp functions involves de ning lsl theories for each construct. For each vhdl type, a parameterized trait was developed. When the associated type is used in a speci cation, the appropriate trait is included to provide a theory for that type in the lsl model. Similar techniques are used for the store and csp models. lsl traits de ned by Chalin [8] were reused here after some modi cation and reveri cation. For csp functions, the csp axiomatization developed by Camilleri [16] is adapted. Camilleri's original theories were developed in HOL [17], thus requiring translation to lsl and veri cation. The only challenging task associated with translating Camilleri's csp axiomatization involved moving from a higher order logic representation to a rst order representation. Speci cally, the csp choice operation plays a major role in the vspec de nition. In the HOL axiomatization, choice is parameterized over a choice operation. In lsl, this is achieved using a parameterized trait with the choice function as a parameter. The instantiation of the trait parameter is achieved at parse time requiring a new version of the choice trait to be instantiated for each instance of choice. The higher order representation allows instantiation of the choice function at proof time making for dramatically simpler proof activities. Each vspec component is translated into an associated lsl trait. Brevity prevents the expansion of a component in this paper, however these traits share a common structure centering on: (i) the pre- and post-conditions; and (ii) the csp choice operator. Speci cally, the choice operator is specialized by specifying a choice function and an alphabet. The alphabet speci es what states can occur next and was de ned as earlier. The choice function generates the next state and is de ned using the pre- and post-condition of the component. Figure 5 shows the template used to generate lsl traits for each system component. The trait is instantiated using the table shown in Table 1. In the template, operations I(pre) and O(pre,post) are instantiated with the vspec component's requires and ensures clauses respectively. The sensitive to clause is incorporated in the alphabet of the csp process associated with each component. Recall that the alphabet of the component is de ned to be the set of states satisfying the activation condition. Note that the constrained by clause is not involved in the de nition. Performance constraints are evaluated using pdl as described in a later section. trait name ( port_list %% Port symbols from entity state_variable_list %% State symbols from state clause I, O, modSet, modSet_event, input_event, Psi, InitStates, maintain_state, F, well_def_alpha, choice_F, choice_traces, choice, entity_process) : trait includes OneComponent includes includes_list %% Traits explicitly included by the entity includes type_trait_list %% Traits included to define VHDL types includes program_store_list %% Traits representing program store introduces port_declaration_list %% Declaration of ports state_variable_declaration_list %% Declaration of state variables asserts pre, post, any: Store InitStates_predicate; %% Value of outputs and state does not change from post state of %% one element of trace top the next element of the trace maintain_state(post,any) == maintain_state_predicate; %% Sensitive to clause defines Psi pre Psi == modified_sensitive_to_predicate; %% requires clause defines I I(pre) == modified_requires_predicate; %% ensures clause defines O O(pre,post) == modified_ensures_predicate; %% modifies clause defines modSet modSet == ( \ins modifies_list); modSet_event(any) == modifies_event_list; %% True when an event occurs on an input signal input_event_assertion; %% All objects are active objects in store model active_objects_assertions; %% All objects above are independent of one another indep(empty \apd independent_objects_list); independent_objects_assertions; 8 2 fg Fig. 5. Template specialized to generate traits for single components. 5 Veri cation Correctness checks in vspec take three fundamental forms: (i) component verication; (ii) interconnection veri cation; and (iii) bisimulation. Component and interconnection veri cation represent partial correctness checks used to quickly assess the quality of a speci cation. Bisimulation precisely de nes the relationship between a vspec architecture and an associated system speci cation. Although component and interconnection veri cation only verify speci c system properties, they are frequently simpler to prove than bisimulation relationships. Component veri cation allows users to specify properties of a single component using lsl. The component is transformed into an lsl trait and the Larch Prover called with the property as a theorem. Component interconnections are not considered and typically only the precondition, postcondition and activation condition are included the veri cation. This is the simplest veri cation activity and is used simply to verify properties of single vspec components. Name from Template Description trait name entity name trait port list Comma-separated list of all entity port names. state variable list Comma-separated list of all entity state variable names. includes list Comma-separated list of names of all traits explicitly included in the entity. type trait list Comma-separated list of trait names that de ne the vhdl types needed in this entity. program store list Comma-separated list of sorted projections of the program store (SProjStore) needed in this trait. port declaration list lsl constant declaration for each port signal in the entity. state variable declaration list lsl constant declaration for each state variable in the entity. InitStates predicate Predicate to de ne initial Stores an entity can enter. Takes into account the initial value of all entity state variables. maintain state predicate Assertion that the value of all outputs and state variables does not change from Store post to Store any. modi ed sensitive to predicate Entity's sensitive to clause predicate converted to lsl format with all port and state variable references replaced with call to Chalin's val operator for the proper Store (pre or post). modi ed requires predicate Entity's requires clause predicated converted to lsl format with all port and state variable references replaced with call to Chalin's val operator for the proper Store (pre or post). modi ed ensures predicate Entity's ensures clause predicated converted to lsl format with all port and state variable references replaced with call to Chalin's val operator for the proper Store (pre or post). modi es list List of all modi ed port signals and state variables (including \implicitly" modi ed ones). The \ins operator separates each element in this list. modi es event list Assertion there is an event on the value of at least one modi ed object in Store any. input event assertion Disjunction of statements that an event occurred on an input signal in state any active objects assertions Assertion of the form X \in activeObjs(any) for every object X (i.e. each signal and state variable) in the entity. independent objects list List of all objects in the entity. The \apd operator separates each element in this list. independent objects assertions One commented out assertion of the form ~depOn(dwn(x), dwn(y)) for every possible combination of port signals and state variables x and y. Table 1. Summary of substitutions to create a trait for an associate entity using the entity template. Interconnection veri cation examines speci c relationships between components. As the name implies, interconnection veri cation centers primarily on properties of interconnected ports. In most cases, users select from pre-de ned conditions. Proof obligations are generated and veri ed automatically in most cases. Speci c examples of interconnection veri cations include proving: (i) all outputs from a component are legal inputs to another; (ii) some output from a component will activate another; and (iii) all inputs activating a component are legal component inputs. Many similar, additional obligations can be generated and discharged automatically. Bisimulation allows a user to verify that an abstract architecture correctly implements its requirements. This veri cation obligation is generated automatically by the vspec parser and is based on weak bisimulation [18]. A weak bisimulation (or simply bisimulation) condition holds when a sequence of states in the architecture (or concrete) model produces the desired single state change speci ed by the system level (or abstract) model (see Figure 6). Only the rst and last state of the concrete state sequence are signi cant. The speci c state sequence leading from the initial concrete state to the nal concrete state is ignored. S S’ Component Execution Abstract State Concrete State s s’ s’’ s’’’ Fig. 6. Concrete state changes associated with a single abstract state change. Equation 5 is a weak bisimulation correctness obligation for showing abstract architecture A satis es a single abstract state change. Here, A is the set of concrete states where the activation condition of at least one component in A is true. The obligation states that for all traces of the concrete state starting in a state whose abstract projection satis es the abstract speci cation's pre-condition, either the resulting process state satis es the component postcondition or the process can consume the state and continue. 8 : traces(A)
I (abs(0 )) ^ A= = As ) (O(abs(0 ); abs(s)) _ s 2 A ) (5) In addition to functional veri cation, the current vspec tool suite supports constraint veri cation using The Performance Description Language (pdl) [19]. The semantics of constraints is de ned using lsl in a fashion similar to the other vspec clauses. However, constraint evaluation requires signi cant manipulation of intervals. This activity proved to be exceptionally dicult in the Larch toolset. pdl is a language designed explicitly for representing and evaluating constraint information. Speci cally, pdl provides a mechanism for representing and evaluating interval mathematics representations. In pdl, designers de ne models for various constraint types. These models are then used to instantiate architectures of components. Each interconnected component is assigned one model for each constraint to be evaluated. vspec constraint evaluation allows the user compare a systems level constraint description to an architectural description. For each vspec constraint, a pdl model has been de ned. Each model minimally de nes the data type associated with the constraint, and a function to combine two constraint values. An architecture is derived from the vhdl architecture and populated with the various constraint models. Using the pdl evaluator and the combine operators associated with each constraint, a system level constraint value is calculated. This value is then compared with the system level speci cation to determine if the architecture meets its associated systems level performance requirements. 6 vspec in Practice vspec has been evaluated in both academic and industrial settings. Many ex- ample speci cations have been written in the research setting. Two of which, the Move Machine and Find, represent signi cant milestones in the vspec lifecyle. More recently, TRW has used vspec to specify two signi cant avionics components. 6.1 The Move Machine The rst signi cant speci cation developed using vspec was done by Baraona [4]. The Move Machine is a simple CPU speci cation where operations are mapped to memory locations. The only operations performed by the Move Machine move data from one memory location to another. The Move Machine was speci ed as an instruction interpreter and at the register transfer level. Speci cations were written, however no analysis was performed. The Move Machine exercise served to shake out initial problems in the vspec semantics. Although no veri cation was performed, the exercise represented the rst actual vspec usage example. Furthermore, the example represents a common class of systems and provided an excellent usage example for early users. 6.2 Find The Find system and architecture speci cations presented in Figure 2 represent the rst complete bisimulation veri cation activity performed using vspec. Like the Move Machine, Find was developed as a synthesis benchmark and exhibits some interesting modeling capabilities. Speci cally, the use of activation conditions to model data caching. The Find architecture decomposes the problem into two components: (i) a sorting component; and (ii) a binary search component. The architecture is speci ed to cache the results of sorting so that if the input array does not change, it is not resorted. The result is a more ecient search. Speci cations similar to those presented in Figure 2 were written and parsed by the original vspec parser. Formal models were generated by the parser and the Larch Prover was used to perform the veri cation. For this example, the proof obligations necessary to show the bisimulation relationship were written by hand. Although the veri cation was completed successfully, this activity demonstrated limitations in using lsl and the Larch Prover for veri cations of this size. The fundamental problem was the rst order nature of lsl and the mechanisms used to specify the basic CSP theories. 6.3 Pulse Interval Processor In an initial technology transfer e ort, vspec was used jointly by TRW and The University of Cincinnati to model the Pulse Interval Processing (PIP) section of an Interrogate Friend or Foe (IFF) transponder. The IFF transponder redesign represents a real Digital Signal Processing (DSP) product being designed and elded by TRW. Although vspec was not used in the actual design ow, we were given access to speci cations and worked with engineers designing the system. Unfortunately the PIP architecture is proprietary to TRW and details of the speci cation cannot be presented here. However, several important results are presented. The PIP is an interesting challenge problem because of its means of encoding information. The PIP's function is to: (i) receive pulses from a digital signal processing system; (ii) transform pulse trains into commands; and (ii) produce appropriate output in response to those commands. Commands are used by other aircraft and air trac control systems to gather information about an aircraft's altitude, position, mission and origin. The PIP is a particularly interesting model because information is encoded in the time di erence between received pulses. This presented an interesting speci cation challenge as vspec does not use a temporal logic. The speci cation was written using lsl to represent pulse times and their associated receive times. Pulse streams are processed by examining each pulse with respect to the PIP state and receive time of the last pulse. When a pulse is received its receive time is stored in the PIP state. When a second pulse is received, the di erence between its receive time and the stored receive time determines the command issued. The vspec state clause is used to maintain the last pulse received and a nested IF-THEN-ELSE statement is used to represent various processing cases. The PIP speci cation was partially veri ed by automatically generating interconnect and component proof obligations. We were able to verify several interconnect conditions and TRW found one type error that had not been caught in the actual design ow. This error was not signi cant and would likely have been caught during design inspection or testing. No bisimulation relationships were speci ed or veri ed as the PIP architecture was established before beginning this speci cation task. As an extensive design activity for PIP preceded our e orts and this represented a redesign of a well understood system, the use of vspec did not seriously impact the actual design ow. However, design engineers commented that writing vspec made speci cation of test vectors much simpler. This represents an interesting and somewhat unexpected result. 6.4 Real Time Monitor The Real Time Monitor (RTM) is a proprietary special purpose signal processor used in military aircraft avionics subsystems. It is similar to the PIP except it contains programmability features allowing it to process multiple pulse streams and recognize multiple protocols. The RTM processor was speci ed by TRW exclusively with only vspec language assistance from the developers. Little veri cation was performed due to time restraints on the overall project. Although details of the activity are considered proprietary, TRW acknowledges that using vspec played a key role in reducing estimated product costs by 25%. They observed that although vspec increased cost and development time during requirements analysis and representation, early mitigation of errors, precise requirements capture and ease of test vector generation compensated for initial costs. Speci cally, they reported that the result of the vspec speci cation activity resulted in much more precise and complete speci cations. Even without extensive veri cation, they reported discovering and mitigating ambiguities in the speci cations. Although only one legitimate error was discovered, using vspec forced them to be more precise in their speci cation activities. However, it should be noted that the primary motivation for writing vspec was a promise for automated veri cation, not more precise speci cations. An unexpected result was TRW's engineer's belief that having vspec specications made de ning and generating test vectors an easier task. In the design and implementation of avionics systems such as those developed by TRW, test vector generation and maintenance is a resource intensive task. TRW engineers reported that having vspec speci cations made identi cation of test cases and de nition of test vectors easier. Although unexpected, careful analysis indicates this result is not surprising. It should be the case that test vectors correspond with requirements and ultimately that is what they are designed to test. This result is being explored in a follow on e ort to determine if vspec can systematically impact the testing process. TRW commented further that mature tools integrated into vhdl design environments would contribute to potential cost savings. Although this represents a development task, it does indicate the importance of integrating formal methods into traditional design ows. 6.5 Evaluation Summary The vspec language and tools were evaluated with respect to two internal and two industrial examples. Internal examples were evaluated by students at The University of Cincinnati. The rst industrial example was evaluated jointly with TRW and the second evaluated solely by TRW. Table 2 represents speci cation and veri cation operations performed in each example. Each evaluation was completed to a large degree of success. Although language semantics and tool problems were certainly found, TRW is continuing to actively use vspec and continues to support tool development activities. 7 Related Work Odyssey Research Associates (ORA) has developed Larch/vhdl, an alternative Larch interface language for vhdl [20]. Larch/vhdl is targeted for formal analysis of a vhdl description and ORA is de ning a formal semantics for vhdl Example System Architecture Interconnect Bisimulation Spec Spec Veri cation Veri cation Move Machine X X Find X X X X X PIP RTM X X Table 2. Major vspec evaluation activities. using lsl. The lsl representations are used in a traditional theorem prover to verify system correctness. Larch/vhdl annotations are added to a speci c vhdl description to represent proof obligations for the veri cation process. This di ers from vspec's purpose of representing requirements and design decisions at high levels of abstraction. Augustin et al.'s val [21] is another attempt to annotate vhdl. The purpose of a val annotation to a vhdl description is to document the design for veri cation. val provides mechanisms for mapping a behavioral description to a structural description. Two val/vhdl descriptions of a design can be transformed into a self-checking vhdl program that is simulated to verify that the two descriptions implement the same function. This is once again slightly di erent than vspec's purpose of high level requirements representation. The abstract architecture representation capabilities of vspec are also fairly closely related to several architecture description languages that have been developed to describe software architectures [22]. Some of the more well known architecture description are UniCon [23], Wright [24, 25] and Rapide [26, 27]. Each of these languages allow the de nition of components and connectors to de ne a software architecture. This is very similar to the vhdl notion of a structural architecture. Allen and Garlan's Wright language is of particular interest when discussing vspec because a Wright component is de ned with a variant of csp. Unlike vspec's use of csp to de ne component synchronization, Wright uses csp to de ne component behavior as well. A Wright description consists of a collection of components interacting via instances of connector types. Wright's csp descriptions de ne the sequence of events a component or connector participates in. 8 Conclusions and Current Status Several problems and complexities of the Larch-based semantics were discovered in our prototyping activities. In an e ort to eliminate diculties, the vspec semantics have been transformed into PVS [28] form. The use of higher order logic substantially simpli es the speci cation and veri cation of CSP properties. The vspec parser has been re-implemented in Java and generates PVS models in place of Larch. The higher order nature of PVS and maturity of its associate toolset will dramatically improve veri cation eciency. vspec is currently involved in several commercialization e orts. First, under Air Force and TRW sponsorship, the vspec toolset is being integrated with Mentor Graphics' Renoir development environment. This integration will allow vspec to be evaluated by engineers in their traditional design cycle. Second, under DARPA and EDAptive Computing sponsorship, vspec is being used to facilitate component retrieval by comparing component requirements with available components described by vspec. Comparing requirements with components formally supports high assurance in the quality of the match. Finally, under TRW sponsorship we have begun an e ort to generate test vectors from vspec speci cations. This paper brie y presented the vspec language and its associated semantics. The semantics of single components were de ned using a canonical axiomatic approach. Activation conditions were described and a csp-base semantics provided. The use of vhdl architectures to describe abstract architectures was then discussed. The paper concluded with a presentation of examples used to evaluate the system and results of those activities. References 1. IEEE Standard VHDL Language Reference Manual. New York, NY, 1993. 2. P. Alexander, P. Baraona, and J. Penix. Using Declarative Speci cations and Case-Based Planning for System Synthesis. Concurrent Engineering: Research and Applications, 2(4), 1994. 3. P. Alexander, P. Baraona, and J. Penix. Application of Software Synthesis Techniques to Composite Systems. In Computers in Engineering Symposisum of the ASME ETCE, Houston, TX, January 1995. 4. P. Baraona, J. Penix, and P. Alexander. VSPEC: A Declarative Requirements Speci cation Language for VHDL. In Jean-Michel Berge, Oz Levia, and Jacques Rouillard, editors, High-Level System Modeling: Speci cation Languages, volume 3 of Current Issues in Electronic Modeling, chapter 3, pages 51{75. Kluwer Academic Publishers, Boston, MA, 1995. 5. Phillip Baraona and Perry Alexander. Abstract architecture representation using VSPEC. VLSI Design, 9(2):181{201, 1999. 6. J. Guttag, J. Horning, and J. Wing. The Larch Family of Speci cation Languages. IEEE Software, 2(5):24{36, 1985. 7. John V. Guttag and James J. Horning. Larch: Languages and Tools for Formal Speci cation. Springer-Verlag, New York, NY, 1993. 8. Patrice Chalin. On the Language Design and Semantic Foundation of LCL, a Larch/C Interface Speci cation Language. PhD thesis, Concordia University, Department of Computer Science, Montreal, Quebec, Canada, December 1995. 9. John V. Guttag and James J. Horning. Introduction to LCL, A Larch/C Interface Language. Technical Report 74, Digital Equipment Corporation Systems Research Center, 130 Lytton Avenue, Palo Alto, CA 94301, July 1991. 10. Gary T. Leavens. Larch/C++ Reference Manual. Available at: ftp://ftp.cs. iastate.edu/pub/larchc++/lcpp.ps.gz, 1995. 11. David Guaspari, Carla Marceau, and Wolfgang Polak. Formal Veri cation of Ada Programs. IEEE Transactions on Software Engineering, 16(9):1058{1075, September 1990. 12. C. A. R. Hoare. Communicating Sequential Processes. Prentice-Hall, Englewood Cli s, 1985. 13. Knowledge Based Software Engineering Laboratory, University of Cincinnati. VSPEC Language Reference Manual, 1996. 14. R.D. Tennent. Principles of Programming Languages. Computer Science Series. Prentice-Hall International, 1981. 15. P. A. Wilsey, D. E. Martin, and K. Subramani. Savant/tyvis/warped: Components for the analysis and simulation of vhdl. In VHDL Users' Group Spring 1998 Conference, pages 195{201, 1998. 16. Albert John Camilleri. Mechanizing CSP trace theory in higher order logic. IEEE Transactions on Software Engineering, 16(9):993{1004, September 1990. 17. M. J. C. Gordon. HOL: A proof generating system for higher-order logic. In G. Birtwistle and P. A. Subrahmanyam, editors, Current Trends in Hardware Veri cation and Automated Theorem Proving, pages 73{128. Springer-Verlag, 1989. 18. Robin Milner. A Calculus of Communicating Systems, volume 92 of Lecture Notes in Computer Science. Springer-Verlag, Berlin, 1980. 19. Ranga Vemuri, Ram Mandayam, and Vijay Meduri. Performance modeling using PDL. Computer, 29(4):44{53, April 1996. 20. D. Jamsek and M. Bickford. Formal Veri cation of VHDL Models. Technical Report RL-TR-94-3, Rome Laboratory, Griss Air Force Base, NY, March 1994. 21. L. Augustin, D. Luckham, B. Gennart, Y. Huh, and A. Stanculescu. Hardware Design and Simulation in VAL/VHDL. Kluwer Academic Publishers, Boston, MA, 1991. 22. D. Garlan and M. Shaw. An Introduction to Software Architecture. In V. Ambriola and G. Tortora, editors, Advances in Software Eng. and Knowledge Eng., volume 2, pages 1{39. World Scienti c, New York, 1993. 23. M. Shaw, R. DeLine, D. Klein, T. Ross, D. Young, and G. Zelesnik. Abstractions for Software Architecture and Tools to Support Them. IEEE Transactions on Software Engineering, 21(4):314{335, April 1995. 24. R. Allen and D. Garlan. Formalizing Architectural Connection. In Proc. Sixteenth International Conference on Software Engineering, pages 71{80, May 1994. 25. R. Allen and D. Garlan. A Case Study in Architectural Modelling: The AEGIS System. In Proceedings of the 8th International Workshop on Software Speci cation and Design, March 1996. 26. D. Luckham, J. Kenney, L. Augustin, J. Vera, D. Bryan, and W. Mann. Speci cation and Analysis of System Architecture Using Rapide. IEEE Transactions on Software Engineering, 21(4):315{355, April 1995. 27. D. Luckham and J. Vera. An Event-Based Architecture De nition Language. IEEE Transactions on Software Engineering, 21(9):717{734, September 1995. 28. Judy Crow, John Rushby, Natarajan Shankar, and Mandayan Srivas. A Tutorial Introduction to PVS. SRI International, Menlo Park, CA, June 1995. Presented at WIFT'95.