sync on multiple clocks

Hi all,

We have an FPGA that works on some crystal clock. This FPGA should
interface with a processor - the processor reads and write data
to the FPGA's registers. The processor bus has a clock of its own,
to which all the bus signals are synchronized. The frequencies of
the clocks are the same, but there is an unknown phase, of course.

The problem is to reliably get data from the CPU, while still working
on our own clock.

The favorite solution so far is double-sample the CPU signals, just
connect them to two registers, one after another, both on our clock,
this way the output of the 2nd register is stable (no meta-stability).
Note: the CPU generates no signals that last less than 2 full clock
cycles, thus allowing us to do this.

What do you think ?

Thanks in advance

Spur

Hello Spur,

> We have an FPGA that works on some crystal clock. This FPGA should
> interface with a processor - the processor reads and write data
> to the FPGA's registers. The processor bus has a clock of its own,
> to which all the bus signals are synchronized. The frequencies of
> the clocks are the same, but there is an unknown phase, of course.

..... and the phase changes over time, of course. I mean that both
frequencies are NOT the same but they are just similar. That is
the actual problem.

> The problem is to reliably get data from the CPU, while still working
> on our own clock.
>
> The favorite solution so far is double-sample the CPU signals, just
> connect them to two registers, one after another, both on our clock,
> this way the output of the 2nd register is stable (no meta-stability).
> Note: the CPU generates no signals that last less than 2 full clock
> cycles, thus allowing us to do this.
>
> What do you think ?

Hmmm, I think that is dangerous. Of course, the second register is not
exposed to high danger because it reads from an already synchronized
register that, however, shows the problems. So when the first register
samples an edge and outputs crap, the second register will sample crap
as well. "crap" means either meta-stable or a 1 or 0 when there should
be a 0 or 1. As far as I understood your application, the latter one
is what is killing you.

Besides the perhaps simplest solution of using really the same clock
for the FPGA and CPU I would go the following way:
1. The CPU-signals have to be sampled by the CPU-clock.
2. There is something like an asynchronous handshake-semaphore (e.g.
an RS-FlipFlop) that is set whenever a new CPu-vector has been sampled.
3. On the internal FPGA-side this semaphore has to be evaluated. If it
is set, data from the CPU-vector registers can be sampled by
internal registers driven by the FPGA-clock and the semaphore is
to be cleared.

Important additional notes:
- Depending on the CPU-bus, this might require an FPGA clock that is
faster than the CPU buc clock.
- The asynchronous semaphore shall be sampled by ONE AND ONLY ONE
FlipFlop on either clock domain.
When the semaphore has not changed, there is no problem. When it
has changed and causes metastability-effects on the register, the
following logic might see the semaphore unchanged. But that's not
a problem as it will see it changed very likely in the next cycle.
- In order to reduce metastability-problems even more (for the
case that they are propagated into the second-stage D-FlipFlops
and even further, you might want to daisy-chain more FlipFlops in
order to reduce the probability.
However, with every FlipFlop the reaction latency is increased.

Anyways, you see that this requires some "intelligent" logic that
bridges between your clock domain. As far as I know, it is impossible
to do such bridging just with some data-path registers.

Regards,
Mario

PS: Your question is actually something for comp.arch.fpga or
sci.electronics.design rather than this VHDL newsgroup!

Mario Trams

Mario Trams wrote:

> Besides the perhaps simplest solution of using really the same clock
> for the FPGA and CPU.

Yes! Put an oscillator and a zero-delay buffer chip with 4 or 8
outputs between the cpu and fpga.

Send the cpu, fpga and other peripherals their own copy.
Works great, no thinking required.

-- Mike

Mike Treseler