I simulate my code at edaplayground.com, using Synopsys VCS. You can paste the code there to run.

A toggle synchronizer will work, but you have to ensure the signal from the source will not change too quickly to be captured in the destination domain, in the fast to slow synchronization case. In that design it was a datapath that I needed to synchronize across the clock domain, so I used this asynchronous FIFO. I think for any CDC, there will always need to be assumptions about the range of ratios between the two clocks that has to be taken into account in the design.

“In a memory controller design I worked on, the destination clock can take on three different frequencies, which can be either faster/slower/same as the source clock. In that situation, it was not easy to design the clock domain crossing signals to meet the 1.5x cycle width of the slowest destination clock.”

So what was your approach? I hope you were looking for a generic solution for slow to fast and fast to slow CDC. A toggle synchronizer (which has a pulse to level converter at the source side and edge detector at the receiver side) will work here I think.

Hi. I assume you’re talking about coarse grained clock gating, where you are writing new custom logic to gate the clock when the logic is idle (and not fine grained clock gating, which is “automatically” inserted by synthesis tool). For coarse grained clock gating, you can imagine there is a tradeoff between how much logic you gate at once versus how complex the clock gating logic is. The more you gate at once, the simpler the logic, and vice versa. For designs I work on, our policy/guideline is to gate at a “design block” level, which consist of several to tens of modules. What that means is the clock gating will generally encompass alot more logic than just the synchronizer pair. You would determine an idle condition for all that logic (including the synchronizer, and across the two clock domains), then instantiate a clock gate surrounding all that logic. That’s just the guideline that my team uses. Clock gating design is very dependent on your overall low power methodology, which may be different from company to company, from team to team.

I am considering clock gating for power saving.

May I know how would your synchronizer pair circuit works in clock gating situation ?

That’s a really good question, but unfortunately I don’t have any information on that. Formal property verification of asynchronous designs I think is kind of a hack, as there is no equivalent way to express asynchronous designs in formal property verification tools (you can kind of fake it by allowing one clock to toggle on any edge of the other clock). To properly verify CDC I think linting or CDC verification tool (which can be formal based as well) will yield better results.

Hi Promach. Let’s take the Multi-cycle path (MCP) formulation with feedback design. It requires the source side logic to assert and hold src_send to indicate sending a data bit (on src_data_in) until src_rdy is asserted. After that, src_send must de-assert, then re-assert a later cycle to send the next data bit. Therefore, to send two consecutive bits of zeros or ones would require two src_send/src_rdy handshakes, with at least one idle cycle (src_send=0) in between.