Generate a Global Oversampling Clock

R2026b

In many designs, the DUT is not self-contained. For example, consider a DUT that is part of a larger system that supplies timing signals to its components under control of a global clock. The global clock typically runs at a higher rate than some of the components under its control. By specifying a global oversampling clock, you can integrate your DUT into a larger system without using Upsample or Downsample blocks.

To generate global clock logic, you specify an oversampling value. The oversampling value expresses the desired rate of the global oversampling clock as a multiple of the base rate of your model. When you specify an oversampling value, HDL Coder™ generates the global oversampling clock and derives the required timing signals from clock signal. The global oversampling clock affects only the generated HDL code. The clock does not affect the simulation behavior of your model.

Specifying the Oversampling Value

You can use two different parameters to set an oversampling value for your model, depending on your design:

  • If you are modeling with actual hardware rates, enable the Treat Simulink rates as actual hardware rates parameter to set an oversampling value for your model automatically.

  • If you are modeling with relative rates in Simulink®, set the Oversampling factor parameter to a value greater than 1 to set an oversampling value for your model.

When you enable Treat Simulink rates as actual hardware rates, HDL Coder can automatically adjust the oversampling value for your model if changes in Simulink rate or target frequency occur, without requiring you to update the Oversampling factor manually.

Specify the Oversampling Value Using the Configuration Parameters Dialog Box

When modeling with actual hardware rates which means that the Simulink rates reflect data rates on hardware, you can specify the oversampling value for a global clock from the Configuration Parameter dialog box by:

  1. Setting a value greater than zero for the Target Frequency parameter in the HDL Code Generation > Target pane.

  2. Selecting the Treat Simulink rates as actual hardware rates check box in the HDL Code Generation > Global Settings pane.

When modeling with relative rates which means that the Simulink rates are normalized to a base rate of one, you can specify the oversampling value for a global clock from the Configuration Parameter dialog box by setting the Oversampling factor parameter to a value greater than 1 in the HDL Code Generation > Global Settings pane.

Specify the Oversampling Value from the Command Line

When modeling with actual hardware rates, you can specify the oversampling value for a global clock from the command line by setting the TargeFrequency property for your model and enabling the TreatRatesAsHardwareRates property by using the hdlset_param or makehdl functions. For example, to specify a target frequency of 200MHz and enable HDL Coder to set an oversampling value for your current model automatically, use these commands: 

hdlset_param(gcs,'TargetFrequency',200)
hdlset_param(gcs,'TreatRatesAsHardwareRates','on')

When modeling with relative rates, you can specify the oversampling value for a global clock from the command line by setting the Oversampling property with the hdlset_param or makehdl functions. For example, to specify an oversampling factor of 7 for your current model, use this command:

hdlset_param(gcs,'Oversampling',7)

Requirements for the Oversampling Factor

When you specify the oversampling value manually by using the Oversampling factor parameter:

  • The Oversampling factor must be an integer greater than or equal to 1.

  • The default value for the Oversampling factor parameter is 1. In the default case, HDL Coder does not generate a global oversampling clock.

  • Some DUTs require multiple sampling rates for their internal operations. In such cases, the other rates in the DUT must divide evenly into the global oversampling rate. For more information, see Resolving Oversampling Rate Conflicts.

Resolving Oversampling Rate Conflicts

The HDL realization of some designs is inherently multirate, even though the original Simulink model is single-rate. For example, when resource sharing maps multiple operators onto a single hardware resource, the shared resource must operate at a faster clock rate to process all operations in one input sample period.

Consider the sfir_fixed model, which implements a symmetric FIR filter with four multipliers. To open the model, enter:

slhdlc_demo_setup("sfir_fixed")

Set the SharingFactor HDL block property to 4 to share the four multipliers onto a single hardware multiplier. This requires four clock cycles per input sample, creating a clock rate that is four times faster than the base clock rate:

dut = "sfir_fixed/symmetric_fir";
hdlset_param(dut, SharingFactor=4);
makehdl(dut, ClockRatePipelining="off");
### The DUT requires an initial pipeline setup latency. Each output port experiences these additional delays.
### Output port 1: 1 cycles.
### Output port 2: 1 cycles.
...
### MESSAGE: The design requires 4 times faster clock with respect to the base rate = 1.
...

If the requested global oversampling factor is not a multiple of the inherent clock rate, HDL Coder displays a message and ignores the requested oversampling value. For example, an oversampling factor of 5 is incompatible with a clock rate that is four times the base rate because 5 is not a multiple of 4:

makehdl(dut, Oversampling=5, ClockRatePipelining="off");
### The design requires 4 times faster clock with respect to the base rate = 1, which is incompatible with the oversampling value 5. Oversampling value is ignored.
...

To avoid oversampling rate conflicts, verify that the oversampling factor is a multiple of any inherent clock rate in the design. For example, if resource sharing introduces a clock rate that is four times the base rate, valid oversampling factors include multiples of 4. An oversampling factor of 8 is compatible:

makehdl(dut, Oversampling=8, ClockRatePipelining="off");
### MESSAGE: The design requires 8 times faster clock with respect to the base rate = 1.
...

How Clock-Rate Pipelining Resolves Oversampling Conflicts

When the ClockRatePipelining HDL code generation parameter is enabled (the default), HDL Coder automatically resolves oversampling conflicts by extending the resource sharing schedule to fit the requested oversampling factor. The same oversampling factor of 5 that caused a conflict now succeeds:

makehdl(dut, Oversampling=5, ClockRatePipelining="on");
### MESSAGE: The design requires 5 times faster clock with respect to the base rate = 1.
...

Clock-rate pipelining resolves the conflict by stretching the sharing schedule from N cycles to M cycles, where N is the number of shared operations and M is the requested oversampling factor. The shared hardware still performs the same N multiplications (one per cycle during phases 0 through N–1), but the remaining M–N phases are idle. A gating signal makes sure the sharing counter only advances during the first N of M phases. The result is that N operations complete in an M-cycle window, matching the global oversampling clock.

For example, with the SharingFactor HDL block property set to 4 and the Oversampling HDL code generation parameter set to 5, the shared multiplier performs its 4 multiplications during phases 0–3 and is idle during phase 4. The hardware utilization drops from 100% to 4/5 (80%), but the design honors the requested 5x oversampling rate without conflict.

Because the ClockRatePipelining HDL code generation parameter is "on" by default, oversampling rate conflicts are rare. The conflict arises when clock-rate pipelining is disabled, because the sharing schedule is fixed and cannot accommodate a mismatched oversampling factor.

Other Scenarios That Produce Oversampling Conflicts

Oversampling rate conflicts can also occur in these scenarios:

  • Model references — If a referenced model is configured with resource sharing that creates an inherent clock rate, the top-level model's oversampling factor must be compatible with that rate.

  • Protected models — A protected model's internal clock rate is opaque and cannot be modified by clock-rate pipelining. If the protected model runs internally at a faster rate, the parent model's oversampling factor must be a multiple of that rate.

Target Frequency Limitations

When you use the Treat Simulink rates as actual hardware rates parameter, HDL Coder computes the oversampling factor as the ratio of the Target Frequency parameter value to the DUT base sample rate. The target frequency must be an integer multiple of the DUT base rate. Otherwise, HDL Coder cannot derive a valid oversampling factor and might instead generate a clock that depends on other HDL Coder optimizations. Choose a target frequency that is an integer multiple of the DUT base rate. For example, for a 48 kHz base rate, valid target frequencies include 48 MHz, 96 MHz, and 192 MHz.

When HDL Coder cannot derive a valid oversampling factor:

  • HDL Coder does not use the target frequency to determine the generated clock rate.

  • HDL Coder generates a clock that defaults to the minimum oversampling required by other HDL Coder optimizations, such as resource sharing or streaming.

  • HDL Coder might generate HDL code that operates at a clock frequency lower than the specified target frequency.

For example, consider a model with a DUT base rate of 48 kHz and a target frequency of 50 MHz. The ratio between the target frequency and the DUT base sample rate is 50,000,000 / 48,000 = 1041.67, which is not an integer. HDL Coder generates a 48 kHz clock.

Next, suppose the example model uses the resource sharing optimization in HDL Coder. The DUT has the SharingFactor HDL block property set to 100. Because the ratio between the target frequency and the DUT base sample rate is not an integer, HDL Coder generates a clock at 100 x 48,000 = 4.8 MHz instead of the requested 50 MHz.

See Also

Topics