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

Subversion Repositories dblclockfft

[/] [dblclockfft/] [trunk/] - Rev 43

Rev

Filtering Options

Clear current filter

Rev Log message Author Age Path
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 3375d 12h /dblclockfft/trunk/
22 Lot's of changes, mostly around getting this multiply to fit within a
particular FPGA. Specifically, we just added the capability of using
hardware multiplies to the command line options. Use them if you have
them, and it will simplify the operation of the FFT.
dgisselq 3376d 14h /dblclockfft/trunk/
21 Modified the core generator so that the result compiles with Xilinx's Vivado
toolsuite without generating any syntax errors.
dgisselq 3377d 10h /dblclockfft/trunk/
20 Adjusted rounding to use the floating point modes inherent in the double type.
Hence, (int)(x+0.5) has been replaced by (int)round(x).
dgisselq 3379d 00h /dblclockfft/trunk/
19 Added the capability to accumulate bits internal to the FFT, only to drop
those extra bits just before the end. This helps to reduce truncation
error, and may even drop it by a factor of four (my own measurements).
dgisselq 3379d 20h /dblclockfft/trunk/
18 This file was placed into the bench/rtl/ directory. dgisselq 3381d 12h /dblclockfft/trunk/
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 3381d 12h /dblclockfft/trunk/
16 Cleaned up the test bench build scripts, made sure license statements were
placed on all files, etc.
dgisselq 3381d 12h /dblclockfft/trunk/
15 Added rounding into the routine to remove bias. All of the test benches have
been modified so that the FFT, with rounding, now passes. While the rounding
implementation applied does remove bias, it does not yet remove all bias.
Some work still remains.
dgisselq 3382d 11h /dblclockfft/trunk/
14 Found several bugs in the previous version. The biggest were in the qtrstage.
Apparently, the qtrstage didn't work before, even though I thought it did.
Further, the FFT testbench has been adjusted to place proper values into
the fft_tb.dbl file it creates. (I've been testing it by reading this into
Octave, and visually inspecting the results--quantitative testing of the
fft_tb and ifft_tb are still lacking.) Now, however, if I cascade the
forward and reverse together, I seem to get something at least close to the
right answer. Close, of course, is relative. I think all that I still
struggle with is rounding and truncation errors, hence I'm checking in
my changes.

The FFT generator was also modified to allow arbitrary length paths
in the command line specified path prefix. This has not been tested.

A bug was also found in the butterfly, whereby for certain multiply delays
the butterfly would be unable to determine whether or not its results were
valid. Adding an extra bit to the FIFO address in these cases fixed the
problem. This change was encapsulated into the lgdelay() function, and
an additional bflydelay function. In my frustration, I modified the
fftstage function so that, when it is built, the parameters it is built
with are the default parameters. This should only affect testing, by
making any testing more realistic, but that may still remain to be seen.

Another change was made to the core generator, so that now when a core
is generated, the main file now contains a copy of the arguments that were
used when the core generator was invoked. This is good for posterity, in
case you ever need to ask yourself how I ended up here.
dgisselq 3383d 09h /dblclockfft/trunk/

< Prev 1 2

Show All

powered by: WebSVN 2.1.0

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