Multicycle Path Timing Constraints

In my model I have created multiple rates using rate transition blocks and that works fine if the ratio of the fast clock to slow clock is on the order of 20 or 50. However, I have one system where the clock rate is reduced by 2500 (50 MHz to 20 KHz) and rate transition blocks use a large amount of hardware resources. Instead, I use a delay block with an enable port and just pulse the enable signal every 2500 clocks. However, Simulink thinks everything is running at the original 20 ns rate and doesn't generate the correct multipath timing constraints. Is there a way to force simulink into thinking this path has a different clock rate without using a rate transition block or is there a way to tell HDL coder i'm manually creating the clock enable for certain logic?

Answer 1

[Kiran Kintali]

Handling Large Clock Ratios in Multirate HDL Designs : Automated Timing Constraints with HDL Coder

You have a multirate FPGA design where the fast clock runs at 50 MHz and a slow region runs at 20 KHz a clock ratio of 2500:1. Rate Transition blocks work well for moderate ratios (20x–50x) but become resource-prohibitive at 2500x because HDL Coder generates a large timing controller with a 2500-count counter, plus bypass registers and associated clock enable logic for every signal crossing that boundary.

You used a Delay block with an Enable port, manually pulsing the enable signal every 2500 clock cycles. This produces correct functional behavior in hardware but Simulink treats the entire path as running at the 50 MHz base rate (20 ns period). Consequently HDL Coder does not recognize the slow-rate region. The generated timing constraints assume single-cycle (20 ns) paths for logic that actually has 50 µs (2500 cycles) to settle. Synthesis tools over-constrain these paths, wasting routing resources and potentially failing timing.

Summarizing your core question:

Is there a way to tell HDL Coder / Simulink that a path has a different effective clock rate without using Rate Transition blocks, or to manually specify that certain logic uses a custom clock enable with a known multicycle relationship?

HDL Coder Multirate Architecture

How HDL Coder Handles Multiple Rates

HDL Coder supports two clock modes:

**Single Clock** (default) One primary clock at fastest rate; timing controller generates clock enables for slow-rate registers. Enable-based MCP constraints available.

**Multiple Clock** Separate clock ports per rate; no timing controller. MCP constraints **not** generated

In single-clock mode, the timing controller produces enb_1_N_0 signals (rate = 1/N, phase = 0) that gate Delay/register blocks operating at slower rates. HDL Coder can then auto-generate multicycle path (MCP) constraint files (SDC/XDC/UCF) that tell the synthesis tool these paths have N cycles to settle.

The Resource Problem at High Ratios

For a 2500:1 ratio, the timing controller needs:

• A counter counting 0–2499 (12 bits minimum)
• Phase comparison logic for each enable signal
• Bypass registers at every rate boundary

While the counter itself is small, each Rate Transition block also generates bypass registers and synchronization logic. For wide buses crossing the boundary, this multiplies significantly.Recommended SolutionsSolution A: Enable-Based Multicycle Path Constraints (Primary Recommendation)

This is the closest match to your existing approach.

You should restructure your model so that HDL Coder's timing controller recognizes the slow-rate region and auto-generates MCP constraints. The key insight: you do NOT need Rate Transition blocks to get MCP constraints; you need the slow-rate region to be bounded by registers operating at the slow rate with proper Simulink sample times.How to Set Up

1. Set sample times explicitly — Give the slow-rate subsystem/blocks a sample time of 50e-6 (20 KHz) instead of inheriting the 20 ns rate
2. Use Downsample/Upsample blocks (DSP System Toolbox) or Rate Transition blocks configured for minimal overhead at the boundary — these establish the rate relationship that the timing controller needs
3. Bound the slow region with registers — Add Unit Delay blocks at the slow rate (50 µs) at the input and output of the slow-rate region
4. Enable MCP constraint generation:hdlset_param(gcs, 'MulticyclePathConstraints', 'on'); hdlset_param(gcs, 'SynthesisTool', 'Xilinx Vivado'); % or appropriate tool
5. Disable CRP in the slow region — Clock-rate pipelining moves registers to the fast clock domain and defeats MCP:hdlset_param('model/SlowSubsystem', 'ClockRatePipelining', 'off'); hdlset_param('model/SlowSubsystem', 'AdaptivePipelining', 'off');

What HDL Coder Generates

For a 2500:1 ratio, the generated constraint file would contain:

**Xilinx Vivado (XDC):**
```tcl
# Multicycle constraints for clock enable: DUT_tc.u1_d2500_o0
set enbregcell [get_cells -hier -filter {mcp_info=="DUT_tc.u1_d2500_o0"}]
set enbregnet [get_nets -of_objects [get_pins -of_objects $enbregcell -filter {DIRECTION == OUT}]]
set reglist [get_cells -of [filter [all_fanout -flat -endpoints_only $enbregnet] IS_ENABLE]]
set_multicycle_path 2500 -setup -from $reglist -to $reglist -quiet
set_multicycle_path 2499 -hold  -from $reglist -to $reglist -quiet
```

**Altera Quartus (SDC):**
```tcl
set enbreg [get_registers *u_DUT_tc|phase_0]
set_multicycle_path 2500 -to [get_fanouts $enbreg -through [get_pins -hier *|ena]] -end -setup
set_multicycle_path 2499 -to [get_fanouts $enbreg -through [get_pins -hier *|ena]] -end -hold
```

These constraints are automatically generated no manual SDC/XDC authoring required. HDL Coder also adds direct_enable and mcp_info attributes to the generated HDL to ensure synthesis tools preserve the enable signal structure that the constraints reference.

• Enable-Based Multicycle Path Constraints
• Example: openExample('hdlcoder_clockdemo')

Solution B: Downsample / Upsample Blocks (Alternative to Rate Transition)

If you have DSP System Toolbox, Downsample and Upsample blocks provide an alternative to Rate Transition blocks for establishing rate boundaries with potentially less overhead and more control.

[50 MHz domain] → [Downsample by 2500] → [Slow Logic at 20 KHz] → [Upsample by 2500] → [50 MHz domain]

The Downsample block samples every 2500th input. The Upsample block inserts 2499 zeros between samples (or holds the value depending on configuration). HDL Coder recognizes these as rate-change blocks and generates the appropriate timing controller enables.Combined with MCP

When you use Downsample/Upsample blocks with MulticyclePathConstraints = 'on', the constraint file is generated for the slow-rate region automatically — achieving the same result as Solution A but with different modeling semantics and the added benefit of sample offset control.

Useful Reference Materials in HDL Coder:

• Enable-Based Multicycle Path Constraints https://www.mathworks.com/help/hdlcoder/ug/enable-based-multicycle-constraints.html
• Multirate Model Requirements https://www.mathworks.com/help/hdlcoder/ug/configuring-multirate-models-for-hdl-code-generation.html
• Usage of Rate Change and Constant Blocks https://www.mathworks.com/help/hdlcoder/ug/best-practices-for-rate-change-blocks-lookup-tables-and-constants.html
• Global Oversampling Clock https://www.mathworks.com/help/hdlcoder/ug/generating-a-global-oversampling-clock.html
• Using Multiple Clocks in HDL Coder https://www.mathworks.com/help/hdlcoder/ug/using-multiple-clocks-in-hdl-coder.html
• HDL Code Generation for a System with Multiple Independent Clock Domains https://www.mathworks.com/help/hdlcoder/ug/multiple-independent-clock-domains-hdl-code-generation.html

[John]

I tried doing what you had suggested by adding delay blocks with a sample time of 50 us. However, this generated ZOH boxes to appear next to the delay:

I then tried to run workflow advisor but I run into this error message:

I then add the explicit rate transition blocks but that causes me to have the same problem as before. I also tried to minimally configure them by clearing both options from the block properties but then i get this error in workflow advisor: