Question on Metastability

Using a VirtexE part.  I have two banks of registers.  One is actually a 
32-bit counter running real slow at 1KHz (1mS time tag).  The other is a set 
of data registers that run anywhere from 100Hz to 100MHz.  I need to 
register the time tag set of registers into the variable frequency registers 
at predetermined... but variable intervals.  I can't do a majority vote with 
either clock because I don't know which will be running faster and I only 
have a couple clock periods to live with as far as delay.  I draw a blank on 
this one, does anybody have any ideas to this predicament?

I tried doing this with simple registering from one set to the other... And, 
as expected, I run into metastability problems several times per second.

TIA,
Ed 

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
32-bit counter as a Gray counter. Since only one bit changes at any
time, a not-totally-synchronous transfer never results in a serious
error. Afterwards, you can convertthe gray code back to binary.
Binary-to-Gray conversion uses one XOR per bit, and is very fast.
Gray-to-binary involves a ripple chain, and may be more challenging at
100 MHz, but I suppose you can do it off-line. Or you pipeline the
operation.

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

"Stephan Flock" <sflock@freenet.de> wrote in message 
news:dh354s$gcu$03$1@news.t-online.com...
> 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
>
> 

"Peter Alfke" <alfke@sbcglobal.net> wrote in message 
news:1127539632.607707.192720@g44g2000cwa.googlegroups.com...
> 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.


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


> My suggestion is to run the
> 32-bit counter as a Gray counter. Since only one bit changes at any
> time, a not-totally-synchronous transfer never results in a serious
> error. Afterwards, you can convertthe gray code back to binary.
> Binary-to-Gray conversion uses one XOR per bit, and is very fast.
> Gray-to-binary involves a ripple chain, and may be more challenging at
> 100 MHz, but I suppose you can do it off-line. Or you pipeline the
> operation.

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


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

GPE wrote:
<snip>
> 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.

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

GPE wrote:
> 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
>
> "Stephan Flock" <sflock@freenet.de> wrote in message
> news:dh354s$gcu$03$1@news.t-online.com...
> > 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
> >
> >

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:
<snip> 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.  

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....

> 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).

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