From windley@cheetah  Fri Feb 16 11:37:38 1990
Received: by iris.ucdavis.edu (5.57/UCD.EECS.2.0)
        id AA12940; Fri, 16 Feb 90 11:37:38 PST
Received: from cheetah.ucdavis.edu by clover.ucdavis.edu (5.59/UCD.EECS.1.11)
        id AA27951; Fri, 16 Feb 90 11:41:57 PST
Received: by cheetah.ucdavis.edu (AIX  2.1.2/3.14)
        id AA00160; Fri, 16 Feb 90 11:33:03 PST
Message-Id: <9002161933.AA00160@cheetah.ucdavis.edu>
To: info-hol@clover
Subject: 1989 User's Group Meeting Abstracts (2 of 2)
Date: Fri, 16 Feb 90 11:33:02 -0800
From: Phil Windley <windley@cheetah>


% here's part 2...
%
% opps!  I didn't mean to leave one line dangling.  Make sure this line is
% connected to the prvious paragraph!

mixed hardware/software systems.

\paragraph{Design Methodology}
The main part of the presentation used some foils I had prepared some time
earlier to describe how a consistent methodology could be used to design
hardware in both a top-down and bottom-up manner which could be
incorporated with a CAD design database.

The problem was that when designing a module that includes submodules you
have to either already have designed the sub-modules, forcing design to be
bottom up, or to use specifications of the submodules. If specifications
are used then when implementations are produced a proof has to be performed
to replace the specifications by implementations. Also, the designer needs
to know which sub-modules are implemented and which are still just
implementations.

The method suggested involved treating sub-modules as extra parameters to
the module. Then the correctness statement of a module was of the form

\begin{quote}
``For all sub-modules implementations\\
\hspace*{2em} (each sub-module implementation implies its specification)\\
\hspace*{2em} implies the module with those sub-modules implies its specification''
\end{quote}

For example for a 4 bit adder with 1-bit adder submodules this would be in HOL

\[
\begin{array}{l}
\forall ADDER\_IMP \bullet \\
\qquad(\forall x?,y?,cin?,s!,cout!:cout \bullet\\
\qquad\qquad ADDER\_IMP(x?,y?,cin?,s!,cout!)\\
\qquad\qquad \implies ADDER\_SPEC(x?,y?,cin?,s!,cout!))\\
\qquad\implies\\
\qquad\forall cin?, cout:sig, x?, y?, s!:bus4 \bullet \\
\qquad\qquad ADDER4\_IMP\; ADDER\_IMP (x?,y?,cin?,z!,cout!)\\
\qquad\qquad \implies ADDER4\_SPEC (x?,y?,cin?,z!,cout!)
\end{array}\]

The proof of this is much easier than might appear as suitable applications
of rewriting,
\verb!STRIP_TAC! and \verb!RES_TAC! reduce to the ``normal'' proof.

At some level the designer encounters true implemented modules.  These have
a correctness term of the form ``implementation implies specification''.
Such implementations without sub-module parameters are termed
``realizations'' to indicate that they are for-real designs.  A realization
can be used in a higher level modules and by instantiating them in the
parameter list of that module. Now using modus ponens with the
specification term for the realization and that of the enclosing module one
of the relevant sub-module assumption in the implementation can be removed.
Once all sub-module parameters are replaced by realizations the module
itself becomes a realization.

The benefits of this technique are

\begin{itemize}
\item
``Realizations'' are always genuine usable designs --- a realization can
only be constructed out of other realizations.
\item
Design can be top-down or bottom-up as sections can be left as specifications.
\item
Annotations were shown on how this method could be added to the INMOS HDL
to allow for inclusion in CAD tools.
\end{itemize}

\talk{Semi-Custom Verification}
     {Phillip J. Windley\\
      {\em windley@iris.ucdavis.edu}\\
      University of California, Davis}

The terms ``custom'' and ``semi--custom'' have come to have particular
meanings in the chip fabrication business.  A ``semi--custom'' VLSI chip
is one fabricated from pre--designed gate arrays,
making it both cheaper to fabricate and less efficient (in space and time)
than a fully custom design.  We use these words in a analogous manner to
describe the verification of a microprocessor that can be changed with
little reverification cost, but with some lose of flexibility.

Formal verification promises to provide increased confidence that computer
systems meet their specifications; but to realize this benefit, the cost and
complexity of formal verification must be reduced.  To date,
verification has primarily been used in safety--critical and
security--critical computer systems where the cost and complexity can be
justified.  Other systems, however, could benefit from the application of
formal methods if simpler means of verifying hardware and software can be
found.

Several microprocessors have been verified using formal methods.  Each of
these verifications has been ``full--custom,'' that is, each microprocessor
design and subsequent verification was done to some custom specification.
Because of the complexity of verifying real computer systems, the only
successful verification efforts have been on relatively simple
microprocessor architectures (fewer than 32 words of micro--instruction
store, small instruction set, limited features for supporting operating
systems, etc.).  The largest of these microprocessors, the VIPER
microprocessor, was abandoned due to the large amount of human effort
seemingly required to complete the proof.

This talk discusses the formal verification of a microprocessor, but more
importantly, we present a theory of interpreter hierarchies that
provides a means of significantly reducing the complexity of microprocessor
verification.  This theory is embodied in a set of tools and techniques for
the HOL theorem prover.  We present the theory and a discussion of how this
theory leads to the ``semi--custom'' verification of microprocessors making
formal methods more accessible to the design engineer.  For a more detailed
treatment of this research see [1,2].

\noindent
{\bf Reference:}
\begin{enumerate}
\item
Windley, Phillip J.,``A Hierarchical Methodology for Verifying
Microprogrammed Microprocessors,'' University of California, Davis Division
of Computer Science Research Report No.  CSE-89-27, November, 1989.
\item
Windley, Phillip J, ``The Semi-Custom Verification of Microprocessors,''
University of California, Davis Division of Computer Science Research
Report No.  CSE-90-1, January, 1990.
\end{enumerate}

\newpage
\section{Foundations Session.}
{\bf Session Chair:} Tom Melham, Cambridge University

\begin{flushleft}
{\bf December 15, Afternoon}

\vspace{.25truein}
{\bf Speakers:}

\begin{tabular}{ll}
Ton Kalker      & {\em Well-ordering and Cardinals in HOL }     \\
                &                                               \\
Elsa Gunter     & {\em Abstract Theories for HOL}               \\
                &                                               \\
Sten Agerholm   & {\em Automating a Model Checker}              \\
Henrik Skjoedt  &                                               \\
                &                                               \\
Stig Pedersen   & {\em Modeling of Diagnostic Reasoning}        \\
\end{tabular}
\end{flushleft}

\newpage
\talk{Well-ordering and Cardinals in HOL}
     {Ton Kalker\\
      {\em kalker@apolloway.prl.philips.nl}\\
      Philips Research Laboratories, The Neatherlands}

The notion of a well-ordering as defined in ordinary set theory is
recalled: A linear ordering on a set S is called a well-ordering if every
non-empty subset E of S has a smallest element.

A famous theorem of Zermelo (1904) asserts the fact that the axiom of
choice is equivalent to every set having at least one well-ordering.  As in
the HOL logic the axiom of choice is automatic by the presence of the
Hilbert choice operator, the above mentioned set-theoretical fact can be
translated to the HOL logic. We showed how set theory can be ``simulated'' in
HOL by representing sets as predicates on types, and then gave an outline
of the prove. The complete prove can be found in the library
{\tt well\_ordering} of HOL88.

Having {\tt well\_orderings} available gives us the tool for formulating
the transfinite-induction principle, which is a straightforward
generalization of the general induction tactic for naturals.
We showed the formulation of this induction tactic and mentioned the
associated tactics and rules, which can also be found in the
library {\tt well\_ordering}.

As an application of the library {\tt well\_ordering} and the library
{\tt quotient} we did a short outline of a theory about cardinals.
We showed how with the help of a quotient construct cardinals
can be defined: they are just classes of equipotent sets, where
as before sets are modeled as predicates on types. Set inclusion
is extended to a partial order on cardinals. To prove the fact this this
ordering is even linear, we need transfinite induction. Transfinite
induction is used to show that:
\begin{verse}
         if set $A$ can not be surjected onto set $B$,  \\
                  then\\
         there exists an embedding of $A$ into $B$.
\end{verse}
We closed the talk with saying that the full details can be found in the
library of HOL88, and that the work done showed that HOL can be used for
non trivial math.

A paper on well-orderings, cardinals, etc. in HOL will appear
shortly.


\talk{Abstract Theories for HOL}
     {Elsa Gunter\\
      {\em elsa@linc.cis.upenn.edu}\\
      Univeristy of Pennsylvania, USA}

In this talk an extension to the HOL theory mechanism is proposed,
namely that of abstract theories.  An abstract theory extends the
current notion of theory in HOL by allowing the user to abstract out
of a theory type variables, term variables and theorem assumptions.
Within a theory so bound, the bound type variables have the status (for
almost all purposes) of 0-ary type constructors, the bound term
variables have the status (again, for almost all purposes) of
monomorphic constants, and the bound theorem assumptions have the
status of axioms.  From outside the abstract theory these are bound
type variables, bound term variables and bound theorem assumptions,
all awaiting instantiation.  The goal of adding such a construct to
HOL would be to facilitate the natural development and use within HOL
of abstract mathematical theories  with repeated application.

The attributes of an abstract theory are to be:
\begin{itemize}
\item Type Binder (list of type variables)
\item Term Binder (list of term variables (with their types))
\item Theory Assumptions (list of pairs of strings and terms of type bool)
\item Parent Theories (list of theories and abstract theories)
\item Type Constructors
\item Constants
\item Axioms
\item Definitions
\item Theorems
\end{itemize}

The functions for interaction with abstract theories are to be as follows:

\begin{itemize}
\item
For declaring a new abstract theory:
\begin{verbatim}
  new_abstract_theory: string -> type list -> term list ->
                       (string # term) list -> void
\end{verbatim}
where
\begin{itemize}
\item
{\tt string} is the name of the abstract theory.
\item
{\tt type list} is a list of type variables to be treated (almost) as type
constants from within the abstract theory.
\item
{\tt term list} is a list of term variables to be treated (almost) as
monomorphic constants from within the abstract theory.  The types of the
term variables can only involve those variables found in the type list.
\item
{\tt (string \# term)} list is a list of labeled propositions which are
treated as axioms from within the theory.  The propositions may involve
those type variables and those free term variables appearing respectively
in either the type list or the term list.
\end{itemize}

\item
For extending or loading an abstract theory:
\begin{verbatim}
 extend_abstract_theory: string -> void

 load_abstract_theory: string -> void
\end{verbatim}
These commands allow for the addition of definitions, type definitions, and
theorems to previously created abstract theories.

\item
For closing an abstract theory:
\begin{verbatim}
 close_abstract_theory: void -> void
\end{verbatim}
This command returns HOL to previous concrete theory, and removes all ML
identifier bindings made while the abstract theory was open.

\item
For instantiating a theorem:
\begin{verbatim}
 extract_theorem: string -> string -> thm.
\end{verbatim}
where
\begin{itemize}
\item
The first {\tt string} is name of abstract theory.
\item
The second {\tt string} is name of theorem in abstract theory.
\item
The {\tt thm} returned is the result of discharging all the abstract theory
assumptions and generalizing all the the variables in the the term binder
for the theorem named.
\end{itemize}

\goodbreak
\item
For instantiating all of the abstract theories:
\begin{verbatim}
apply_abstract_theory: string -> string -> type list -> term list ->
                        thm list -> void
\end{verbatim}
This command incorporates into the current theory the results of
instantiating all of the theorems in the abstract theory with the
values given in type list and term list, provided that
\begin{itemize}
\item
The first {\tt string} is the name of the abstract theory.
\item
The second {\tt string} is a modifier to the names of the theorems from the
abstract theory.
\item
The {\tt type list} provides values to instantiate the type variables in the
type binder of the abstract theory.
\item
The {\tt term list} provides values of the appropriate instantiated type to
instantiate the term variables in the term binder.
\item
The {\tt thm list} provides theorems whose statements are the instantiated
versions of the abstract theory assumptions.
\end{itemize}
\end{itemize}

The following functions are used from within an abstract theory:
\begin{itemize}
\item
The function
\begin{verbatim}
  thy_asm: string -> thm.
\end{verbatim}
returns as a theorem one of the theory assumptions, provided that
{\tt string} is a label for the theory assumption.

\item
For introducing new type operator:
\begin{verbatim}
 abs_new_type_definition: (string # term) -> thm
\end{verbatim}
where
\begin{itemize}
\item
{\tt string} is the name of the new type operator to be introduced.
\item
{\tt term} is a predicate (containing no free variables) on an existing
type which defines a subset which, if non-empty, is to be in one-one
correspondence with the type being defined,
\end{itemize}
This function introduces a new type operator with arity the same as the
arity of the type on which P is a predicate (for this purpose the types and
terms in the binder of the theory are to be considered as free), ana which
asserts an axiom stating
\begin{verbatim}
 |- ?rep.(!y z. (rep y = rep z) = (y = z)) /\
         (!x. (P x \/ (x = @y. P y)) = (?z. x = rep z))
\end{verbatim}
which is returned as a theorem.

\item
In addition, we would have the usual functions for internal interaction
with concrete theories as currently existent, except that {\tt
new\_type\_definition} is prohibited, and {new\_definition} is required to
not define a constant whose name is that of a term in the theory binder.
Within {\tt new\_definition}, the terms of the theory binder are
disallowed.
\end{itemize}

In conclusion, the proposed notion of abstract theories provides a
modest, consistent extension to HOL, which we believe will provide a
convenient environment for developing and applying theories with
assumption.  In conjunction with the existing theory capacity of HOL,
they should play the same role for theorem proving in-the-large as
structures and functors (i.e. ``modules'') due in Standard ML.  Moreover,
they should remove {\em all} excuses for non-foundational uses of new-axiom.

\talk{Automating a Model Checker for \\
      Recursive Modal Assertions in HOL}
     {Sten Agerholm\\
      Henrik Skjoedt\\
      {\em dathsk@daimi.dk}\\
      Aarhus University, Denmark}

Transition systems are widely used in computer science, communication
engineering and circuit designing, among others, for modeling the
behavior of both hardware and software systems. For example, computer
scientists use transition systems in studying finite state concurrent
programs; the operational semantics of such can be given by finite labeled
transition systems.

Properties of states in finite labeled transition systems can be expressed
using recursive modal assertions. The assertion language we have
implemented in the HOL system includes recursive assertions defined as
maximum and minimum fixed points. This language is powerful and can be used
to express properties such as `always', `eventually' and `deadlock', among
others. In order to have the recursive assertions in HOL we proved a
special version of Tarski's theorem which provides a way of defining and
reasoning about maximum and minimum fixed points.

In general it can be quite hard work to prove by hand whether or not a
state satisfies an assertion, and it is therefore desirable to have a way of
checking whether assertions are true or false on states mechanically. We
have implemented an algorithm which proves theorems in HOL, automatically,
stating whether a state satisfies an assertion or not.

The model checking system consists of various tools which reduce the
workload of the user to a minimum, for example the system does all the
theorem proving needed. In addition, it is made flexible with respect to
efficiency optimizations.

\talk{Modeling of Causal and\\
      Diagnostic Reasoning}
     {Stig Andur Pedersen\\
      {\em sap@meza.ruc.dk}\\
      Roskilde University Center, Denmark}
Clinical reasoning is rendered difficult by the logical complexity of
causal explanations of various diseases. A logical analysis of causal
structures involved in clinical reasoning is presented.  Disease causes are
chosen as non-redundant parts of causal complexes. A causal complex is a
description of a situation which by necessity leads to the disease.
Usually causal complexes are identified by listing relatively few non-
redundant components of it. It is argued that counterfactual conditionals
(i.e., conditionals with false antecedents) play a decisive role during the
construction and analysis of causal complexes and that we would gain a
better understanding of causal reasoning by developing formal analyses of
counterfactuals involved in such reasoning. One such formal analysis is
sketched. We believe that HOL will be a suitable tool for implementing and
further analyzing this logical system.


\end{document}





