| Rev |
Log message |
Author |
Age |
Path |
| 16 |
Cleaned up the test bench build scripts, made sure license statements were
placed on all files, etc. |
dgisselq |
3412d 22h |
/dblclockfft/ |
| 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 |
3413d 20h |
/dblclockfft/ |
| 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 |
3414d 19h |
/dblclockfft/ |
| 13 |
I updated the butterfly testbench to automatically determine the delay
internal to the chip and multiply, and then to use that delay in determining
whether the values were accurate or not. This is better than the fixed
delay approach that was used before. The change was necessitated by an
attempt to use a different multiply structure that had a different
internal delay to it. (The multiply didn't work out, as it only worked
on operands with identical numbers of bits.) |
dgisselq |
3415d 00h |
/dblclockfft/ |
| 12 |
Minor changes to both class (trimmed the portlist and revision history
tables to match the text width), and the description of the io ports.
Specifically, i_left, the port that is broken out and described, had
mislabeled/misnumbered bits in the port list.
As this is a minor change, I will not update the revision--although perhaps
it should be. |
dgisselq |
3418d 06h |
/dblclockfft/ |
| 11 |
Here's the full first draft of the specification, now complete. |
dgisselq |
3418d 07h |
/dblclockfft/ |
| 10 |
I'm in the middle of building the spec. I've got most of the parts
complete, but the figure diagraming an FFT stage is still in the works.
I'm checking this in in the hopes that someone struggling to use this
will find this initial draft of the specification useful enough to
make their project work. |
dgisselq |
3418d 19h |
/dblclockfft/ |
| 9 |
Now working on the test bench for the FFT. Currently, the FFT passes
all test bench "tests." However, the test bench does not yet accurately
report on the success of its work. This remains for future work. Lots
of bugs fixed while making this test bench code work.
(I should mention, while all test benches currently pass, that doesn't
mean that the code works ... yet. I just haven't found the bug that
breaks it.) |
dgisselq |
3421d 00h |
/dblclockfft/ |
| 8 |
This completes the initial work on a test bench for the FFT stage. I
chose to test the odd 2048 stage only, but (hopefully) the testbench
will still apply to all other stages as well. At any rate, based upon
some trial runs, it looks like the FFT may be starting to work as well.
More testing is needed, for certain, but to do that I'm going to have
to figure out just what tests are needed, and how exactly to apply those
tests within the test bench construct. |
dgisselq |
3421d 07h |
/dblclockfft/ |
| 7 |
Two sources belonging to the last commit, whose comments go with the
last commit, that just didn't make it in time. |
dgisselq |
3421d 18h |
/dblclockfft/ |
