Component price:
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

Features
- 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.
Deliverables
- verified RTL code
- Access to detailed design documentation
- 1 year support and customization service.
slow signals synchronizer documentation
parameters table
parameters for typical synchronizer
|
Parameter |
Valid values |
description |
|
A2BWIDTH |
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 |
|
B2AWIDTH |
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 |
Direction/width |
description |
|
clka |
Input |
Clock signal for main domain A, free running clock, needs to toggle for proper functionality |
|
clkb |
input |
Clock signal for domain B |
|
resetb |
Input |
Active low reset signal, when asserted, mask would be set 0. |
|
a2b_datain |
Input [A2BWIDTH -1:0] |
Data bus to be transferred from clka to clkb |
|
b2a_datain |
Input [B2AWIDTH -1:0] |
Data bus to be transferred from clkb to clka |
|
a2binack |
Output |
Acknowledge, indicating that the data for transfer from clka to clkb was sampled |
|
b2ainack |
Output |
Acknowledge, indicating that the data for transfer from clkb to clka was sampled |
|
a2b_dataout |
Input [A2BWIDTH -1:0] |
transferred data bus from clka to clkb |
|
b2a_dataout |
Input [B2AWIDTH -1:0] |
transferred data bus from clkb to clka |
Functionality
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:

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.
Reset
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.
Assumptions
- 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.
Test Items
the below table summarizes the test items that were checked for the different decoders:
|
Item name |
Description |
|
Clock frequencies |
Check synchronizer for different clock frequencies |
|
Clock alignment |
Check different clock alignments |
|
|
|
To access the implementation information you need to use 35 credits (RTLery currency) or purchase the component.
Learn more about how it works.
Click here to buy RTLery credits
|
|
|
Learn more about how it works.
Click here to buy RTLery credits
