summaryrefslogtreecommitdiffstats
path: root/archive
diff options
context:
space:
mode:
authorYann Herklotz <git@yannherklotz.com>2020-11-19 10:01:56 +0000
committerYann Herklotz <git@yannherklotz.com>2020-11-19 10:01:56 +0000
commitce1b8290fbacf709a1a5320c11e9d2157dadcc8f (patch)
tree8449fe4bc0d58102fa097357eb6575109aa47fdd /archive
parent8745901dc8b53042cc004049b2dfc49d0f7651fd (diff)
downloadoopsla21_fvhls-ce1b8290fbacf709a1a5320c11e9d2157dadcc8f.tar.gz
oopsla21_fvhls-ce1b8290fbacf709a1a5320c11e9d2157dadcc8f.zip
Push
Diffstat (limited to 'archive')
-rw-r--r--archive/verilog.tex5
1 files changed, 5 insertions, 0 deletions
diff --git a/archive/verilog.tex b/archive/verilog.tex
index 5fc8999..a363596 100644
--- a/archive/verilog.tex
+++ b/archive/verilog.tex
@@ -1,3 +1,8 @@
+%\JW{I think most of the following paragraph could be chopped. We've already mentioned that we're only targeting a small fragment of Verilog, so we could mention at that point that in the fragment we target there is no discrepancy between the simulation behaviour and the synthesis behaviour. I don't know how important it is to talk about the details of evaluation order here -- does the reader really need to be aware of this in order to understand your work?}
+When targeting a hardware description language such as Verilog, it is important to be consistent between simulating the hardware and the behaviour of the synthesised result on actual hardware. In the target Verilog semantics, only clocked \alwaysblock{}s are supported as these ensure that there are not mismatches between simulation and synthesis, as combinational \alwaysblock{}s that trigger on any change of an internal signal may behave differently in simulation or synthesis based on the order of operations. This limitation in the semantics therefore helps keep the Verilog correct and consistent. In addition to that, only nonblocking assignment is used in signals that are used in multiple \alwaysblock{}, which stops any race conditions from occurring as all the signal updates happen deterministically. \NR{So the semantics allows multiple drivers then?} Finally, a specific order of evaluation for the \alwaysblock{} is chosen, and because of the limitations listed before, choosing an order is guaranteed to have the same behaviour as executing the \alwaysblock{} in any order.\NR{Order is not guaranteed if we have multiple drivers.}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
Using these constructs it is therefore possible to describe how hardware functions, where always blocks that are triggered by a clock periodically get translated into flip-flops and always blocks triggered by changes in any internal signals are translated into combinational logic.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%