Cdc single bit tester (cdc_single_bit_tester)

cdc_single_bit_tester is an asset in the ocpi.assets.misc_comps component library. Implementations include cdc_single_bit_tester HDL Worker (cdc_single_bit_tester.hdl). Tested platforms include xsim, zed.

Design

The cdc_single_bit_tester serves as a testbench for the single_bit cdc primitive. The single_bit primitive synchronizes a single-bit from the source clock domain to the destination clock domain. The output of the synchronizer is sent to worker’s output port.

For normal operation, the input signal must be sampled two or more times by the destination clock. To achieve this requirement when synchronizing from:

  1. Slow Signals into Fast Clock Domain:

The destination clock must be \(>=\) 2x frequency of the source clock.

  1. Fast Signals into Slow Clock Domain:

The minimum input signal width must be 2x the period of the destination clock and the input pulses must be separated by 2x src_clk cycles to ensure proper crossing of the CDC boundary. Depending on the phase and frequency relationship of the source and destination clocks, the generated pulse in the destination domain may be +1 cycle more than the input pulse.

See http://www.sunburst-design.com/papers/CummingsSNUG2008Boston_CDC.pdf - Section 4.4 and https://m.eet.com/media/1137372/17561-310388.pdf for more information on the 2x requirement.

The number of register stages used in the synchronizers is configurable. An optional input register may be used to register the input signal in source clock domain prior to being synchronized. When possible, it is recommended (default) to register the input signal in the source clock domain before sending it across the clock domain crossing (CDC) into synchronizers.

The cdc single bit tester worker uses the clock from the Control Plane as input to the clock generator. The output of the clock generator is used to drive the output port clock.

A block diagram representation of the implementation is given in Figure 151:

cdc_single_bit_tester block diagram.

Figure 151: cdc_single_bit_tester block diagram.

Interface

<ComponentSpec>


  <Property Name="src_clk_hz" Type="float"
                              Parameter="true"
                              Default="100000000.0"
                              Description="Source clock frequency"/>

   <Property Name="dst_clk_hz" Type="float"
                               Parameter="true"
                               Default="100000000.0"
                               Description="Destination clock frequency"/>

   <Property Name="num_input_samples" Type="uchar"
                                      Parameter="true"
                                      Default="15"
                                      Description="Number of input samples sent."/>
                                      
  <Port Name="out" Producer="true"/>

</ComponentSpec>

Properties

  • src_clk_hz: Source clock frequency.

    • Type: float

    • Access:

      • Parameter: True

      • Writable: False

      • Initial: False

      • Volatile: False

    • Default value: 100000000.0

  • dst_clk_hz: Destination clock frequency.

    • Type: float

    • Access:

      • Parameter: True

      • Writable: False

      • Initial: False

      • Volatile: False

    • Default value: 100000000.0

  • num_input_samples: Number of input samples sent.

    • Type: uchar

    • Access:

      • Parameter: True

      • Writable: False

      • Initial: False

      • Volatile: False

    • Default value: 15

Ports

Inputs:

None.

Outputs:

  • out

    • Protocol: None

    • Optional: False

Implementations

Dependencies

The dependencies to other elements in OpenCPI are:

  • assets/components/misc_comps/cdc_single_bit_tester.hdl/cdc_single_bit_tester.vhd

  • core/hdl/primitives/cdc/single_bit.vhd

  • core/hdl/primitives/cdc/cdc_pkg.vhd

Limitations

Limitations of cdc_single_bit_tester are:

  • None.

Testing

There are files used to validate the data the cdc_single_bit_tester worker sends. The files used in the verification were created from the output of the unit test when running the unit test in simulation and contain the expected output data when there is no metastability. Since there might or might not be a perfect match of the output data to the expected output data when running the tests in hardware due to metastability or phase offset, the output data is correlated with the expected output data. If there is at least a 0.7 positive Pearson product-moment correlation coefficient, then test case is considered passing. This correlation is only used when running the unit test on hardware. If the test are run in simulation, the output data is compared with expected output data. If they match exactly, then test case is considered passing.

References