hi ross, besides ryan's great new casper memo number 50, Performance optimization for Virtex 6 CASPER designs<http://dl.dropbox.com/u/2832602/roach2_timing.zip> May 2013 (Ryan Monroe)
you might also want to look at memo 43, Speed Optimization with PlanAhead<https://casper.berkeley.edu/wiki/Speed_Optimization_with_PlanAhead> - August 2011 (William Mallard) best wishes, dan On Tue, May 7, 2013 at 9:51 AM, Ryan Monroe <[email protected]> wrote: > Hi Ross, > > I just added a memo to the CASPER page. It was a study I did on meeting > timing for ROACH2, but it applies to ROACH1 and should be illuminating > w.r.t. timing closure on these parts. Using the techniques I describe > there /might/ get you to 325 MHz. Keep in mind that I was *completely* > unprofessional in that document. Don't go looking for something that can be > published in nature ;-) BUT you will get to see how I really feel about > Xilinx tools.... > > That said, your goal is pretty ambitious so be prepared for a struggle. I > support everything Andrew said below. Specifically, there is generally a > hard limit, past which adding more latency *never* helps. For instance, > with a multiply that is 18x25 or smaller, that limit is 4 (but Xilinx often > doesn't choose the optimal configuration so it's worse) DSP48 adds, it's > 3. for fabric adds, it's 1. Anything more than these numbers will almost > always hurt you, although less can help. > > I'm planning on being down at Caltech 3:30-4:00 today. If you want, I can > meet you and talk about it either before or after that slot? > > --Ryan > > On 05/06/2013 11:33 PM, Andrew Martens wrote: > >> Hi Ross >> >> The guys at Berkeley and Ryan would probably have more detailed advice >> (especially regarding hand-placement) but the following are some general >> guidelines if trying to optimise timing from within System Generator; >> >> 1. Adding latency to an operation in System Generator results in the >> following; >> a. Register stages are added to sections within the operation so as >> to pipeline things and allow higher speed operation. >> This is useful where pipeline registers exist in cores e.g the >> DSP48 multiplier core. It is also useful in operations that can be >> pipelined e.g the cast/convert block uses a sequence of >> operations. >> b. Once all possible register stages within the operation are >> exhausted, the remaining latency is allocated after the >> operation. This latency will be limited in the benefit it adds as >> it is normally implemented in a single slice >> (the look up table can act as a shift register in Xilinx FGPAs >> and the final register stage of latency is implemented >> using the register in the slice). >> >> This leads to the following tips; >> >> 1. Avoid long chains of asynchronous logic. Add latency to operations >> involving large fanout or fanin e.g muxes, adders, comparators, >> cast/convert. Do a bit of thinking and research on how the various >> operations would be implemented under-the-hood. >> >> 2. Register inputs and outputs of blocks. >> >> 3. Use the CASPER Delays/pipeline block instead of the System Generator >> delay block on critical timing paths (the pipeline block forces the latency >> to be implemented in a pipeline of register stages instead of being >> absorbed into a single slice). >> >> 4. BRAMs followed by Multipliers often cause timing problems as they are >> limited and location constrained. These occur in the pfb_fir and fft. Add >> lots of BRAM latency to help (at least 3 to start) and Multiplier latency >> (4 would be a start but adding too much adds register stages *after* the >> Multiplier which is pointless). >> >> 5. Any input/output to/from yellow blocks (especially FPGA pins) should >> contain a pipeline block with a latency of at least 2 (allowing one >> register stage near source and one near destination). >> >> 6. Check to see if the System Generator block you are using has timing >> related options e.g the cast/convert has a 'Pipeline for maximum >> performance' option. >> >> Cheers >> Andrew >> >> >> Hi All, >>> >>> I'm trying to get the ROACH1 to run at 325MHz (5GSPS) in a simple >>> spectrometer. This is obviously pushing the limits of the hardware - >>> I'm kind or arbitrarily tweaking the latencies in these blocks to try >>> and meet timing requirements. Are there any guidelines/notes I should >>> be following - i.e should certain latencies match such as Add and bram >>> where as say Fanout doesn't matter. Also are there any limits on these >>> - i.e say 20 rather than 2? >>> >>> I'm sure if my understanding of the PFB and FFT was more than minimal >>> this would be obvious... >>> >>> R >>> >>> >>> -- >>> Ross Williamson >>> Research Scientist - Sub-mm Group >>> California Institute of Technology >>> 626-395-2647 (office) >>> 312-504-3051 (Cell) >>> >>> >>> >> >> > >
