From 0f26740e1474d6b1bdf1b2a2d6ea9a20f8fa2eee Mon Sep 17 00:00:00 2001 From: John Wickerson Date: Tue, 17 Nov 2020 20:44:25 +0000 Subject: Update on Overleaf. --- verilog.tex | 1 - 1 file changed, 1 deletion(-) (limited to 'verilog.tex') diff --git a/verilog.tex b/verilog.tex index 355b91c..8315062 100644 --- a/verilog.tex +++ b/verilog.tex @@ -13,7 +13,6 @@ The semantics of Verilog differs from regular programming languages, as it is us A module can contain multiple always blocks, all of which run in parallel. These always blocks further contain statements such as if-statements or assignments to variables. Each always block also contains a list of events at which it should trigger, which could either contain signals that are assigned to other signals in that always block, or a different signal such as a clock which will trigger the always block periodically, only the latter are actually supported in our target semantics. \JW{That sentence is a bit wordy. Can you just say something like: `We support only \emph{synchronous} logic, which means that the always block is triggered on (and only on) the rising edge of a clock signal.'?} \NR{We should mention that variables cannot be driven by multiple \alwaysblock{}s, since one might get confused with data races when relating to concurrent processes in software.} - As hardware designs normally describe events that will be executed periodically for an infinite amount of time, the top-level of the semantics is best described using small-step semantics, whereas the execution of one small step is described using big-step semantics. An example of a rule in the semantics for executing an always block is shown below, where $\Sigma$ is the state of the registers in the module and $s$ is the statement inside the always block: \begin{equation*} -- cgit