Hi Guenter, Your mileage may vary, and I don't know what the specs of your system are, but if it were me I'd start by drawing loose pblock constraints for the DSP and ram in each stage in the fft. I would suggest not going overboard with pipelining, which in my experience can frequently make things worse on roach2 designs. Pblocks for other modules which are naturally divided into stages (like the pfb or xeng) are also easy to make and can be really helpful. Even if you don't have timing errors in them getting their logic out the way of the fft will make a difference. Personally I'm not a big fan of constraining slice locations, unless there are very specific paths that give problems. Sounds like you might have already done this though (and I think everyone has a different strategy with planahead).
If you do find you want/need to make fft changes the 'proper' way of doing it is by modifying the fft draw scripts (the _init.m files in casper_library). This is a massive pain though, so I understand why you don't do that! At the very least, if you haven't done so already, you should black box your fft design (see the black boxing memo on the wiki) so that you can mess around with your fft independently of the rest of your model. If nothing else, this makes the compile cycle quicker - you can just regenerate the fft netlist and copy it into your build without running system generator again on your whole design. If you're hacking the block, it also makes it somewhat easier to version control your fft changes independent of whatever else may be going on in your top level model. Good luck! Jack On Mon, 26 Sep 2016, 02:56 Guenter Knittel, <gknit...@mpifr-bonn.mpg.de> wrote: > Hi Dave, > > > > >> Delving into the innards to make ad hoc changes makes it hard > > >> to go back because changing the mask dialog parameters will obliterate > > >> all the ad hoc changes. Ad hoc changes to latencies can also be tricky > > >> because other (possibly not so obvious) latencies might need > corresponding changes. > > > > You are absolutely right! On the other hand, what *can* I do? The original > design ran at > > 150MHz give or take, but the application required it to run at 250MHz. So > what are my options? > > > > Thanks, regards > > Guenter > > > > > > > > *From:* David MacMahon [mailto:dav...@berkeley.edu] > *Sent:* Freitag, 23. September 2016 17:55 > > > *To:* Guenter Knittel > *Cc:* casper list > *Subject:* Re: [casper] FFT speed optimizations > > > > > > On Sep 23, 2016, at 04:17, Guenter Knittel <gknit...@mpifr-bonn.mpg.de> > wrote: > > > > I guess normally one would do this by going to the Function Block > Parameters and setting > > the latencies accordingly. However, I have made so many manual ad-hoc > changes to the > > Simulink model that this is not an option any more. > > I’m sure this is not the best way in general to apply optimizations to the > design. > > Many of the high level CASPER DSP blocks allow the user to specify latency > values for things like multipliers, adders, and BRAMs in the block's mask > dialog box. That's probably the easiest place to change the amount of > latency for the underlying components. It's a bit of a blunt tool in that > it applies to entire high level block, but it's easy to use. Delving into > the innards to make ad hoc changes makes it hard to go back because > changing the mask dialog parameters will obliterate all the ad hoc changes. > Ad hoc changes to latencies can also be tricky because other (possibly not > so obvious) latencies might need corresponding changes. > > > > Dave >
