Regarding simulation speed, it does take a while to generate a map of size 2^15, but the save state logic works well, and this only happens when the parameters are changed. Updating the design after initially setting the parameters does not take an appreciable amount of time. Simulating a map of size 2^14 was very quick and would not dominate simulation time. Therefore, I see no reason not to provide the espresso map block as an option, especially since it seems to be working fine with 10.1 now. I will commit the tested version of the mask init file. Glenn
On Thu, Sep 25, 2008 at 4:10 PM, G Jones <[email protected]> wrote: > 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 >>>>>> >>>>> >>>>> >>>> >>>> >>>> >> >
