Rigorous Timing, Static occam , and Classic CSP: Formal - - PowerPoint PPT Presentation
Rigorous Timing, Static occam , and Classic CSP: Formal - - PowerPoint PPT Presentation
Rigorous Timing, Static occam , and Classic CSP: Formal Verification for IoT A Fringe Presentation for CPA2017 by Lawrence J. Dickson Space Sciences Corporation Lemitar, NM, USA Jeremy M. R. Martin Lloyds London, UK Ground Truth
Ground Truth (Reality Check) for CSP
- ccam compiled and run on classic Transputers, e.g. T425, is ideal Ground
Truth for Formal Verification using CSP and other tools (such as EDA):
- Completely general and capable of all* computing tasks
- Parallel and IO supported by language primitives
- No software kernel or operating system needed#
- No communicating process queue#
- No message queue#
- No message buffer#
- Communicates directly with all peripherals (TRAMs)
- Prompt, non-polled IO including select (ALT)
- Static resource allocation
- Finite resource allocation
- Language primitives supported by formally verifiable assembly coded state
machines
- Hardware/software equivalence^
*Autonomous vehicle demonstrated on Autobahn in 1993 References: INMOS: Transputer Databook, Second Edition, 1989, page 268-269# et al INMOS: Transputer Instruction Set, a Compiler Writer's Guide, Prentice Hall, 1988 INMOS: occam 2 Reference Manual, Prentice Hall, 1988, page 71^ et al
Ground Truth CSP Characteristics
Several characteristics of the Ground Truth are applied to the subset of CSP that is considered, while one theoretical feature is added to the Transputer characteristics to aid the proofs:
- All processes and events are triple disjoint (no event synchronizes more
than two processes).
It was noted at CPA2016 that synchronization of more than two processes, such as barriers, can be emulated by sets of triple disjoint synchronizations.
- All process counts and resources are finite.
This restriction is required for realism. This restriction is needed to avoid effective divergence.
- All resources are statically allocated.
- ALT select is allowed for inputs only.
These two occam characteristics are required for Hardware-Software Equivalence.
- High priority Transputer hardware responses are used.
- Randomization of data and of ALT priority can be imposed.
These last two are required for the greatest generality of IoT proofs and divergence testing. Practical use of low priority is a separate topic - optimization of deep stack computing. Only the randomization is not found in classic hardware, though it can be programmed. Reference: Jeremy Martin: The Design and Construction of Deadlock-Free Concurrent Systems, PhD Thesis, University of Buckingham, 1996
Ground Truth Use is Bottom-Up
Usability of CSP constructs, such as hiding, is explored by exhaustive examination of actual occam programs compiled for the Transputer.
- Key tool for those lacking hardware: Gavin Crate’s Transputer Emulator.
- Simple test programs: FIFO.occ and rawFIFO.occ (source available)
References: Gavin Crate: Transputer Emulator: https://sites.google.com/site/transputeremulator/Home/installation-instructions Lawrence Dickson: Crawl-Space Computing, LAZM, 2014, page 111-120 et al
Cycle-counted Flowchart FIFO on 20 MHz T425(s)
CSP Expression for Finite FIFO
Variables: Structure and Content
Algorithmic SKIP is quickly-executing and correctly-Terminating code that adjusts structure and content variables
- Formally verifiable by EDA techniques
- No waits or communications
- Example is occam function or value process
Structure variables: value is tracked and tested in CSP or flowchart
- Resource requirements and current value are known
- Can affect program flow deterministically
- Usually bounded integer or Boolean values
Content variables: position and state are tracked in CSP or flowchart
- Resource requirements and identity are known
- Can affect program flow only non-deterministically
- Can be anything, even non-digital, like marbles or barrels of oil
Example: algorithmic SKIP after communication b in store affects structure variables fl (current count of content packets) and indout (location of head of content queue):
SEQ IF indout < nm2 indout := indout + 1 TRUE indout := 0 fl := fl - 1
Flowchart of store
Covering-with-Boundary (CwB) plus Start and Direction
- CwB # is like parking garage
- Any possible timeline of
the program can be mapped continuously so as to follow the arrows on the Total Flowchart *
- Every continuous path that
follows the arrows on the Total Flowchart is a possible timeline of the program * # Mathematical definition exists
- Content height maps
(as in Slide 4) are made by integrating these timelines *
- Boundary (finiteness)
forces bounded delay and prevents effective divergence * * Mathematical proofs exist
Basic Building Blocks
Unit Sweep is a maximal block of Transputer assembly code, each instruction of which executes immediately after the previous, and no instruction of which except the last can deschedule (block).
- It therefore ends with termination, communication, future time wait, or ALT on comms and future times
- “Sweep-past” instructions which cannot block include past time wait, SKIP ALT, and past timer ALT
- Unit Sweeps with “sweep-past” instructions in their interior are “long units,” can cause FV problems
- The “Terminus,” or last instruction, of the Unit Sweep CAN deschedule but possibly may not do so
Communication or “Comm” is an actively proceeding software (memcpy)
- r hardware (link) data transmission between processes.
- It does not start until both endpoint processes are ready
- The first process executes a communication setup and then may block for a time
- The second process’s comm setup is followed without delay by the comm
- Hardware (link) data transmission uses Direct Memory Access (DMA) with process descheduled
Spin Unit refers either to a Unit Sweep or to a Soft Comm.
- While running, it uses all the Transputer uniprocessor’s cycles, except for any stolen by link DMA
- It is assigned to a particular process and shares no cycles with other processes
- A hardware (link) comm is not a Spin Unit because it can run in parallel with unrelated processes
Active Sweep refers to the time during which a process is Active, starting with its being (re)scheduled, through reaching the front of the process queue and executing a Unit Sweep, through possible other Spin Units till it terminates or deschedules.
- This is “Active” as defined in Transputer Databook, p 268
- Time spent in the process queue is called the “Pre-Sweep”
Progress and the Straight Sweep
Progress of a process continues as long as it is in an Active Sweep or is communicating.
- Progress of a process continues during its Link Comm, or during its Soft Comm when that is executed
by its comm partner, even though those are not part of the process’s Active Sweep.
- Progress includes the Pre-Sweep of the process’s Active Sweep, even though the (re)scheduled
process is not then executing.
- Progress does NOT include the time after the first comm setup, after an ALTWT, or after a future timer
wait setup, when the process is descheduled and not yet rescheduled.
Straight Sweep of a process or of a set of processes is a continuous, uninterrupted time interval during which at least one of the processes in the set is making Progress.
- Equivalently, Straight Sweep is a continuous, uninterrupted time interval during which at least one of
the processes is in the process queue, is executing, or is communicating.
Leadup of a process to a possibly descheduling event is the Pre-Sweep and the Unit Sweep of that process immediately before that event, which is the Terminus of the Unit Sweep.
- The process may or may not deschedule at the Terminus to which the Leadup leads.
- Dual Leadup Time is a time shared by the leadups to two related events (such as the two ends of a
comm, or an ALT and its winning output) in separate processes.
- Lone Leadup is the other case, when the leadups to the two related events do not share any time.
Lone Leadup Soft Comm
Pre-Sweep: Why is it Progress?
Because of Finiteness, a known small number of processes, denoted by tot, share this high-priority uniprocessor. At most tot-1 preceding processes, including one current when the Pre-Sweeping process is (re)scheduled, can execute during the Pre-Sweep. When a preceding process executes, and before it deschedules, its first Unit Sweep may be followed by a number of Spin Units due to ready ALTs and
- comms. Each of these requires a descheduled process be rescheduled after
the Pre-Sweeping process. All but the last of the preceding processes, when itself descheduled, can perform this function for one later preceding process in the worst case. It follows (proof available) that for tot>1, the Pre-Sweeping period contains between 0 and 3(tot-2)+1 Unit Sweeps, and between 0 and tot-2 Soft Comms, executed in immediate succession. The worst case is all ALTs. On average, then, if each Spin Unit takes about the same time, the Pre- Sweeps slow down the execution of the Pre-Sweeping process by about a factor of tot. This is just what is expected in a multitasking system. We accept this slowdown and spread Progress across the whole Active Sweep.
HSE Theorems
Hardware-Software Equivalence (or HSE) means communicating processes behave the same whether they are on the same Transputer (Soft Comms) or on different Transputers (Link Comms). Internally, this is implied by static resource allocation. Since the only external activity of any running process is communication, the proof of HSE is completed by the following: Comms Equivalence Theorem: Given the same time ordering of Unit Sweep Termini and Comms endpoints, the Progress times of any process, as functions of these endpoints, are independent of whether the Comms are Soft Comms or Link Comms. (Proof available)
Sketch of proof: Six cases are dealt with (see next slide): Unconditional comms (input first and output first), and ALT wins (early winner and three late winner cases). Link Comm setup for input is setting link to immediately acknowledge; Link Comm setup for output is sending one byte. Progress continues after Soft Comm as if rescheduled/executed immediately; Link Comm uses process queue. Note: Timings may be very different. Typically, Link Comms are much slower. But this is mere jostling
- f Progress speeds, not an essential difference.
Straight Sweep Equivalence Corollary: Under the same assumptions, Straight Sweeps are independent of whether the processes are on the same
- r different hardware.
Proof: Definition of Straight Sweep means this Corollary follows from applying the above Theorem to each process in the set.
Straight Sweep Theorems
Shared Event means an event completed by the action of two processes. It may be either an Unconditional (non-ALT) Communication or an ALT that is won by a comm together with the winning comm. It is associated with two Termini, one for each process.
In rare ALT cases, a third process or event may slightly beat the winner and trigger the ALT (the Anomalous Cases). We deal with this in our results. It makes no significant difference.
Early Sweep means that, of the Leadups leading to the associated Termini, the earlier starting is part of a Straight Sweep across the shared event. Late Sweep means under the same assumptions that the later starting is part of the Straight Sweep. Normal Sweep is an Early Sweep if there is a Dual Leadup Time, and a Late Sweep if there is a Lone Leadup. Unconditional Comm Straight Sweep Theorem: In an Unconditional Comm, the Straight Sweep of the communicating processes includes a Normal Sweep across the Comm to a time shared by both processes after the Comm. (Proof available) ALT Straight Sweep Theorem: The Straight Sweep of the ALTing and the winner process extends from before or at the end of the ALTWT to a time shared by both processes after the winning Comm. (Proof available)
It is a Normal Sweep except in the Anomalous Cases. Even these include the end of the ALTWT.
Tight Sequence Sweep
Tight Sequence of Comms means a sequence of Unit Sweeps in each of two processes, each sequence being of the same count, where the Terminus
- f each Unit Sweep in one process is a Comm with the Terminus of the
corresponding Unit Sweep in the other process. Chain of Comms Corollary: If a Straight Sweep of two processes extends through the first Comm of a Tight Sequence of Comms of those processes, it continues through all the other Comms of the Tight Sequence to a time shared by both processes after the last Comm.
Proof: Induction on the Unconditional Comm Straight Sweep Theorem, since it is known that the Straight Sweep extends to a time shared by both processes after the first Comm. Note: This works if the first Comm of the Sequence is an ALT winner, in which case the ALT Straight Sweep Theorem implies the Straight Sweep extends back to the end of the ALTWT.
Lone Leadup ALT with Tight Sequence of 2 Comms, Straight Sweeps
Straight Sweep Theorems Applied
These are minimum Straight Sweeps implied by the Theorems, taking communicating processes pairwise. In some cases, the gap between a Terminus and the next Start Sweep may be a real pause. In other cases, the Straight Sweep continues across it. FIFO Part of rawFIFO
Note: Each buffer[k] rotated 180 degrees from neighbor for clarity.
Internally Active (Unstable) States
In the context of these flow drawings, an Internally Active (Trickling or Unstable*) state is one, like either of the above, in which there is empty space below filled space (called gaps) in the direction of content flow.
- Jostling means changing the timing of external communications with the
program.
- It is possible for jostling to make a correctly running program stay internally
active forever! (Note: these are real, not idealized, FIFO programs.)
- Robust Formal Verification must prove the program works correctly and
promptly under any possible jostling. Our Ground Truth approach does this.
Reference: A.W. Roscoe: The Theory and Practice of Concurrency, Prentice-Hall, 2005, page 169*
Mathematical Proofs Exist for FV of Jostling Independence
For both FIFO and rawFIFO Ground Truth runs, under any condition of jostling, the following are true (proofs available):
- Straight Sweep (Progress without breaks) of the set of all processes
continues as long as the program is Internally Active.
- If Internally Active, there is a fixed, known, short length of time after which
the program either ceases being Internally Active or relaxes by at least one Unit of Content Height.
- Because of Finiteness, this implies that from the point of view of any Unit of
Content, the action of the program is verified to be equivalent to CSP, plus a delay less than a fixed, known, short time.
- The same FV approach will be applicable to more general IoT programs.
Explanation of bolded terms (exact definitions are available with proofs): Unit of Content is a single content variable retaining its identity passing through the program. Unit of Content Height is a single space in which the Unit of Content may rest during its path. External Progress is communication of a Unit of Content via an external CSP event. Relaxation is a significant move of internal content in the direction of External Progress (output). Note: Content need not be digital, but may be something like marbles or barrels of oil. This is IoT!
- ccam-CSP correspondence
Crosslinks (or Crossties) are lines which show the shared events of the CSP traces of two (or more) Ground Truth processes. These resemble crosslinks in chemistry polymers or proteins, hence the name (which does NOT imply use of Link Comms). Crosslinks are often hidden in CSP work.
Merging crosslinked processes in CSP involves the interleaving (|||) operator, as long as it is understood that the timing (e.g. of c with respect to ddd) may be ill-defined or “none of the above.” Effective divergence is the possibility of an unbounded number of non-Crosslink events happening when a crosslink is ready to fire. It is bad because Crosslinks are supposed to fire promptly (Roscoe, page 169), and if they do not, Relaxation cannot happen despite unbounded Progress. Example: If an ALT replaces PRI ALT in FIFO, and the finiteness condition (Boolean guard) is removed, an unbounded number of d’s in sequence when a is ready to fire becomes possible.
Conclusions
- Straight Sweep analysis is the key to mapping Ground Truth to CSP.
Each Unit Sweep, Pre-Sweep, and Comm takes known, finite, bounded time. Straight Sweep continues as long as program is Internally Active. A finite bounded number of Unit Sweeps and Comms leads to Stable State or unit Relaxation. A finite bounded number of unit Relaxations leads to External Progress.
- We proved all of the above for FIFO and rawFIFO.
- We were unable to apply CSP “hiding” to a and b separately in FIFO.
We were unable to apply LTS > PNFTS > NFTS to FIFO with “hiding”. Author Dickson could find no authoritative documentation on how to do this. The interaction with the “timeout” or “sliding choice” operator was especially unclear.
- Instead of hiding, analyzing Ground Truth Straight Sweeps showed both
FIFO and rawFIFO to behave externally equivalently to with a known, bounded delay.
- Either side of the [] in this CSP expression can be preferred depending
- n the “Trickling” internal state!
Hint: make the internal Comms a and b slow Link, the external Comms c and d fast Soft Comms. The delay or “favoritism” is always by a finite, bounded time. No permanent rejection as in “sliding choice” is seen.
Questions and Future Plans
QUESTIONS
- Someone please do the missing CSP, and explain the rules?
Especially needed are those relating to hiding and Timeout/Sliding Choice. We will contribute the comparison to Ground Truth!
- Classic Transputer question: how does Link cycle-stealing work?
We have assumed, based on Crowell & Elzenga, that it is super-high priority.
- Where is the occam language in the Chomsky hierarchy?
We know it is not Turing complete - but neither is anything else (infinite memory required). Linear bounded automaton? Finite automaton? Surely someone already looked at this . . .
- Why does FDR go with functional language / no assignments?
Structure Variables in Ground Truth seem much more natural. Is there an equivalent technique in FDR? Can FDR do FIFO as defined here, including the bounding Booleans?
- Has SAT or any other CSP technique progressed into a tool like FDR?
FUTURE PLANS
- Expand techniques to include nontrivial Algorithmic SKIP.
Operations will include compression, sorting, encryption, etc. Operations will be applicable both to Structure Variables and Content Variables.
- Do bigger cases and real IoT.
For testing, a real Transputer system or exact emulator will be desirable!
- Integrate our FV techniques with real FDR (or SAT?) and EDA.