Question on Metastability

If I understand you right, you need to copy the 32-bit counter ontent (which changes very slowly) into a fast-changing (fast-clocked) register at asynchronous times. I am sure that your problem is not metastability, but rather timing uncertainty between the 32 register bits. My suggestion is to run the

As is often the case,,mtastabilty gets blamed here for a completely different (and more solvable) problem. Peter Alfke, Xilinx Applications

You could run both your 32-bit counter and the other set of registers off a fast (e. g. 100 MHz) clock. Detect the edge of the 1 kHz counter clock signal and make it a clock enable for the counter together with the 100 MHz clock.

HTH, Stephan

I agree with Stephan. Making the whole design synchronous is the best solution. I was overly concerned with pointing out that the problem has nothing whatsoever to do with metastability, and I overlooked the simpler solution. Synchronous is the way to go, whenever possible. Peter Alfke, Xilinx (from home)

But - I have an oddball case of a clock. One always runs at 1Khz. The other *May* run as fast as 100MHz but usually runs slower -- sometimes as slow as 100Hz. If I knew my variable clock was always fater than the 1KHz clock, the edge detection would work fine.

Incidently, I already have a circuit similar to what you have in one of my other designs which does have a guaranteed fast clock.

Thanks, Ed

Yeah, I agree - I normally just lump them together although I shouldn't.

I never thought of a gray counter. I'll look into this as it may be a better solution. I can always pipeline the conversion - I do have a dozen or so cycles to play with before I need to get the result out.

Thanks, Ed

What about dual port memory, or perhaps a special FIFO, given the extreme clock ratios ? [and the gray counter as well, for safety..]

-jg

The obvious solution would be to use a third clock of known higher frequency. If this isn't avaliable, you could add hardware to detect which clock is running faster, but that may be more work than it's worth, especially if your variable rate clock changes frequently.

This would be a good time to add 2 cents worth on the virtues of having a free-running clock in an FPGA (as were in early Xilinx parts). Many newer parts have internal oscillators for configuration but the clocks aren't available to the routing fabric. I've seen some threads here about building oscillators in the FPGA from internal LUT delays and the like. I wouldn't like to depend on that sort of design due to variances in process and temperature. For future designs, however I would suggest always having a fixed clock of sufficient frequency to feed a DLL (unless you can't afford the crystal which would be unusual in most designs containing an FPGA).

Regards, Gabor

Gabor wrote: This would be a good time to add 2 cents worth on the virtues of

However, those variances actually self-track, so a Logic Element + Routing derived clock can be self-margining.

Lattice have added a usable clock to their MachXO, so this might catch on....

There is another class of Osc, called the Calibrated On Chip - these are now common in small Microcontrollers, and achieve in the regions of 1-2-3% stability over Vcc and Temp.

Ideal would be both; The first type would be easy for the FPGA vendors to offer as simple IP blocks, but the CalOsc is needs special HW, and a mindset change in the FPGA sector, so is less likely.....

-jg

The original question has been answeed: I still stand behind my suggestion in #2 in this thread. A self-contained stable oscillator is a difficult (if not impossible) proposition. All transistor parameters have unacceptable variation over temp, voltage, and processing. Metal resistivity and capacitance are fairly stable, but how do you make an oscillator out of that? Peter Alfke

Depends on what you mean by stable and acceptable.

Certainly to RS232 standards is achievable today.

For some background reading, look at the Philips LPC9xx family, and the Atmel AVR series. They have impressive On-Chip osc performances.

Also look here (even more precise) :

they show Silicon Oscillators, spec'd to ~1%. and targeting ceramic resonator applications. They also have Spread spectrum Silicon oscillators.

More esoteric are the still experimental 'machined silicon' oscillators

- more special process handling, but precisions getting close to low end quartz crystals.

There are many apps, where even 2% is more than precise enough, and others where +/-20% would be fine.

-jg

This worked quite well. I left my 32-bit binary counter alone (hey, I'm lazy!) -- added a binary to gray code converter on the output. Registered that using a higher clock that was used to derive the 1KHz clock - so I get a nice, registered gray code.

With the higher frequency clock, I register the gray code at the required time interval. Perform a gray code to binary conversion to get back to my original value. Luckily, I have several clock periods worth of time to bring back the original binary value as this piece of the puzzle isn't real fast. Now all I have left is a 1-bit ambiguity - which is quite reasonable.

Thanks, Ed