summaryrefslogtreecommitdiffstats
path: root/verilog.tex
diff options
context:
space:
mode:
authorYann Herklotz <git@yannherklotz.com>2021-08-02 00:26:15 +0200
committerYann Herklotz <git@yannherklotz.com>2021-08-02 00:26:15 +0200
commita89ffd74a82b225be85627926407ed9a05aefc5e (patch)
treee4f37b5c5dec7331323992477e9fe31f01055337 /verilog.tex
parent5ba8d98c98ca17b543f212486a5a4e2e7b91ca84 (diff)
downloadoopsla21_fvhls-a89ffd74a82b225be85627926407ed9a05aefc5e.tar.gz
oopsla21_fvhls-a89ffd74a82b225be85627926407ed9a05aefc5e.zip
Clear up the Introduction and Algorithm section
Diffstat (limited to 'verilog.tex')
-rw-r--r--verilog.tex2
1 files changed, 1 insertions, 1 deletions
diff --git a/verilog.tex b/verilog.tex
index 2c474e6..c169aaf 100644
--- a/verilog.tex
+++ b/verilog.tex
@@ -9,7 +9,7 @@ This semantics is quite practical as it is restricted to a small subset of Veril
The semantics of Verilog differs from regular programming languages, as it is used to describe hardware directly, which is inherently parallel, rather than an algorithm, which is usually sequential. The main construct in Verilog is the \alwaysblock{}.
A module can contain multiple \alwaysblock{}s, all of which run in parallel. These \alwaysblock{}s further contain statements such as if-statements or assignments to variables. We support only \emph{synchronous} logic, which means that the \alwaysblock{} is triggered on (and only on) the rising or falling 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.} \JW{Given the recent discussion on Teams, it seems to me that we perhaps don't need to mention here what happens if a variable is driven multiple times per clock cycle, especially since Vericert isn't ever going to do that.}
+%\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.} \JW{Given the recent discussion on Teams, it seems to me that we perhaps don't need to mention here what happens if a variable is driven multiple times per clock cycle, especially since \vericert{} isn't ever going to do that.}
The semantics combines the big-step and small-step styles. The overall execution of the hardware is described using a small-step semantics, with one small step per clock cycle; this is appropriate because hardware is routinely designed to run for an unlimited number of clock cycles and the big-step style is ill-suited to describing infinite executions. Then, within each clock cycle, a big-step semantics is used to execute all the statements.
An example of a rule for executing an \alwaysblock{} that is triggered at the positive edge of the clock is shown below, where $\Sigma$ is the state of the registers in the module and $s$ is the statement inside the \alwaysblock{}: