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)
