Abstract. The parameterized verification of concurrent algorithms and protocols has been addressed by a variety of recent methods. Experience shows that there is a trade-off between techniques which are widely applicable but depend on nontrivial human guidance, and fully automated approaches which are tailored for narrow classes of applications. In this spectrum, we propose a new framework based on environment abstraction which exhibits a large degree of automation and can be easily adjusted to different fields of application. Our approach is based on two insights: First, we argue that natural abstractions for concurrent software are derived from the "Ptolemaic" perspective of a human engineer who focuses on a single reference process. For this class of abstractions, we demonstrate soundness of abstraction under very general assumptions. Second, most protocols in given a class of protocols -for instance, cache coherence protocols and mutual exclusion protocols -can be modeled by small sets of high level compound statements. These two insights allow to us efficiently build precise abstract models for given protocols which can then be model checked. We demonstrate the power of our method by applying it to various well known classes of protocols.

No abstract

We cannot apply PODC methodologies to industrial designs without formal models of the designs. Formal models are usually hard to find. We have built a tool that extracts formal models directly from design documents. Protocol verification consists of three easy steps: find a protocol, model the protocol, and verify the protocol. Go ahead, laugh at the joke, but it is not much of an exaggeration to say that getting the protocol model has traditionally been the hardest of the three steps at companies like Digital, Compaq, HP, and Intel. We could talk for an hour on the reasons, but the bottom line is that the tools we build assume the existence of a model, and we think very little about where these models come from, yet our tools will never gain widespread use if we don't address the problem of building the model of an industrial design.Industry often uses the "Superman approach" to model building. (Superman is a fictional comic book superhero once popular in America.) In this approach, a single verification expert joins a group (usually late), spends months learning the protocol, building a model, changing the model as the design changes, and only then gets to do any verification. This is not the right approach. For one thing, it doesn't scale well (there aren't many supermen), it burns out the supermen we have (leaving even fewer supermen), and it never gets past the "technology demonstration" phase ("That was great, Superman, you wanna do it for me again?").While not building models, designers are producing a number of design artifacts with significant technical content: microarchitecture specification documents containing state transition tables, block diagrams, pipeline diagrams, timing diagrams, message flows, etc. We should be able to use this information to build the formal model we need from what the designers are already willing to produce. And once the model is built, it could be highly attractive to the designers to include it in their documents, leading to more precise, less ambiguous design documents. This is our dream:• A front-end that can extract from a specification document the transition tables, block diagrams, pipeline diagrams, etc, and build a formal protocol model.• A back-end that can take this protocol model and produce input to formal verification tools, and produce reference models for traditional simulation.What we have done is build a tool that mechanically extracts tabular information from a design document -state transition tables, state definitions, type definitions, etc -and builds a mathematical protocol model, and from that model generates a Murphi model [3] for model checking. We have applied this approach to a cache coherence protocol that is unusual (caches are maintained on doubly-linked lists) and complex (37 cache states) called SIMPL. We are not the first to do table-based design [1, 2, 4], but it is one thing to ask designers to write tables in a style intended for formal analysis, and it is another to take tables as they are written by the designers and make formal sense ...