Generate a Global Oversampling Clock

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:

Setting a value greater than zero for the Target Frequency parameter in the HDL Code Generation > Target pane.
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. As an example, consider the simplevectorsum_cascade model.

This model consists of a subsystem, vsum, driven by a vector input of width 10, with a scalar output. The following figure shows the root level of the model.

Subsystem contains vsum block in it.

The device under test is the vsum subsystem, shown in the following figure. The subsystem contains a Sum block, configured for vector summation.

The Sum of Elements block with In1 at the input port and Out1 at the output port

The simplevectorsum_cascade model specifies a cascaded implementation (SumCascadeHDLEmission) for the Sum block. The generated HDL code for a cascaded vector Sum block implementation runs at two effective rates: a faster (oversampling) rate for internal computations and a slower rate for input/output. HDL Coder reports that the inherent oversampling rate for the DUT is five times the base rate:

dut = 'simplevectorsum_cascade/vsum';
makehdl(dut);

### Generating HDL for 'simplevectorsum_cascade/vsum'
### Starting HDL Check.
### HDL Check Complete with 0 errors, 0 warnings and 0 messages.


### The code generation and optimization options you have chosen have introduced
    additional pipeline delays. 
### The delay balancing feature has automatically inserted matching delays for
    compensation.
### The DUT requires an initial pipeline setup latency. Each output port
    experiences these additional delays
### Output port 0: 1 cycles

### Begin VHDL Code Generation
### MESSAGE: The design requires 5 times faster clock with respect to the
    base rate = 1.
...

In some cases, the clock requirements for such a DUT conflict with the global oversampling rate. To avoid oversampling rate conflicts, verify that subrates in the model divide evenly into the global oversampling rate.

For example, if you request a global oversampling rate of 8 for the simplevectorsum_cascade model, the coder displays a warning and ignores the requested oversampling factor. The coder instead respects the oversampling factor that the DUT requests:

dut = 'simplevectorsum_cascade/vsum';
makehdl(dut,'Oversampling',8);

### Generating HDL for 'simplevectorsum_cascade/vsum'
### Starting HDL Check.
### HDL Check Complete with 0 errors, 0 warnings and 0 messages.

### The code generation and optimization options you have chosen have introduced
    additional pipeline delays. 
### The delay balancing feature has automatically inserted matching delays for
    compensation.
### The DUT requires an initial pipeline setup latency. Each output port
    experiences these additional delays
### Output port 0: 1 cycles

### Begin VHDL Code Generation
### WARNING: The design requires 5 times faster clock with respect to 
        the base rate = 1, which is incompatible with the oversampling 
        value (8). Oversampling value is ignored.
...

An oversampling factor of 10 works in this case:

dut = 'simplevectorsum_cascade/vsum';
makehdl(dut,'Oversampling',10);

### Generating HDL for 'simplevectorsum_cascade/vsum'
### Starting HDL Check.
### HDL Check Complete with 0 errors, 0 warnings and 0 messages.


### The code generation and optimization options you have chosen have introduced
    additional pipeline delays. 
### The delay balancing feature has automatically inserted matching delays for
    compensation.
### The DUT requires an initial pipeline setup latency. Each output port
    experiences these additional delays
### Output port 0: 1 cycles

### Begin VHDL Code Generation
### MESSAGE: The design requires 10 times faster clock with respect to 
    the base rate = 1.
...