How to synchronize register bank used in the IP Core

Hello,

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

Thanks,

Krupesh

--------------------------------------- Posted through

formatting link

Reply to
kapatel
Loading thread data ...

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

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

Reply to
glen herrmannsfeldt

glen herrmannsfeldt wrote:

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

Reply to
Mark Curry

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

Reply to
langwadt

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.