DSPTester peek/poke printing more useful info

[shunshou]

I think you shouldn't directly be using TesterOptionsManager and should have a DSPTesterOptionsManager that lets you customize verbosity.

I finally got the standard PeekPokeTester to print out something, but evidently, things are just printed out as BigInt converted to base 10.

My old DSPTester printout allowed for much more thorough debugging:

You could print out base 10/hex bits flavor. It would also directly print out the decimal version of DspReal/FixedPoint peek/pokes... and for fixed point, it would also show # integer bits + # fractional bits used (or it might've been range, I forget) to compute the Double result for fixed point (that helps to double check that width inference, etc. were working correctly).

All of these features help to make the debug process easier.

For example: If I want to test the correctness of implicitly[Real[R]].fromDouble(3.333333)

And I'm not super sure how many Fixed point fractional/integer bits are allocated, I'd like to use the tester to debug...

I'm also not loving the fact that expect prints twice (the first line is ugly and non-informative -- you don't even know which signal it's referring to):

expect got 2.00000000 expect 2.00000000
EXPECT AT 15 add 1.0 + 1.0 => 2.0 should have been 2.0 PASS

Expect should look more like the peek/poke strings, and if you supply a string, it should only print something like the 2nd line, but with a signal name [without you having to manually pass in result and expected vals].

Little details like this speed up the design/debug process considerably...

---

Edit: Ok, DspTester needs its own verbosity, so you can turn off _verbose for PeekPokeTester and override all the prints for Dsp specific things with something that's more useful...

[shunshou]

I'm working on my own version of VerboseDspTester (extends DspTester) that gives me features I want. It should also make addressing #29 a piece of cake whenever I need to do it for hardware validation...