sync on multiple clock

[Spur]

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

 

[st]

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

i think why don't you use the same clock for both?
very often there is the option to use "external" clock on one of the xtal
pins.

have a look in the datasheet of the two parts...

but normal operation would be to have n data lines between the two devices
and then some lines for timing control, let's say a write and a read line.
the processor writes: first set all adress and data bits in one/two clock
cycles
then set write line to low in next cycle
hold all for 1 or better two (or more if required to give the cpld time to
take the data) cycles
in this time the cpld takes the data as soon as he sees the low on write.
after two (or more) cycles past the write low setting
the processor takes it high again and continues to work.

i think this is the pretty standard protocol thing for which you may find
lots of documentation...
but if you need it at highest possible speed sync the two units.


st

 

[Jim Thompson]

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

The way the big boys (e.g. Cray) do it is with DLLs
(delay-locked-loops).

...Jim Thompson
--
| James E.Thompson, P.E. | mens |
| Analog Innovations, Inc. | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| Phoenix, Arizona Voice480)460-2350 | |
| Jim-T@analog_innovations.com Fax480)460-2142 | Brass Rat |
| http://www.analog-innovations.com | 1962 |

For proper E-mail replies SWAP "-" and "_"

Why is it that Democrats can't debate politely?
And are only rude and interruptive.
Lack of mental capacity?

 

[Fred Bloggs]

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

This is not true- metastability due to D-input setup violations is
manifested by greatly increased propagation delay through the FF- so
there is no guarantee that the second FF even sees the signal.

 

[Wade Hassler]

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

Is it possible to route the FPGA clock (or some derivative) to the
processor?
The solution you found is good, but you'll always be yearning to get
back those sync-clocks.
Wade H

 

[Keith R. Williams]

Is it possible to route the FPGA clock (or some derivative) to the
processor?
The solution you found is good, but you'll always be yearning to get
back those sync-clocks.

I did this a while back. I used LVPECL clock generators to drive the
FPGA (Virtex-E) and then drive the processor clock with LVCMOS-1.5
outputs and SSRAM clocks using HSTL drivers from the FPGA. I reserved
FPGA clock resources for the processor clock and another for the SSRAM
clocks.

 

[Dana Raymond, a minor God]

Is the processor's interface to the FPGA synchronous or not? Of course it
uses its own clock to generate timing, but the interface doesn't require the
clock does it?

If the 'registers' are FF arrays (vectors) then asynchronous reads through a
processor interface mux are possible and very easy to implement. In other
words, you can read the register values without bringing the processor's
control signals into your clock domain.

If the 'registers' are in RAM, then see if your FPGA has dual port RAM in
distributed LUT memory or in memory blocks. Dual ported RAM allows
simultaneous synchronous writes at one port and asynchronous random (RAM)
reads from another.

If you have to reclock the control signals then I suggest you simulate a
testcase with sliding phase offsets to ensure reliable operation. Also see
if you can force the flop into the IOB. This should help with clock skew
between the control signals and provide timing stability from one fit to the
next.