OpenCores
URL https://opencores.org/ocsvn/dblclockfft/dblclockfft/trunk

Subversion Repositories dblclockfft

[/] [dblclockfft/] [trunk/] [bench/] [rtl] - Rev 41

Rev

Details | Compare with Previous | Blame

Filtering Options

Clear current filter

Rev Log message Author Age Path
41 Updated bench tests for each component dgisselq 2072d 07h /dblclockfft/trunk/bench/rtl
35 TB now handles newer Verilator versions

I also placed verilator -Wall into the verilator Makefile,
turned on the -trace capability (tho nothing uses it), and
placed `default_nettype none into all of the created
Verilog files.		 dgisselq 2545d 20h /dblclockfft/trunk/bench/rtl
33 Updated internal docs, ignore files, no substantial changes. dgisselq 2792d 16h /dblclockfft/trunk/bench/rtl
30 Minor documentation edits. dgisselq 3269d 09h /dblclockfft/trunk/bench/rtl
23 Lot's of work to implement a variable means of rounding. The variable
rounding is now implemented within the code, all that's left is to
place a command line option to the generator to choose how values
are to be rounded: either by truncation (drop the lower bits), by
always rounding half up (if the first extra bit is one, go up),
by rounding away from zero (if exactly .5, move away from zero), or
by rounding towards even (if exactly .5, move towards the nearest
even value).

This added an extra clock cycle to each stage, so all of the
test benches needed to be reworked. There is currently no testbench
to test the rounding method itself. This necessitated some
wholescale changes to the testbench code, and the addition
of the twoc.[h|cpp] files. (They were within every piece of code, just
copied from one to the next, this now encapsulates them within their
own file so fixes will propagate to all.) Other changes include creating
testbench classes, adjusting the classes so that one can test what will
happen if the sync isn't added initially, and more. In the end, my
problem was tied to an assumption within fftmain.v that dblstage would
always be a one tick delay, whereas with the one tick of the rounding
function it now becomes a two tick delay .... but the task is done, and
the FFT appears to work again. The maximum sum of square errors (XISQ)
is about half what it was before now, when I use convergent rounding.		 dgisselq 3537d 10h /dblclockfft/trunk/bench/rtl
17 These files were moved here from the trunk/bench/cpp directory, as they
seem to make the most sense here. (They're not C++ files, but Verilog
files, supporting the testbench functions.)		 dgisselq 3543d 10h /dblclockfft/trunk/bench/rtl

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.