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

Subversion Repositories dblclockfft

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

Rev

Directory listing | View Log | Compare with Previous | RSS feed

Last modification

  • Rev 23, 2015-03-14 23:51:44 GMT
  • Author: dgisselq
  • Log message:
    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.

powered by: WebSVN 2.1.0

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