Introduction to Design Languages Last Time This Time Syntax, Semantics, and Model Syntax Computational Model

Home , Verilog

Last Time

Introduction to Design Introduction to the class Languages

Embedded systems

Prof. Stephen A. Edwards Role of languages: shape solutions

Project proposals due September 26

• Do you know what you’re doing? Lobby, Paris Opera House

This Time Syntax, Semantics, and Model

General ideas behind languages Marionette model

Syntax, Semantics, and Models of Computation

Specification versus Modeling You control the syntax

Concurrency: Two things at once

Nondeterminsm: Unpredictability The semantics connect the

syntax to the model Types of communication: Memory, broadcasting

Hierarchy You ultimately affect a model

Syntax Computational Model

Formally: What a string ultimately affects

Does not need to be unique Language: infinite set of strings Babbage’s from an alphabet Difference Engine Rosetta stone Model Alphabet • DNA Proteins suspended in water • DNA {A T G C} • Student Transcripts Your knowledge The admiration of others • Student Transcripts {w1007-02 w1009-01 w4559-02 …}

• English Natural language understanding • English {aardvark abacus abalone …}

• Verilog Discrete event simulator • Verilog {always module …} Netlist of gates and flip-flops

Semantics Defining Syntax

How to interpret strings in the model Generally done with a grammar

“When I use a Also not necessarily unique word, it means Recursively-defined rules for constructing valid just what I choose it to sentences mean - neither more nor less.” “Backus-Naur Form” Semantics • DNA [[ AGA ]] = Arginine [[ TAG ]] = STOP expr :: literal • Student Transcripts [[ w1007-02 ]] = Java | expr + expr | expr * expr • English [[ Look out! ]] = I’m in danger

• Verilog [[ always @posedge clk]] = FF Not a focus of this class

Defining Semantics Specification and Modeling

Operational Semantics How do you want to use the program? • Abstract machine (memory, program counter) •

Each statement advance machine state Specification languages say “build this, • Closest to implementation please”

Denotational Semantics Modeling languages allow you to • Context domain (memory state) describe something that does or • Answer domain (result, I/O behavior) will exist • Meaning function: Program → (Context → Answer)

• Much more mathematical

• Able to deal with recursion and self-reference Distinction a function of the model and the language’s semantics Copernican Model of the Solar System Copyright © 2001 Stephen A. Edwards All rights reserved Copyright © 2001 Stephen A. Edwards All rights reserved

Specification Versus Modeling Gratuitous Picture

C is a specification language Chartres Cathedral, • Semantics very operational France • Clear how the language is to be translated into assembly language Façade a renovation of and earlier Romanesque Verilog is a modeling language church (note rounded • Semantics suggestive of a simulation procedure windows)

• Good for building a model that captures digital Right tower considered hardware behavior (delays, race conditions, unknown the architectural gem values) • Starts complicated • Not as good for specification: how do you build something with a specific delay? • Ends simple, to-the-point

Concurrency The Challenge of Concurrency

Why bother? Synchronization

Harder model to program How to arbitrate access to shared resources • Memory

• I/O ports

Real world is concurrent • Actuators

Good controller architecture: concurrently-running

process controlling each independent system Different approaches to concurrency a focus of the component course E.g., process for right brake, process for left brake, process for brake pedal

Approaches to Concurrency Communication and Concurrency

Shared memory / “Every man for himself” Idea: let processes run asynchronously and only • Adopted by Java, other software languages force them to synchronize when they communicate

• Everything’s shared, nothing synchronized by default

• Synchronization through locks/monitors/semaphores CAR Hoare’s Communicating Sequential Processes • Most flexible • • Easy to get wrong Rendezvous-style communication: • Processes that wish to communicate both wait until the Synchronous other is ready to send/receive

• Global clock regulates passage of time

• Very robust in the presence of timing uncertainty Kahn Process Networks (later in the course) • Proven very successful for hardware design • Communicate through channels • Synchronization overhead often onerous • Writer always continues • Reader waits until data has arrived

Nondeterminism Nondeterministic Is Not Random

Does a program mean exactly one thing? Deterministic: 1+1 = 2 always

“Increment Example from C: a, return Random: 1+1 = 2 50% of the time, 3 otherwise result”

printf(“%d %d %d”, ++a, ++a, ++a); Nondeterministic: 1+1 = 2 or 3, but I’m not telling

The nondeterministic behavior could Argument evaluation order is undefined look determinstic, random, or Program behavior subject to compiler interpretation something worse

Are you sure your program does what you think?

Nondeterminism Is Awful Example From Verilog

Much harder to be sure your specification or model is Concurrent procedure execution order undefined correct always @(posedge clk) $write(“a”) always @(posedge clk) $write(“b”) True nondeterminstic language difficult to simulate

• Should produce “any of these” results

• Must maintain all possible outcomes, which grows First implementation moved procedures between two

exponentially push-down stacks. Result:

Idiosyncrasies of a particular implementation of a a b b a a b b a a b b a nondeterministic language often become the de facto standard Later simulators had to match now-expected behavior

Nondeterminism Is Great Communication

True nondeterministic specification often Memory exponentially smaller than deterministic counterpart • Value written to location

Implicit “all possible states” representation • Value stays until written again • Value can be read zero or more times after write E.g., nondeterministic finite automata for matching • No synchronization regular expressions

If system itself is truly nondeterministic, shouldn’t its model also be? Buffer

• Value written to buffer Can be used to expose design errors

• Value held until read

More flexible: only there if you want to use it • Values read back in order they were written

Correctness remains more elusive

Communication Hierarchy

Wires Most languages have ability to create pieces and • May or may not have explicit write operation assemble them

• Value immediately seen by all readers Advantage: Information hiding • More like a system of equations than a sequence of • User does not know details of a piece operations • Easier to change implementation of piece without breaking whole system • Easier to get small piece right • Facilitates abstraction: easier to understand the whole

Advantage: Reuse • Pieces less application-specific; can be used elsewhere

Summary Summary

Languages have syntax, semantics, and model Concurrency useful for handling real world

Syntax usually defined with grammar Synchronization big challenge

Semantics can be defined operationally or • Shared memory and locks denotationally • Synchrony • Rendezvous synchronization Many possible models: A focus of this class

• Buffer synchronization

You ask for something with a specification language Nondeterminism

You describe something that does or will exist with a • Good for certain models modeling language • Can be very succinct • Makes specification hard • Makes verification harder

Summary

Communication techniques • Memory • Buffered • Wired

Hierarchy for information hiding