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 Lloyd’s London, UK

Ground Truth (Reality Check) for CSP occam 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 • CwB # is like parking garage • Content height maps • Any possible timeline of (as in Slide 4) are the program can be mapped made by integrating continuously so as to follow these timelines * • Boundary (finiteness) the arrows on the Total Flowchart * forces bounded delay • Every continuous path that and prevents follows the arrows on the effective divergence * Total Flowchart is a possible timeline of the program * # Mathematical * Mathematical definition exists proofs exist Covering-with-Boundary (CwB) plus Start and Direction

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) or 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 Lone Leadup Soft Comm 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.

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.