<?xml version="1.0" encoding="utf-8"?> 
<!DOCTYPE zprava SYSTEM "techrep.dtd" >
<zprava cislo="4/2004" jazyk="en">  
<!-- opravit podle aktualnich grantu!!! -->
<nazev>How to Formalize FPGA Hardware Design
    <footnote>This work is supported by the FP5 project No. IST-2001-32603,
    the CESNET activity Programmable hardware, and the GACR grant
    No. 201/03/0509.</footnote> 
</nazev>
<autor>Jan~Holeček, Tomáš~Kratochvíla, Vojtěch Řehák, David~Šafránek, and Pavel~Šimeček</autor>
<datum>October 6, 2004</datum> 


<h1>Abstract</h1>
<p>
In this report, a formal view of an FPGA hardware design is presented. An
approach of how elementary FPGA design entities can be modeled in terms of
Kripke structures is presented here. The report is also focused on capturing
the problems of modeling synchronous parts of hardware design together with its asynchronous parts.
</p>

<h1>Introduction</h1>

<p>
In formal verification, abstraction plays a crucial role due to the state <i>explosion problem</i>~<cite href="Bar02"></cite>. Abstraction is related mostly to simplification of specification of complex system behavior. The most crucial fact concerning abstraction is that of ensuring the abstraction to be correct and still containing the critical parts of the system under verification. 
</p>

<p>
In the following sections, ways of how to abstract away from complex
physical properties of an FPGA hardware design~<cite href="FPGA"></cite> are
discussed. We focus on the approach of modeling basic elements of the FPGA-based hardware design in the form of a <i>Kripke structure</i>~<cite
href="MC"></cite>. Moreover, the problems of capturing both synchronous and
asynchronous parts of a hardware design together in one model are also solved. 
</p>

<h1>Principal Entities of Hardware Design</h1>

<p>
The logical structure of a typical hardware design specified using the
state-of-the-art HDL languages such as VHDL~<cite href="VHDL"></cite> or Verilog~<cite href="Ver"></cite> is modular. It is
composed from small units (<i>entities</i>) interconnected together by wires
along which <i>events</i> representing changes of logical values flow. Each
entity has an interface which is given by a set of <i>input signals</i> and
<i>output signals</i>. Events occurring in input signals control the behavior
of the entity. Values of output signals are combined from values of input
signals with respect to the current state of the entity.
</p> 

<p>
Following the physical aspects of hardware, changes of values of signals
occur with some infinitesimal delay, so called <i>delta delay</i>~<cite href="VHDL"></cite>. We have
to point out that we abstract from this delay whenever it does not affect
the properties we verify. We call this kind of abstraction the <i>zero
delay abstraction</i>. This abstraction relies on the same idea as the synchronous hypothesis known from synchronous languages~<cite href="Esterel"></cite>.  As this abstraction is very strict and can hide some very critical aspects of hardware design, we will discuss it in details later on in this report.
</p>

<p>
From the behavioral point of view, we distinguish two basic elements of
hardware design -- <i>combinational logic elements</i> (and-gates,
or-gates,...) and <i>sequential logic elements</i> (latches and
flip-flops).  Values of signals in combinational logic elements can be
sensed only in the moment in which they occur. In particular, the
combinational logic elements instantaneously transform values from input
signals to values of output signals. In contrary, the purpose of a
sequential logic element is to save a value of a signal over time. We call
this kind of behavior <i>registered behavior</i> with respect to the fact
that the sequential logic is composed from registers and other
memory elements.
</p>

<p>
The crucial observation of the registered behavior is that an assignment of
a value to a registered signal is always put in the context of a conditional
specification. In other words, assignments to registered signals are
guarded. If a particular guarding condition does not hold, the value of the
relevant registered signal remains the same. This conservative behavior
takes its place here even if the value of the input signal, which has to be
stored, has been possibly changed. Moreover, assigning to a registered
signal may be controlled also by events occurring in some <i>clock
signal</i>. Details of this behavior will be discussed later.
</p>

<p>
Here we would like to give examples of two most basic sequential logic
elements -- a <b>latch</b> and a <b>flip-flop</b> circuits. We focus on
highlighting differences in behavior of these circuits.
In <a href="#latch">Figure</a> there is an example of a level sensitive
<b>latch</b>. The VHDL process statement construction in this figure is the
key part of definition of the latches behavior. The circuit has two input
signals -- the data signal <tt>in</tt> and the signal
<tt>gate</tt>. There is also one output signal <tt>out</tt>. The circuit is
sensitive on changes occurring in both its input signals. The behavior is
such that whenever <tt>gate</tt> has high value then the output <tt>out</tt>
changes <i>asynchronously</i> (instantaneously) with any change of the
signal <tt>in</tt>. In all situations in which <tt>gate</tt> is low,
<tt>out</tt> is constant and retains its current value.  As the most
significant property, we highlight the asynchrony of the latch behavior.  In
other words, the signal <tt>gate</tt> acts as a gate guarding a direct
connection between the signal <tt>in</tt> and the signal <tt>out</tt>.  A
sample timing diagram is depicted in the right part of the figure.
</p>

<obr src="latch" id="latch">Latch</obr>

<p>
Another basic sequential logic elements are <b>flip-flops</b>. Their behavior is
similar to that of latches with one crucial difference. Unlike latches, a
flip-flop is sensitive only on the clock signal. Assigning a value to a
flip-flop is synchronous with ticks of the clock. An example of an edge
sensitive flip-flop is in <a href="#f-f">Figure</a>. 
<!-- In the following, we note the extension in the conditional logic of the
VHDL process which defines the flip-flop behavior.--> 
The expression of the if-statement requires not only <tt>clk</tt> to be
high, but also the rising edge in that signal. The output <tt>out</tt>
signal will be updated to the value of <tt>in</tt> just only in the moment
when <tt>clk</tt> turns from low to high. Corresponding timing diagram
visualizing a typical flip-flop signal flow is depicted in <a
href="#f-f">Figure</a>.
</p>

<obr src="f-f" id="f-f">Flip-Flop</obr>

<p>
With respect to comparison of aspects of the circuits described above we
distinguish two kinds of behavior of registered signals -- the
<i>synchronous</i> and the <i>asynchronous behavior</i>. In the following two
examples we show how the <i>synchronous</i> and the <i>asynchronous
behavior</i> can be combined. For the first example (<a
href="#asyn-reset">Figure</a>) we use a flip-flop register with an
asynchronous reset. In this case, the signal <tt>out</tt> is reset to low
value whenever the <tt>reset</tt> signal turns to high. This behavior is
absolutely independent of the <tt>clk</tt> signal. With respect to the
<tt>in</tt> signal the circuit behaves as a flip-flop.
</p>

<obr src="asyn-reset" id="asyn-reset">Flip-Flop with an Asynchronous
Reset</obr>

<p>
In <a href="#syn-reset">Figure</a> we present the second example, a
flip-flop register with a synchronous reset. In this case, the <tt>out</tt>
signal is reset synchronously with the clock. Note that the reset take its
effect just with the raising edge of the <tt>clk</tt> signal.
</p>

<obr src="syn-reset" id="syn-reset">Flip-Flop with a Synchronous Reset</obr>

<p>
In the previous paragraphs we have mentioned that the zero delay
abstraction has to be done carefully in some cases; the following example
of <a href="#delay">Figure</a> demonstrates such a case.
</p>

<obr src="delay" id="delay">Zero Delay Abstraction</obr> 

<p>
There are three flip-flop registers (<tt>FF0</tt>, <tt>FF1</tt>, and
<tt>FF2</tt>) with synchronous gates. All of them have the same structure.
In their interfaces there are input signals <tt>in</tt>, <tt>ce</tt>, and
the registered output signal <tt>out</tt>. Each signal <tt>ce</tt> performs
the synchronous gate and guards synchronous change of the output signal
<tt>out</tt> to the actual value of the <tt>in</tt> signal.  In the register
<tt>FF0</tt>, there are both signals <tt>ce</tt> and <tt>in</tt> constantly
set to high value.
<!-- odtud neopraveno (english) -->
Hence, the gate is still opened and (each) rising edge of
clock signal sets the output signal <tt>out</tt> to high signal too. The
input <tt>ce</tt> of the register <tt>FF1</tt> is connected to the output of
<tt>FF0</tt> and so the gate of <tt>FF1</tt> is just opened in the first
rising edge of the clock. That is the place to be careful. As there is a short
delay in the signal transfer in the real hardware, we have to keep on mind
that for the first rising edge of the clock the gate of <tt>FF1</tt> is
closed. Similarly, at the second rising edge of the clock the input signal <tt>in</tt>
of the register <tt>FF2</tt> is delayed and so the output <tt>out</tt> is
once more set to the low signal at the second rising edge of the clock.
</p>

<p>
To sum up, whenever the setting to the registered signal is controlled by an
edge of a signal, the input values taken in to account during this setting
are those immediately before the controlling signal edge.
</p>
<!--potud neopraveno -->
<!--
PRIKLAD: 
paralelni scitacka 
TYPY registru podle toho co je v podmince prirazeni (hranou, brana)
 - DFFRS,                                             1        0
 - DFFERS,                                            1        1
 - LATRS                                              0        1

Problem neustaleneho signalu ve chvili oliznuti.
- Pokud mame v navrhu vice hodin => problem viz kapitola ?
- pokud jedny (tzn i synchronni vstupy) => 
  problem vetsiho zpozdeni, nez tik hodin
    - prevadi se na problem hledani nejdelsi cestu mezi registry
    - delaji jine tooly => my to povazujeme za OK

=> 0-delay abstrakce - obrazek + zmeny nastavaji jen a pouze presne 
ve chvili tiku hodin.
-->

<h1>A Formal View of Basic Hardware Design Entities</h1>

<p>
For the model checking approach we need to specify the model formally as a
finite state transition system where states represent current signal values
and transitions represent their discrete changes. For this purpose we use
<i>Cadence SMV</i> language~<cite href="SMV"></cite> which allows us to encode such a model. Moreover, using
the SMV tool we can prove the properties we claim about the model. For
specification of such properties we use a temporal logic. In this section we
describe how this modeling is done.
</p>

<obr src="td_ks" id="td_ks">Timing Diagrams and SMV trace</obr> 

<p>
Each state of a transition system can be expressed as a vector of current
values of signals in a particular discrete point of time. In the timing
diagram depicted in <a href="#td_ks">Figure</a> states are represented as
columns of 0s and 1s. Assuming the zero delay abstraction, two-value domain
is used for modeling of signal values (high -- $1$ and low -- $0$). Each
transition models instantaneous change of some signals with respect to their
current values contained in the source state. The target state then contains
the new values of the signals being changed.
</p>

<p>
Now recall the two kinds of logic elements we have defined in the previous
section, the combinational logic and the sequential logic. In the following
paragraphs we focus on formal representation of both of them.
</p>

<p>
The combinational logic is captured by the notion of states. Relations
between signal values in a particular state originate just a model of some
combinational logic elements. As the delta delay has no influence on
behavior of combinational logic, the zero delay abstraction fits here well.
</p>

<p>
More difficult is to capture the behavior of sequential logic elements.
Changes of registered signals are modeled by transitions. A change of the
value of a specific registered signal is implied by some values in the
preceding state. 
</p>

<obr src="latch_ks" id="latch_ks">Latch in Cadence SMV</obr> 

<p>
In the case of a latch, any change of the <tt>out</tt> signal is guarded by
a simple condition which requires the clock signal to be high. The
transition system which models the behavior of the latch is encoded in SMV
and showed in the left-hand part of <a href="#latch_ks">Figure</a>. An
example of a trace of this transition system is depicted on the right-hand
side of the figure. Note that any change of any signal, even if it occurs
asynchronously with the clock, defines a transition from the current state
to a new state. In every state in which <tt>clk</tt> is $1$, the signal
<tt>out</tt> has the same value as the signal <tt>in</tt>; otherwise it
keeps itself previous value. This models the asynchronous behavior of the
latch. Due to this asynchrony, zero delay abstraction does not violate
soundness of the model.
</p>

<obr src="f-f_ks" id="f-f_ks">Flip-Flop in Cadence SMV</obr> 

<p>
In contrary to the latch case, the modeling of a flip-flop has to follow
results of the "careful construction" at the end of the previous section.
Hence, whenever the current value of clock signal is zero and the next value
is one, the next value of the output signal is set to the current value of
input.  In <a href="#f-f_ks">Figure</a> there is a SMV code of a flip-flop
and an example of its trace.
</p>

<obr src="ks" id="ks">Register with an asynchronous reset and a synchronous
gate</obr> 

<p>
The <a href="#ks">Figure</a> illustrates an example where both
synchronous and asynchronous approaches are combined.
</p>

<!-- zakladem je dobre napsat preklad sekvencni logiky
  -latche OK - maji chovani kombinacni nebo zachovaji registrovanou
	     - hodnotu
  -flip-flopy - kdyz je nastavovanej asynchronne, pak je to jako latch
              - kdyz ale synchronne, pak nutne zero abstraction brat carefully
-->
<!--It can be formally defined as a triple
<tt>(S,R,s_0)</tt>, where 
<ul>
<li><tt>S</tt> is a set of states</li>
<li> <tt>R</tt> is a subset of <tt>S &times; S</tt> 
                denoting the transition relation</li>
<li><tt>s_0</tt> is an initial state</li>
</ul>
-->
<!--
The most usual situation is that the labeling function <tt>L</tt> is a
valuation of state variables in which the current values of registered
signals are stored. 

For every Kripke structure it is possible to extent <tt>L</tt> in such a way
to become injection. lze doplnit na injekci. Pokud je L injekce, pak muzeme
presne definovat stavy pomoci hodnot atomickych propozic. vyuziva se v
symbolickem model checkingu, ktery je dobry na verifikaci HW.

Nepiseme primo KS, ale v trochu lepsim jazyce, jazyk CadenceSMV. 
Nasledujci hodnoty promennych jsou definovany na zaklade predchazejicich.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
stavy (pevne dane hodnotami v stavovych promennych)
prechody R(pouze prirazeni novych hodnot do promennych na zaklade aktualnich).

Beh - posloupnost vektoru, kde bezprostredne nasledujici splnuji podminku R.
R(s,s')

PRIKLAD: seq. scitacky . stav=(in1, in2, reg, out)
R(in1, in2, reg, out, in1', in2', reg', out') , kde
out' = in1 + in2 + reg mod 2
reg' = in1 + in2 + reg div 2

obrazek
 
Zapiseme: tabulka

Ha, je to stejny, jako timming diagram na konci predchozi kapitoly.
Registry, vstupy a vystupy jsou stavove promenne. Draty vyjadruji
vztahy mezi nimi, cili pouze koduji prechodovou funkci R.

draty (signaly) - > prechodovou funkci R
registry => stavove promenne

modelovani registru v KS.
DFFRS DFFERS LATRS

zavislost na hrane meni state variables (CadSMV), kdezto
zavislost na hodnote (gate) lze vyjadrit vztahy mezi promennymi.

Vstupy jsou stavove promenne, ale volne (abstrakce) - nevadi
 - nemusime ukladat, delame symbolicky model checking [citace]

vystupy  - || -, ale zavisle na vstupech a registrech  - nevadi
 - staci si udrzovat metainformaci tohoto vztahu a v pripade potreby 
   hodnotu dopocitat. tzn usetrime dulezity stavovy prostor
-->
<h1>Two and more clocks</h1>

<p>
In this section, a situation where the zero-delay abstraction cannot be
used is discussed. In VHDL, whenever no delay time is specified for a signal assignment statement, a so called delta-delay is assumed. The delta
delay represents an infinitesimal delay needed for 
signal distribution (as has been mentioned in the Section 2). Besides of the light speed,
the main delay contribution is caused by combinational logic between
registers. The more logical combinators are sequentially connected, the longer
the delay is. It is necessary to ensure the longest delay between any two registers to be shorter than one period of the clock signal which
 controls the registers. To solve this problem it is sufficient to find the
longest sequence of combinational logic (with respect to the caused delay)
and compare its delay with the period of the relevant clock signal. In the
case of single clock HW design, this problem is easy to solve. Zero-delay abstraction can be used here without lost of generality.
</p>

<p>
In the case of two or more clocks in the design, the situation is more complicated. The problem is that there could be some registers used by
two (or more) clocks, hence the value of such a register could be read at the
same time when another part of the design (i.e.~controlled by different clock) might be writing into this register. The situation is depicted in the <a
href="#counters">Figure</a> showing two counter <tt>counter1</tt> and
<tt>counter2</tt> and their difference signal <tt>diff2</tt>. The
<tt>counter1</tt> register is driven by the clock <tt>clk1</tt> and the
registers <tt>counter2</tt> and <tt>diff2</tt> are driven by the clock
<tt>clk2</tt>. The timing diagram illustrates the situation when the
sub-design, which is responsible for counting of the new value of the <tt>diff2</tt> register, is reading from <tt>counter1</tt> just in the moment when its value is not stabilized yet.
</p>

<obr src="counters" id="counters">Two counters controlled by two different
clocks. The difference signal <tt>diff2</tt> is driven by clock
<tt>clk2</tt>.</obr> 

<p>
To model this behavior of the design precisely, we cannot abstract away from the delta-delay. Our approach how to capture this problem is based on the idea of adding one "chaotic" state to the model of the register. In this state, the register returns an undefined value. In the next state, the register is stabilized at the exact value. By that way, an instant of indeterminacy of the signal value is modeled. Thus, the model representing the asynchronous part of the design can then deal with this situation. It can be seen in <a href="#counters_ks">Figure</a> how such a model looks like for the case of the example given above.
</p>

<obr src="counters_ks" id="counters_ks">An approach to modeling two counters controlled by two different clocks.</obr>

<p>
To ensure the correctness of the presented approach to modeling of designs
with more than one clocks, we have to evaluate consequences of addition of
the "chaotic" state to the synchronous subpart of the design. First of all
it can be easily seen that the earliest moment when the rising edge of the clock can arise is the next state. With respect to this fact we can argue that the model of the synchronous subpart of the design is untouched by this change. In <a href="#counters_ks_sync">Figure</a> there is a timing diagram of the common behavior of the synchronous subpart of the design.
</p>

<obr src="counters_ks_sync" id="counters_ks_sync">Synchronous part of a HW
design.</obr>

<h1>Conclusion</h1>

<p>
In this report, we have determined the basic elements of hardware design and we have presented an approach how these entities can be modeled in terms of Kripke structures. We have focused on the problematics of modeling synchronous parts of the hardware design together with asynchronous parts. We have successfully applied the techniques described here in formal verification of the Liberouter hardware design, especially in the verification of the asynchronous FIFO unit~<cite href="LibWWW"></cite>.
</p>

  <!-- References -->
  <seznamknih>
    <kniha id="Bar02">
      Barnat J., Brázdil T., Krčál P., Řehák V., and Šafránek D.:
      <i>Model checking in IPv6 Hardware Router Design.</i><br/>
      CESNET technical report 8/2002.
    </kniha>

    <kniha id="FPGA">
      Xilinx, Inc.:
      <i>DS031-1 Virtex-II 1.5V Field Programmable Gate Arrays.</i><br/>
      October 2001.
    </kniha>

    <kniha id="LibWWW">
      Liberouter:      
      <i>Liberouter Project WWW Pages.</i><br/> 
      <tt>http://www.liberouter.org/</tt>
    </kniha>

    <kniha id="SMV">
      Cadence SMV:
      <i>Cadence SMV WWW Pages.</i><br/> 
      <tt>http://www-cad.eecs.berkeley.edu/&vlnka;kenmcmil/smv/</tt>       
    </kniha>

    <kniha id="Ver">
      Daniel C. Hyde:
      <i>Handbook on Verilog HDL.</i><br/>
      <tt>www.eg.bucknell.edu/&vlnka;cs320/1995-fall/manual.pdf</tt>
    </kniha>

    <kniha id="VHDL">
      Ashenden Peter J.:
      <i>The VHDL Cookbook.</i><br/>
      <tt>http://tech-www.informatik.uni-hamburg.de/
      <br/>vhdl/doc/cookbook/VHDL-Cookbook.pdf</tt>
    </kniha>

    <kniha id="MC">
      Edmund M. Clarke, Orna Grumberg and Doron A. Peled:
      <i>Model Checking.</i><br/>
      Cambridge : MIT Press, 1999.
    </kniha>    

    <kniha id="Esterel">
      Gerard Berry:
      <i>The Foundations of Esterel.</i><br/>
      Cambridge : MIT Press, 1998.
    </kniha>  

  </seznamknih>

</zprava>




