Slow signals synchronizer


Slow signal synchronizer offers a solution for transferring relatively slow and static vectors across clock domains without risking meta-stability and coherency problems resulting from partial vector synchronization. The synchronizer is most suitable for configuration and status synchronization. This component contains a verified RTL code of the bidirectional slow signal synchronizer with parametric data bus width in each direction. The purpose of the slow signal synchronizer is to transfer slow changing signals between two clock domains. It is most useful for transferring control registers and configuration to a block in another domain without risking meta-stability that may lead to wrong operations and unexpected behavior. The synchronizer allows the transfer of wide vectors across clock domain independently of clock frequency ratio and with minimal timing requirements. The synchronizer is capable of transferring data at a period of 8 clocks (measured by the slower clock) which is typically sufficiently fast for software controlled operations.

Block diagram

slow signal synchronizer block diagram



  • Transfer new information across every ~8 cycles.
  • Bidirectional data synchronization with the same control logic.
  • Verified sampling, no new data is sampled until previous sample is verified to have been transferred across.
  • Every write to the synchronizer is acknowledged, so user can be sure it will be transferred before changing the input.
  • Minimal number of flops, sampling every 8 clocks
  • Simple timing requirements with predefined naming convention for constraints
  • Suitable only for level signals, not to be used for pulses
  • The Synchronizer is sampling on both sides during reset so reset values may propagate.
  • Asynchronous reset, capable of clearing both sides of the synchronizer.


  • verified RTL code
  • Access to detailed design documentation
  • 1 year support and customization service.

parameters table

parameters for typical synchronizer


Valid values



1 bit or more, cannot be set to 0

the width of the the vector to be transferred across the domains from clka to clkb


1 bit or more, cannot be set to 0

the width of the the vector to be transferred across the domains from clkb to clka





Interface table

Signal name





Clock signal for main domain A, free running clock, needs to toggle for proper functionality



Clock signal for domain B



Active low reset signal, when asserted, mask would be set 0.


Input [A2BWIDTH -1:0]

Data bus to be transferred from clka to clkb


Input [B2AWIDTH -1:0]

Data bus to be transferred from clkb to clka



Acknowledge, indicating that the data for transfer from clka to clkb was sampled



Acknowledge, indicating that the data for transfer from clkb to clka was sampled


Input [A2BWIDTH -1:0]

transferred data bus from clka to clkb


Input [B2AWIDTH -1:0]

transferred data bus from clkb to clka



The synchronizer achieves safe synchronization by spacing out in time the sampling of the data in the two clock domains so each sample is guaranteed to have a stable input driven by the other domain. The below waveform shows the behavior of the synchronizer:

slow signal synchronizer waveform

The acknowledge signal enables the driving logic to sequence events on the synchronizer and be sure all of them were transferred to the other clock domain. Each time the ack signals is asserted, it indicates that the synchronizer has sampled the input data and the other domain will surely see it. If the synchronizer is only used for very slow changing signals, the ack functionality can be ignored.


The synchronizer is using asynchronous reset and the assumption is that it can reset both clock domains. The synchronizer will start to toggle from the reset de-assertion.

During the reset both sides of the data path will be open for free sampling. This will accommodate situations where the reset value of the synchronized bus needs to be available at the synchronizer other end. This functionality is dependent on both clock running during reset, and the reset value to be transferred across is static. In case the clocks are not toggling during reset assertion, the reset value of should be separately set in both sides outside the scope of this synchronizer.


Test Items

the below table summarizes the test items that were checked  for the different decoders:

Item name


Clock frequencies

Check synchronizer for different clock frequencies

Clock alignment

Check different clock alignments





  • The main clock domain clock (domain A) is free running and required to constantly toggle for proper operation.
  • There are no limitations to reset of both sides of the synchronizer with the same asynchronous reset.
  • During reset, the data inputs are stable, preventing meta-stability between the synchronizer domains.

Timing considerations

The timing arcs of this synchronizer should be treated as any other synchronizer. Typically a maximal delay is checked between the two clock domains in order to ascertain that there are no timing issues resulting from placement and routing of the signals. The timing requirement of the synchronizer is to limit the delay of the signals crossing between the domains to 2 cycles of the faster clock but due to its specific design the synchronizer will hold for 3 cycles as well.