Did you guys actually fix fixed point tester problems? about dsptools HOT 7 CLOSED

Point is, I can go around and fix this at a lower level, but that fundamentally might change the way you guys do your tests if you do correct for this somewhere that I'm not aware of...

from dsptools.

Also, nearly equals is insufficient for fixed point expects. I'm working on a better solution, which is essentially porting over my old Chisel2 DSPTester to here.

from dsptools.

Pull request #37 adds "toBigIntUnsigned" and "toDoubleFromUnsigned". Perhaps not the best names, but they convert between FixedPoint and unsigned integers (or rather, unsigned representations of the bits in a signed FixedPoint number). For our stuff, we have AXI everywhere, which abstracts all input/output types as UInts. The way I've written it works for FixedPoint up to 32.W I believe, but not any larger yet.

Also, in the same file (DspBlock.scala, which got moved to rocket-dsp-utils) we have a compareOutput def that compares two arrays. The intention is to just stream data in and out and wait to compare at the end. compareOutput lets you supply an "epsilon" as a "nearly equals". Future work will do more interesting comparisons, like noise analysis or more holistic "expect"s.

from dsptools.

My old tester basically allowed you to set tolerances for fixed point and real expects. Even for reals, you're going to be off by a fudge factor that grows as the computations complexity increases. For fixed point expects, I had a tolerance in terms of "how many LSBs" can be wrong. Noise analysis (done @ the block level, and not part of ChiselDSP) just took the Double out and compared to the real case (for SQNR).

I'm adding my expect functionality back into VerboseDspTester.

Re the unsigned stuff:

It would've made more sense to make all of these changes directly in DspTester, since not everyone will be starting out with the AXI interface.

There are 2 things I can do:

1. Overhaul DspTester to handle signed stuff properly. I assume this affects your DspBlockTester.
2. Make all of my changes to VerboseDspTester. You can choose to have your DspBlockTester extend it or not.

By overhaul, I mean move sign flipping to the appropriate tester. I should also be able to get it to work for Fixed > 32, since what they did in Chisel2 should work just fine.

What's your preference? @stevobailey @grebe

from dsptools.

Oh, tho frankly speaking, this might be an easier change @ the chisel-testers level... I'm just concerned that a PR will take ages to resolve there... [granted, I've already forked it...]. @chick do you have any opinions?

Basically, I need patches for these things in ~day timeframes...

from dsptools.

@shunshou I'd rather see stuff wind up in the DspTester where possible rather than a VerboseDspTester. @chick would be better able to tell you about chisel-testers, although I don't think it would take much longer to get stuff looked at.

from dsptools.

Ok well VerboseDspTester makes some amount of sense for my additional VerilogDumping features, and DspTester is kind of a hot mess right now [functionality is possibly correct, but things are a little all over the place...].

If you have some way to do a regression test, I can make changes in DspTester as long as your stuff doesn't break... I just posted an issue in chisel-testers.

from dsptools.