For simpler logic, the logic reduction seems to work, but the casper_library
FFT has always been rather bloated in comparison to the astro_library ones,
and I think the unscrambler is the cause.
I don't think the synthesizer is good enough to recognize
{bit_reverse(1:fft_length),(1:fft_length)+2^fft_length} or whatever it comes
out to be. We were trying to build 2^15 FFTs for SETISpec, and for both 7.1
and 10.1 green blocks it's really trying to generate a 2^15-deep ROM.
--Henry
Aaron Parsons wrote:
I would avoid hardcoding the case for biplex FFTs, if you can avoid
it. It's a much better solution to get the general reorder block to
work. The pink blocks did use espresso to do the logic reduction in
reorder blocks, and that resulted in slow simulation. Once it was
determined that ROMs used logic reduction in their implementation, we
migrated to those. I must say I'm *very* surprised that ROMs no
longer do this optimization. This may be worth calling Xilinx about.
It may be that there is some flag that is disabling this reduction.
Logic optimization is kind of the whole point of ROMs...
On Thu, Sep 25, 2008 at 6:09 PM, Henry Chen <hche...@ssl.berkeley.edu> wrote:
Hi Glenn,
I'm actually in the process of doing this partway for the biplex
unscramblers. For large FFTs, the arbitrary reorders consume an
insanely huge number of resources trying to get the mapping ROM.
Since the biplex unscramble reorders use a known and easily-described
reorder, I was just going to hardcode them for this special case.
The thing about the pink block reorders, though, was it that it
depended on espresso, which I think we were trying to avoid using
for one reason or another.
Let me know if you want me to wait so we standardize on yours, or
if you want me to just proceed with mine, and then we can converge
in the future.
Thanks,
Henry
G Jones wrote:
For anyone who's interested, I've begun porting the map function used in
the pink reorder blocks to 10.1. For complex reorderings, the green block
seems to be inefficient since it implements the map using ROM rather than
logic as was done in the pink blocks. Ideally, the synthesis tool would
automatically apply logic reduction to the ROM and the two would be
equivalent in implementation, but this does not seem to be the case. I plan
to add an option to the 10.1 FFT block to use either the logic based or ROM
based map, but in case I get side tracked, I wanted to share what I've done
so far. It is not yet tested. The code is here:
http://casper.berkeley.edu/svn/trunk/caltech/lib10.1/map_init.m
Glenn
