Re: board - T562.jpg

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.

John

Seems the GUI-mafia just love RAM.. :)

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:

1. 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...
2. 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...
3. 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.

John

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.

That's one of the laws of software:

All programs expand to consume all available resources

I remember implementing a RAM test in 34 bytes, and a 16x16 integer multiply in < 50 bytes.

Cheers

PeteS

I once wrote an Eratosthenes' prime number sieve using the video display as an array memory (on a 4K machine).

You still count on your fingers?

Try taking off your shoes if you can stand the smell. That will almost double your counting ability.

If it did it would exceed your IQ by a comfortable margin.

You seem to have a fixation about where YOUR next banana will be inserted.

reserving about 1/4 of that for the program it should be able to go somewhere past 10,000 but not beyond 25,000.

And yet you constantly make comments about other people being gay, comments based solely on your own fixations. Based on experience?