Main Content

Optimization with Constrained Overclocking

Area and timing optimizations that you specify can result in upsampled rates, or overclocking, in your design. For example, when you use the resource sharing optimization, HDL Coder™ overclocks the shared resources by an overclocking factor (OCF). The OCF depends on the number of shareable resources and the value for the SharingFactor parameter that you specify. If your clock rate is high, overclocking can cause your design clock rate to exceed the maximum clock rate of your target hardware. To constrain the overclocking of your design, specify the an oversampling value using the Treat Simulink rates as actual hardware rates parameter or the Oversampling factor parameter in conjunction with clock-rate pipelining.

Optimizations that Overclock Resources

Area and speed optimizations and certain block implementations result in overclocking the resources in your design. For example, these optimizations and implementations can result in upsampled rates in your design:

  • RAM mapping

  • Streaming

  • Resource sharing

  • Loop streaming

  • Specific block implementations, such as cascade architectures, Newton-Raphson architectures, and some filter implementations

How to Use Constrained Overclocking

When using area and speed optimizations, you can specify constraints on overclocking by specifying an oversampling value for your model. To learn how to specify an oversampling value, see Specifying the Oversampling Value. If you want a single-rate design, you can use these parameters to prevent overclocking or limit overclocking within a range.

Suppose that you have a design that does not currently fit in the target hardware, but is already running at the target device maximum clock frequency, and you know that the inputs to your design can change at most every N cycles. You can enable area optimizations, such as resource sharing, and specify a single-rate implementation using the oversampling value of your model.

By default, the clock-rate pipelining optimization is enabled, and it works in conjunction with the oversampling value to make the DUT sample time slower than the actual clock rate. You can design your model at the sample time of your actual hardware, the data rate, and then enable the Treat Simulink rates as actual hardware rates parameter to let HDL Coder set an optimized oversampling value N for your design based on your model base rate and the clock rate. HDL Coder then has a latency budget of N cycles to perform the computation. In this situation, HDL Coder can reuse the shared resource at the original clock rate over N cycles, instead of implementing the sharing optimization by overclocking the shared resource.

Constrained Overclocking Limitations

When you constrain overclocking by enabling the Treat Simulink rates as actual hardware rates parameter or by setting the Oversampling factor parameter to a value greater than 1, the Clock inputs parameter must be Single.

Related Topics