Hardware Reference
In-Depth Information
4.5
Assumptions
We have mentioned the existence and general meaning of assumptions in previous
chapters, here we provide a more detailed examination of assumptions.
4.5.1
Motivation
Figure
4.13
shows a module implementing a simple RAM.
When
read
is asserted,
out
is assigned the contents of the memory at address
addr
. When
write
is asserted,
data
is written at address
addr
. This module also
contains assertion
stable_when_write
checking that when
write
is asserted the
module output
out
does not change. The system function
$stable
(Sect.
7.2.1.4
)
returns true when the current value of the signal is identical to its value at the
previous clock tick, and false, otherwise.
It looks like our design should satisfy this assertion, but if you try to formally
verify the model, you will discover that the assertion fails. Why? The answer
may be surprising: when
read
and
write
are asserted together, the value of
out
may change. But how can it be? We know that
read
and
write
cannot be asserted
together, otherwise the design would not function properly. But how should formal
verification tools guess that this input condition is impossible?
As we can see from this example, to make the design work properly its inputs
should be appropriately constrained. These constraints are called
assumptions
, and
there is a special notation for assumptions in SVA. In our example, the following
assumption is missing:
Fig. 4.13
Simple RAM
Search WWH ::
Custom Search