Update eval and expect semantics

[leonardt]

This now matches verilator's semantics, where expect is equivalent to
asserting a peek. So, the user must now call eval before expect if
the expected value reflects newly poked inputs. Compare this to before,
where expect meant " this is the expected value when the next eval is
called".

[coveralls]

Pull Request Test Coverage Report for Build 88

• 10 of 11 (90.91%) changed or added relevant lines in 2 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.7%) to 91.914%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
fault/tester.py	9	10	90.0%

Totals
Change from base Build 86:	0.7%
Covered Lines:	341
Relevant Lines:	371

---

💛 - Coveralls

[rsetaluri]

I'm wondering if we maybe want to change the mechanics of fault.Tester a bit. It seems like we the user of Tester is thinking in terms of the standard simulator (verilator, python simulator) and expects those semantics. We then roll that up into test vectors, and then each target unrolls it again into sets, evals, and gets. What if instead of creating test vectors we just recorded the sequence of actions. So the fundamental representation in tester is List<Action> where action is either Set(Wire, Value), Eval(), or Check(Wire, Value). It seems the codegen then would be very simple. The only thing would be some special actions for clocks. Let's talk more in person.

Good to merge for now.

[leonardt]

That makes sense, and I agree that would make the semantics more apparent to the user. One issue right now is that when an assertion fails, it doesn't map to the line when expect was called. I think if we explicitly have a notion that users are constructing test sequences, which are then passed to the simulator, understanding error messages will be more natural. However, we should still try to map errors back to the original line that created the test vector.