| Rev |
Log message |
Author |
Age |
Path |
| 26 |
A lot of updates and upgrades in this release. Specifically, work took place
over the last several days to demonstrate this FFT on an FPGA. It was
demonstrated on the Xilinx Artix-7 found on a Basys-3 development board.
Part of the effort stemmed around making certain that the DSPs were used
optimally, part of it stemmed around making certain that various parts of the
FFT could use block RAM-type memories. The other massive change involved
removing as much unnecessary logic as possible, so that two 16-bit 1k FFTs
could fit onto this part--together with other glue logic. The bottom line,
though, is that it all now works. Specifically, I've tested it successfully
with
fftgen -f <FFTSIZE> -n 16 -m 16 -p 7 -c 1 -x 1
and with FFTSIZEs of 32, 64, 128, 256, 512, and 1024.
Oh, I should mention that there's also an undocumented DEBUG interface to the
part, and I fixed where the Verilog files went when given an argument, so
that they actually went to the directory specified. Minor updates have taken
place to the documentation format, making it match the documentation format
for other opencores projects that I've produced.
On a sadder note, the Verilator simulation fft_tb no longer works. (Yeah, get
that---the FFT implementation works but Verilator does not. Sigh). |
dgisselq |
3463d 11h |
/dblclockfft/trunk/doc/spec.pdf |
| 25 |
The documentation has been changed to bring it closer to the example
specification document. The big change is that the first line, the
headline if you will, of each table has een adjusted to have a gray
background.
The second and bigger change is in the fftgen software itself, or more
specifically to the code that it produces. I had the opportunity to build
the code using Xilinx's ISE and spent some time getting rid of warnings
during the build. As a result, registers that need initial conditions
now have initial conditions. In a similar manner I have trimmed out
registers that were unused. The resulting code continues to pass all
test benches, although I will admit that the automated testing of the
whole fft or ifft via there test benches, fft_tb and ifft_tb, continues
to be a less than automated process than it should be. Therefore, these
test benches always "pass" and only a manual examination of the results
can be used to confirm their success. |
dgisselq |
3513d 12h |
/dblclockfft/trunk/doc/spec.pdf |
| 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 |
3544d 04h |
/dblclockfft/trunk/doc/spec.pdf |
| 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 |
3554d 11h |
/dblclockfft/trunk/doc/spec.pdf |
| 11 |
Here's the full first draft of the specification, now complete. |
dgisselq |
3554d 11h |
/dblclockfft/trunk/doc/spec.pdf |
| 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 |
3554d 23h |
/dblclockfft/trunk/doc/spec.pdf |
