Rob, my best FPGA guy, has given up on using the Xilinx 8.2/sp3 IDE software... it's way too flakey. But he says the underlying chunks work fine from the command line, so he put together a "make" thing to process the chip we're working on. So it looks like the core fpga-crunching software was coded by people who know what they're doing, and the IDE wrapper (which runs in 90 megabytes of ram!) was coded by Windows programmers.
The gate signal is totally async to the clock. We're sort of hoping that the output of the logic block is either going to go high or not. A metastability glitch within a Spartan3 flip flop is (optimistically) narrower than the inter-cell routing can propagate. We'll have to try that and see. I could put setup and hold time requirements on the trigger gate specs, and make it the customer's problem!
The downstream logic has to work at 80 MHz max. So if we experimentally tune the BUFG output width to, say, 4 ns, we should have a pretty good margin both ways. Most silicon processes seem to be pretty stable these days.
I suppose we could make the delay tunable through a register our uP could write, and we could check a test point now and then to make sure we have it right. Just a mux selecting delay-line taps would work. We only need to do this once in the product, and it's important, so this is worth some hassle. The trick is, I suppose, to only take risks when you really need to.
I'm not sure I understand your problem, so I'll ask a few more questions. What is the speed of the clock in the design? How often does the internally clocked CE signal gate the external signal to generate a clock pulse? If the external signal will not generate a clock edge on every internal clock there might be an easier way to do this that does not depend on timing delays. It can generate a clock enable signal that is asserted on every other clock cycle. But this may or may not work for your application.
The product is a digital delay generator. Given a customer trigger, it generates four pulses, each programmable for delay and width from the trigger. There are three clock nets on the chip:
Trigger, qualified by a separate gate signal, firing this one-shot. This is the customer's TRIGGER input, any rate from 0 to 80 MHz. This drives a bunch of logic, including optional gate/countdown/burst logic, all of which starts...
A non-continuous delay-generator clock. Following the trigger, we start a gated 50 MHz oscillator that's used to time out 8 coarse delays in 20 ns ticks (rise/fall of each of the 4 outputs). Off-chip analog fine delays trim the actual edges to 10 ps resolution. This 50 MHz clock is phase-locked to...
A 40 MHz clock, from a TCXO.
A digital PLL thing longterm locks the customer-triggered 50 MHz clock to the local 40 MHz crystal oscillator but keeps the 50 MHz thing phase-coherent to the customer trigger, so the delay outputs don't jitter.
Given all these clocks, and all the signals making multiple passes on and off the chip, we're getting output jitters in the ballpark of 50 ps RMS, which ain't bad. Our bigger benchtop DDGs have jitter in the 8 ps range, but their critical paths are power-hogging PECL.
Generating accurate, low-jitter delays from a random trigger, but with crystal-oscillator accuracy, is an interesting problem in general, and it's been approached a lot of ways. We think ours is nicely suited to implementing in an FPGA with minimal external stuff. Our main limitation seems to be on-chip crosstalk and maybe a bit of ground bounce.
I can't say I really understand what you are doing. Obviously how you are solving this problem is something that is too complex for a verbal description without diagrams and detailed explanations. But thanks for trying.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.