The author assumes that FPGA works in a way similar to CPU, and makes various assertion. But the way it works is that it implements a logic/circuitry except that such logic/circuitry was specified by some bits in the memory (hence the word "programmable"). The logic stays unchanged and all bits in the memory that specifies the logic needs to be available at any given time, so the clock cycle is rather deterministic and there is no such thing as "caching" the bits that describe the logic. Granted, FPGA does interface with other components such as external DRAM so technically it could be affected by some caching behavior there, but it is highly unlikely that caching plays as big of a role as would be if it is run by a CPU.
The only design I can think of in an FPGA that would use a "DRAM cache" is a processor. And by definition, no one assumes processor code execution to be timing accurate to 10ns.
Lot of people use SDRAM with FPGAs.
http://www.google.com/search?channel=fs&q=fpga+sdram&...
SDRAM is used commonly with FPGAs for storing largish amounts of data at a reasonable price (static RAM is fast, predictable, and very expensive for large fast memory arrays).
SDRAMs are horribly complex state machine driven pipelined devices. On a system I was working on, a simple write operation to the SDRAM could vary from several clock cycles to 52 (IIRC) clock cycles, depending on what was going on before the "simple" write. I forgot what the worst case stack up was, but it was probably something about a refresh followed by a page miss that needed a precharge...
Trivia: The data throughput listed by SDRAM manufacturers is the best case sequential access fully pipelined scenario when all -nine- eight planets align.
Speculating here: The variability of SDRAM access latency is one reason for putting a high speed cache in front of it. For instance, the cache could be a simple FIFO operation to buffer the data to avoid dropping data when an operation got hit by a long latency stackup. The SDRAM may have the average throughput to handle the data stream, but the (unpredictable) major bumps in latency may required "cache" buffering to keep from dropping data.
An FPGA is not a magic, nondeterministic device, but nothing more or less than a lot of ordinary logic gates in one convenient package, implemented with bundles of small LUTs and flip-flops. If you don't use your FPGA to implement a memory controller or other device with variable latency, you don't get a device with variable latency.
Timing instruments can be challenging to design, but as a rule, they are fairly trivial to test (waves hands dismissively). I wouldn't look for the problem at the gate or RTL level in the timing gear... but the interface between the insanely complex detector hardware and the timing gear is harder to dismiss with hand waving. If there's a bug, it will be in some part of the system that can't be easily characterized for its so-called "residual noise" performance.
