Add clock and reset options #70
Conversation
|
Just FYI, I know why it's failing travis. It will be fixed once this PR is merged: stanford-centaur/smt-switch#95 |
| if (sk == BV) { | ||
| ts.constrain_init(s->make_term(Equal, clk_state, zero)); | ||
| ts.assign_next(clk_state, s->make_term(BVNot, clk_state)); | ||
| } else if (sk == BOOL) { | ||
| ts.constrain_init(s->make_term(Not, clk_state)); | ||
| ts.assign_next(clk_state, s->make_term(Not, clk_state)); |
There was a problem hiding this comment.
I am not sure how realistic the following scenario is, but what happens if e.g., a BTOR2 file already contains logic to handle a custom clock signal? In that case, the user would not need to use the new add-clock feature, however, it would be good to have some error checking to prevent mixing an existing clock logic with the clock logic we add to the model.
In the example below, a counter is incremented whenever the clock (already part of the model) is high, and the clock is always kept high by its next-function. Hence the property fails, i.e., the counter reaches its maximum value.
The call ./pono count2-clk.btor2 produces a counterexample as expected.
However, the call ./pono -k 100 -c clk count2-clk.btor2 reports unknown. We could throw an exception here because the clock signal gets two next-functions assigned, which we usually prevent, if I am not mistaken. Also, with a toggling clock that we add, the property should be reached in twice the number of steps, but it isn't.
1 sort bitvec 3
2 zero 1
3 state 1 count
4 init 1 3 2
5 one 1
6 add 1 3 5
8 ones 1
9 sort bitvec 1
10 eq 9 3 8
11 bad 10
12 zero 9
; clock signal
13 state 9 clk
; clock initialized to zero
14 init 9 13 12
15 ite 1 13 6 3
; next(count): if clk is high then count++ else don't change
16 next 1 3 15
; next-func of clk -- for testing, keep clk always high
17 one 9
18 next 9 13 17
There was a problem hiding this comment.
Hmm.. that is a good point. We can at least throw an exception for two calls to assign_next. Otherwise, I don't think there's much to do to be honest. It's up to the user to know what the encoding is. For Verilog translated by Yosys to BTOR2, it will have a disconnected clock (in which case it shouldn't matter if it's toggled or not) unless it's translated with clk2fflogic, in which case you need to toggle the clock.
There was a problem hiding this comment.
Commit 1548b71 makes it throw an exception if assign_next is called twice with the same state variable. It now says this:
[makaim@lono build]$ ./pono -k 100 -c clk count2-clk.btor2
State variable clk already has next-state logic assigned.
unknown
b0
There was a problem hiding this comment.
Thanks for the updates, @makaimann!
I agree that we should not do more other than checking if a next-state update has been assigned already.
Looks good to be merged to me.
* Add option infrastructure for clock/reset * Add method for looking up a term by name to ts * Minor fix * First pass on clock / reset functions (UNTESTED) * Connect clock/reset functions to command line options * Add simple tests for clock / reset modifiers * Add missing test file * Update smt-switch version * Update python assertions for new named_terms * Throw a PonoException if a state is assigned a next state update more than once
This PR adds modifier functions for adding a simple reset sequence and toggling the clock of a transition system. They would also be exposed through the command line options. This can be very useful depending on the input system. In particular, using Yosys to produce BTOR2 with the option
clk2fflogicrequires toggling the clock and hardware often requires a reset sequence. Note: Yosys does have a simulation option that can simulate the reset sequence. This works well most of the time, but occasionally it does not seem to give monitors' state an initial value which can result in spurious counterexamples in the first state.