How to synchronize register bank used in the IP Core

[kapatel]

Hello,

I have designed an IP Core and I am using some registers to contro
it.Generally Microprocessor writes into these register and IP Core read
these registers.My question is which is the best way to provid
synchronization between Microprocessor clock to IP clock if both clocks ar
different.Currently I am using 2-deep fifo to synchronize all m
registers.But I feel it occupies more resources.So would someone pleas
suggest me any other way?

Thanks,

Krupesh

---------------------------------------
Posted through http://www.FPGARelated.com

 

[glen herrmannsfeldt]

kapatel <94438@embeddedrelated> wrote:

I have designed an IP Core and I am using some registers to control
it.Generally Microprocessor writes into these register and IP Core reads
these registers.

When you say "reads these" what do you mean?

My question is which is the best way to provide synchronization
between Microprocessor clock to IP clock if both clocks are
different. Currently I am using 2-deep fifo to synchronize all my
registers.But I feel it occupies more resources.So would someone
please suggest me any other way?

To answer the question, you have to decide what happens under
various synchronization (or lack of) conditions?

In many cases, the output of registers are control lines, so not,
in the usual sense "read". In some cases, that means that bad or
unusual things happen if the register bits change on different
(on the IP core side) clock cycles.

Just to be sure you aren't confused, not that the problem is
not metastability (which is also a problem related to crossing
clock domains).

If you, for example, clock one register on one clock, and connect
its outputs to a register clocked with a different clock, it is
possible (and if you do it long enough, likely) that at some point
the second register gets some bits from the one clock cycle, and
some from the succeeding cycle. This is a form of race condition.
Again, depending on the system that may, or may not, be bad.

Now, consider how the FIFO works. The register contents gets
clocked into the FIFO. If it is immediately available at the output
(an option on some FIFOs) the same problem can occur as above.
The fix, then, is that the data isn't available until the following
clock cycle. Another feature of a FIFO is the subsequent input
data won't change the value at the output. (It goes into a different
FIFO cell.) But note that even that fails if you don't check the
FULL flag.

So, what you need is a register to write into, at least one clock
cycle of the fastest clock delay before it is read out, and a
guarantee that the first register doesn't change until the value
is read out. That is somewhat simpler than a FIFO. (The latter
guarantee can usually be arranged in the microprocessor logic.)

-- glen

 

[Mark Curry]

kapatel <94438@embeddedrelated> wrote:

I have designed an IP Core and I am using some registers to control
it.Generally Microprocessor writes into these register and IP Core reads
these registers.

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

So, what you need is a register to write into, at least one clock
cycle of the fastest clock delay before it is read out, and a
guarantee that the first register doesn't change until the value
is read out. That is somewhat simpler than a FIFO. (The latter
guarantee can usually be arranged in the microprocessor logic.)

Krupesh - you asked a very general question, so as Glen suggested, you need
to be a bit more specfic.

Glen's last paragraph generalizes things about as much as possible. I'll
rephrase it - the hardware must be designed to only sample the register when it
is known to be stable.

There are often times in some of my logic design, where I have registers
that I call 'Quasi-Static'. These registers are SW controllable,
but they're set at initializaion, and never reconfigured. At the time
they're set, the hardware is at a "don't care" state, since it's being
initialized.

For these type of registers, I don't do any synchronization at all. Just feed
the register cross clock domains, and you're done. (I've got hooks in place
to handle these timing exceptions inside the STA tools).

There's other similar registers, for instance in video design, where
registers are only updated during vertical blanking. I don't call these
"quasi-static" but they are similar in nature for the hardware - they're static
for when I care, only changing when they're not being used. They have 10s
or 100s of clock cycles to stablize before being sampled. These don't
get synchrononizers either.

FIFO's IMHO are overkill for "Control" register type synchronization, normally.
The exception is if that control register is changing often.

My 2 cents...

Regards,

Mark

 

Den mandag den 10. februar 2014 20.46.15 UTC+1 skrev Mark Curry:

kapatel <94438@embeddedrelated> wrote:



I have designed an IP Core and I am using some registers to control

it.Generally Microprocessor writes into these register and IP Core reads

these registers.





glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

So, what you need is a register to write into, at least one clock

cycle of the fastest clock delay before it is read out, and a

guarantee that the first register doesn't change until the value

is read out. That is somewhat simpler than a FIFO. (The latter

guarantee can usually be arranged in the microprocessor logic.)





Krupesh - you asked a very general question, so as Glen suggested, you need

to be a bit more specfic.



Glen's last paragraph generalizes things about as much as possible. I'll

rephrase it - the hardware must be designed to only sample the register when it

is known to be stable.



There are often times in some of my logic design, where I have registers

that I call 'Quasi-Static'. These registers are SW controllable,

but they're set at initializaion, and never reconfigured. At the time

they're set, the hardware is at a "don't care" state, since it's being

initialized.



For these type of registers, I don't do any synchronization at all. Just feed

the register cross clock domains, and you're done. (I've got hooks in place

to handle these timing exceptions inside the STA tools).



There's other similar registers, for instance in video design, where

registers are only updated during vertical blanking. I don't call these

"quasi-static" but they are similar in nature for the hardware - they're static

for when I care, only changing when they're not being used. They have 10s

or 100s of clock cycles to stablize before being sampled. These don't

get synchrononizers either.



FIFO's IMHO are overkill for "Control" register type synchronization, normally.

The exception is if that control register is changing often.



My 2 cents...



Regards,



Mark

you could also just make a single synchronizer between the "busses",
just like if you had a async memory interface

i.e. register the addr/data/write on the processor side, transfer to the peripheral side and do synchronous write

same for reads


-Lasse