Re: casper-scm Commit 13b5978: rewrote butterfly_direct_init
Andrew Martens wrote: Sorry, did not realise you were in the middle of something. No worries. This is dragging on longer than expected (what, with Matlab segfaulting every minute or so). It looks like i won't be pushing any changes before tomorrow evening. Everything is integrated back into the fft library. Now i need to make some new unit tests with coverage for these new features. I've also fixed the superficial wiring bug, and somehow my version of the library is slightly smaller than the original(!). I didn't manually break the links, just changed a parameter to make it redraw and saved the result as the default. It does result in a non-default block being the default but this is the case in other areas too, Ah, ok. hard to make every block use the default. I'm only now able to fully appreciate this after adding new parameters to every fft block and then reintegrating them into each other. Ugh. I will figure out how to revert my last commit, more adventures with git :) Godspeed. ;) Billy William Mallard wrote: Andrew Martens wrote: William Mallard wrote: Those wires are broken because the fft_direct block is configured for 2 inputs, but the default fft_wideband_real block needs it to have 4. But if you were to change the fft_direct block to default to 4 inputs, then the default fft block would be broken by default. Fixing this would require increasing the default sizes of the fft and fft_direct blocks. I didn't do this because i figured the sizes were chosen for a reason. I'd guess the fft and fft_wideband_real blocks are set to the smallest sizes allowed by our streaming architecture. This should be fixed as of commit 1596f5f. Somehow the fft_direct block got the wrong size when used in the default fft_wideband_real. I did try to make the default sizes the smallest possible to reduce the size of the libraries and amount of redrawing needed. I agree that we should try to keep the library as small as possible. In your most recent commit (1596f5), you manually broke the links on all fft_wideband_real sub-blocks. While this approach does fix the broken wires, it also means that each sub-block is now stored as a copy of a library block (instead of as a link to a library block). This takes up much more space than the approach i suggested above. To quantify that, here's the size (in bytes) of casper_library_ffts.mdl: 778050 : commit d38fb1c (my last commit) 1232140 : commit d38fb1c + my suggested fix 2389360 : commit 1596f5f (your last commit) How would you feel about rolling back your last kat commit? I'm 80% done with another major optimization that required modifying every single block in the fft library, and i was planning to push it today or tomorrow. I could follow that up with a fix for the broken wires that minimizes library size. I have been compiling a design with Billy's FFT changes for a while now and so far things seem quite solid. Glad to hear it! Thanks for pulling my changes to the kat repo. Billy
Re: casper-scm Commit 13b5978: rewrote butterfly_direct_init
On 12/01/2010 05:37 PM, Mark Wagner wrote: I pulled again, and unset the global variables mentioned here: http://63.241.181.135/support/answers/33845.htm Which seemed to make that error go away. Either one of those steps should have fixed your bug. For future reference, here's a less sketchy version of that link: http://www.xilinx.com/support/answers/33845.htm Although, i've been having other issues with the newest commits. Namely, the pfb_wideband_real won't redraw properly. I think this is due to it still having the old adder_tree. I haven't touched the PFB library or the adder_tree block, so this has nothing to do with my string of recent commits. If i had made changes to these, i would have written about it in my commit messages. So you might want to start a new thread about pfb issues. Also, the fft_wideband_real in a fresh clone of the library has broken wires. Yeah, i noticed these broken wires before i began optimizing the fft, so that also has nothing to do with my recent commits. Those wires are broken because the fft_direct block is configured for 2 inputs, but the default fft_wideband_real block needs it to have 4. But if you were to change the fft_direct block to default to 4 inputs, then the default fft block would be broken by default. Fixing this would require increasing the default sizes of the fft and fft_direct blocks. I didn't do this because i figured the sizes were chosen for a reason. I'd guess the fft and fft_wideband_real blocks are set to the smallest sizes allowed by our streaming architecture. This seems it can be fixed by redrawing, Exactly. If you change any parameter(s), the block redraws correctly. So this isn't really an issue. but i've also been getting errors about not finding the twiddle block even though it's there, This sounds like a problem that people often have with Matlab loading libraries. Can you give a list of steps to replicate this behavior? but this may be because names of blocks were changed and the path is too long, but i'm still in the process of debugging that. The only block names that changed got shorter. AddSub[12] became cadd, and AddSub[34] became csub. So i doubt that this is your problem. Billy On Mon, Nov 29, 2010 at 11:03 PM, William Mallard w...@llard.net wrote: I haven't had any trouble compiling with the latest fft optimizations, but i think i know what your problem is. I just pushed something that should fix it. Can you pull from bwrc and try compiling again? On 11/29/2010 09:11 PM, Mark Wagner wrote: Hi Billy, I tried to compile a design with your modified fft_wideband_real and received the following error during system generation (see below). Have you been able to get a design to compile? Do you recognize the problem? Thanks, Mark HDL simulation model compilation failed. WARNING:Simulator:1010 - One or more environment variables have been detected which affect the operation of the C compiler. These are typically not set in standard installations and are not tested by Xilinx, however they may be appropriate for your system, so the flow will attempt to continue. If errors occur, try running fuse with the -mt off -v 1 switches to see more information from the C compiler. The following environment variables have been detected: Error occurred during Simulation Initialization. Reported by: 'gbtspec_mode01/fft_wideband_real/fft_biplex_real_4x0/biplex_core/ fft_stage_1/butterfly_direct/cadd/DSP48E' On Tue, Nov 23, 2010 at 7:49 PM, William Mallard w...@llard.net wrote: When dsp48_adders is enabled, butterfly_direct now uses caddsub blocks for complex addition, halving the number of dsp48s used. To implement this, the block's init script needed to be almost completely rewritten to redraw the block. It also necessitated the string of recent changes to all fft-related masks, as well as the creation of the parameterized caddsub_dsp48e block. All existing fft unit tests pass. Billy
Re: casper-scm Commit 13b5978: rewrote butterfly_direct_init
Hi all Yeah, i noticed these broken wires before i began optimizing the fft, so that also has nothing to do with my recent commits. Those wires are broken because the fft_direct block is configured for 2 inputs, but the default fft_wideband_real block needs it to have 4. But if you were to change the fft_direct block to default to 4 inputs, then the default fft block would be broken by default. Fixing this would require increasing the default sizes of the fft and fft_direct blocks. I didn't do this because i figured the sizes were chosen for a reason. I'd guess the fft and fft_wideband_real blocks are set to the smallest sizes allowed by our streaming architecture. This should be fixed as of commit 1596f5f. Somehow the fft_direct block got the wrong size when used in the default fft_wideband_real. I did try to make the default sizes the smallest possible to reduce the size of the libraries and amount of redrawing needed. I have seen a scheme that Dave M (I think..?) uses where the default block is empty so redrawing is forced for anything useful. This minimises the library size and makes upgrades/changes simple as only the init script needs changing i.e no redrawing or replacing blocks in the libraries. Another thing on the list of TODOs... :) I have been compiling a design with Billy's FFT changes for a while now and so far things seem quite solid. The device is not very full so I am not sure about how the extra constraint affects timing in full designs, will try that next with the pocketcorrelator which is quite full. Regards Andrew
Re: casper-scm Commit 13b5978: rewrote butterfly_direct_init
Hi Mark Although, i've been having other issues with the newest commits. Namely, the pfb_wideband_real won't redraw properly. I think this is due to it still having the old adder_tree. The fix I made a while back to allow the use of DSP48s for the adders in the adder_tree meant that it is not backwards compatible. This means that you need to drag a new pfb_wideband_real into your design. The scripts try to reuse the existing blocks, just changing parameters, and this breaks as the old block does not have the same parameters. Regards Andrew
Re: casper-scm Commit 13b5978: rewrote butterfly_direct_init
Hi Andrew, Thanks for the reply. I think this is a problem with our repo, not kat's. I had dragged a new pfb_wideband_real from the bwrc repository. I then changed the number of inputs and it didn't draw. I think this is because when we update the adder_tree block with new parameters, the new version wasn't added to the PFB, so when the PFB mask script tried to run the new adder_tree mask script on the old adder_tree in the PFB, it broke. Mark On Wed, Dec 1, 2010 at 9:35 PM, Andrew Martens martens.and...@gmail.comwrote: Hi Mark Although, i've been having other issues with the newest commits. Namely, the pfb_wideband_real won't redraw properly. I think this is due to it still having the old adder_tree. The fix I made a while back to allow the use of DSP48s for the adders in the adder_tree meant that it is not backwards compatible. This means that you need to drag a new pfb_wideband_real into your design. The scripts try to reuse the existing blocks, just changing parameters, and this breaks as the old block does not have the same parameters. Regards Andrew
Re: casper-scm Commit 13b5978: rewrote butterfly_direct_init
Just a quick update pfb_fir will give problems as neither the script nor library block has been updated. Actually, pfb_fir is fine. The new parameters are not used in the scripts so it just uses the defaults and last_tap pulls in the correct adder_tree without needing to change parameter values. I need to make the choices visible to users and need to make other changes but it will work as is for the moment. Regards Andrew
Re: casper-scm Commit 13b5978: rewrote butterfly_direct_init
I haven't had any trouble compiling with the latest fft optimizations, but i think i know what your problem is. I just pushed something that should fix it. Can you pull from bwrc and try compiling again? On 11/29/2010 09:11 PM, Mark Wagner wrote: Hi Billy, I tried to compile a design with your modified fft_wideband_real and received the following error during system generation (see below). Have you been able to get a design to compile? Do you recognize the problem? Thanks, Mark HDL simulation model compilation failed. WARNING:Simulator:1010 - One or more environment variables have been detected which affect the operation of the C compiler. These are typically not set in standard installations and are not tested by Xilinx, however they may be appropriate for your system, so the flow will attempt to continue. If errors occur, try running fuse with the -mt off -v 1 switches to see more information from the C compiler. The following environment variables have been detected: Error occurred during Simulation Initialization. Reported by: 'gbtspec_mode01/fft_wideband_real/fft_biplex_real_4x0/biplex_core/fft_stage_1/butterfly_direct/cadd/DSP48E' On Tue, Nov 23, 2010 at 7:49 PM, William Mallard w...@llard.net wrote: When dsp48_adders is enabled, butterfly_direct now uses caddsub blocks for complex addition, halving the number of dsp48s used. To implement this, the block's init script needed to be almost completely rewritten to redraw the block. It also necessitated the string of recent changes to all fft-related masks, as well as the creation of the parameterized caddsub_dsp48e block. All existing fft unit tests pass. Billy
casper-scm Commit 13b5978: rewrote butterfly_direct_init
When dsp48_adders is enabled, butterfly_direct now uses caddsub blocks for complex addition, halving the number of dsp48s used. To implement this, the block's init script needed to be almost completely rewritten to redraw the block. It also necessitated the string of recent changes to all fft-related masks, as well as the creation of the parameterized caddsub_dsp48e block. All existing fft unit tests pass. Billy
