This release also includes a new SAT solver called "smvsat" which is now the default SAT solver for the various techniques that use SAT, including bounded model checking (-bmc), proof-based abstraction (-absref) and SAT-based model checking (-smcsat2). This is a "proof generating" SAT solver, meaning that in the unsatisfiable case it produces a proof of the empty clause using resolution steps. SMV can still use zChaff (or other SAT solvers) for bounded model checking, but this cannot be used with the new model checking techniques since they rely on proofs of unsatisfiability.
x[y] in {a,b,c}
could result in unnecessary combinational variables. This caused some verification runs that previoiusly terminated to diverge. The problem is now fixed.
@(#)report.c 3.2: apply_func_op:op=367
Now provides meaningful error message. Fix is to use boolean equivalence "<->" instead of equality "=".
@(#)report.c 3.2: unref_bdd: negative reference count
This is now fixed.
"file.out", line XX:XX: unterminated string or character constant
This is now fixed.
x : boolean resolve;
init(x) := 0;
x := 1;
The symptom was:
@(#)report.c 3.2: apply_func_op: op = 415
This now produces a meaningful error message.
This makes it possible to treat bit vectors, such as address, as scalarset vectors, in both SMV and Synchronous Verilog. A scalarset bit vector can be treated as a symetric scalar quantity at a high level of abstraction and as a bit vector at a lower level. In particular, bit vectors in Synchronous Verilog can be declared as scalarsets, while maintaining "synthesizable" code, using macros for the types.
In support of the above. Should also allow some compositional verification to be done directly in SV, although the type structure of SV is still too poor to support writing abstract models.
This uses a SAT solver to search for counterexamples of a bounded depth. The bounded model checker "bmc" and the SAT solver "sato" must be installed separately. This option only works on Unix-like systems. At present, it depends on various Unix programs like sh, awk and sed, which means there may be incompatbilities due to variations in these programs on different systems.
Previously, SMV could not handle more than one ordset parameter in a property, thus "double induction" was impossible. This is now fixed, although the nember of representative cases generated with multiple orderset parameters of the same type can be quite large! Also, inequality operators can now be applied to ordsets.
You can now split cases on a variable or expression of a non-symmetric type. The variable or expression must be statically typable, so that SMV can determine whether the specified cases are exhaustive. Thus, for example, if x is of type boolean, then the following is legal:
forall(i = 0..1)
subcase bar[i] of foo for x = i;
Note, this could just as well be written out as separate subcase declarations without the loop:
subcase bar[0] of foo for x = 0;
subcase bar[1] of foo for x = 1;
That is, because we do not need to obey symmetry rules, we can write out the expansion of the loop using constants. This also allows us to split cases on a variable of enumerated type, for example:
y : {red, green, blue};
subcase red_case of foo for x = red;
subcase green_case of foo for x = green;
subcase blue_case of foo for x = blue;
Of course, we can't use a parameterized property name, like bar[i], since array subscripts can't be of enumerated type. Notice this also means that we can split cases on any expression that can be stactically typed as boolean. Thus for example:
Displays all the assertions used to prove the current property, and whether
they are assumed "upt to t", "up to t - 1" or "always".
See smvps(1).
subcase special_mode_case of foo for (mode = special) = 1;
subcase normal_mode_case of foo for (mode = special) = 0;
1) In old SMV modules, X, F and G should not be keywords
2) In old SMV modules, next(x=y) should be O.K.
3) In old SMV modules, E[p U q] should be treated as E(p U q)
ordset foo;
x : array foo of boolean;
forall(i in foo)
x[i] := x[i+1];
On the other hand, next(x[i]) := x[i+1] would be O.K. The same comment probably holds true for "refines" declarations. For example
spec[i] refines spec[i+1]
Since SMV doesn't take this into account, it sometimes leaves a signal free when there is one obvious abstraction choice, but that assignment has been subcased. Workaround is just to specify the desired layer by hand in a using..prove declaration.
An expression like "foo ? [0,1] : weak" won't be handled correctly.
ordset foo;
x : array foo of boolean;
forall(i in foo)
x[i] := x[i+1];
On the other hand, next(x[i]) := x[i+1] would be O.K. The same comment probably holds true for "refines" declarations. For example
spec[i] refines spec[i+1]
1) All properties on cycle begin with "G" operator
2) At least one using..prove declaration on the cycle is "unit delay", thus:
using (x) prove y
Any used assertions on a cycle with the the assertion being proved will be assumed only up to time t (or t-1 in unit delay case).
always @(...) begin
if (x) begin end
y = ...;
end
assign x = y;
circularity is caused by misconstrued dependency of y on x.
assign {x,y} = expr;
parameter [1:0] y = 2'd3;