Subversion Repositories dblclockfft

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.