Well that's interesting. I just ran this test with the map bit_rev(0:1023,10) and both distributed ROMs seem to have been implemented in their entirety, with no logic reduction. So clearly the synthesis is not optimizing well at all, even for such a simple map. The espresso map ended up as simply flip flops as expected since the latency was set to one. Glenn
On Thu, Sep 25, 2008 at 3:37 PM, G Jones <[email protected]> wrote: > I just threw together a quick design which has two roms, one with ''use > placement information" turned on and one with it off, and also my port of > the espresso map block. I'm going to test them with various maps and see how > the implementations look. Any specific maps I should try? > Glenn > > > On Thu, Sep 25, 2008 at 3:22 PM, Henry Chen <[email protected]>wrote: > >> 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 <[email protected]> >>> 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 >>>>> >>>> >>>> >>> >>> >>> >
