HDL-Coder Delay Balancing in Feedback-Loop workaround

Hi,

I am trying to generate HDL-Code from a Subsystem that looks like this:

Inside Subsystem 2 and 3 there is some combinatorial logic with multipliers, adders etc. that need Delay-Balancing and Pipelining to achieve the desired Clock-Frequency.

Unfortunately hdlcoder refuses to perform delay-balancing and pipelining. It tells me:

"Delay balancing unsuccessful because Delay introduced in feedback loop cannot be path balanced"

"Unable to insert required number of pipeline registers because the Block is in a feedback path"

Is there a way to perform these optimizations in Subsystem 2 and 3 as if there was no Feedback-Loop involved?

Kind regards

Niklas

Answer 1

[Steven Hatcher]

Hi Niklas,

There is an optimization that can leverage a faster clock in regions of logic running at a slower rate. It looks like your model's clock rate is 100 MHz, and subsystems 2 and 3 leverage 10x and 100x slower rates, respectively. If you are clocking these with a single clock (which generates a timing controller), then HDL Coder can optimize your slower rate logic in the feedback loop by upsampling it to 100 MHz and introducing latency from optimizations at the clock rate while leveraging any existing slower rate state/delays to avoid adding any data rate latency. This optimization is called Clock-Rate Pipelining. The extra data rate latency in the loop is the reason for the delay balancing errors you are experiencing.

Since this feedback loop contains multiple data rates, you will need to use the latest version of HDL Coder (R2022b) which adds support to Clock-Rate Pipelining for multi-rate designs which use Rate Transition, Downsample, and Repeat blocks. I also believe there is no need to request any oversampling by HDL Coder on your design since the faster 100 MHz rate should let Clock-Rate Pipelining know it has an opportunity to optimize the slower logic in subsystems 2 and 3.

If you are still experiencing delay balancing errors after following this suggestion, then you will need to look into the highlightClockRatePipelining.m file which is generated to help identify any obstacles to Clock-Rate Pipelining that may exist in your model.

Feel free to share any more findings or questions you may have.

Steven

[Steven Hatcher]

In general, we've made a lot of improvements to Clock-Rate Pipelining in R2022a and R2022b, as well as many other optimizations (you can check the release notes). I would highly recommend using a newer release if you are experiencing issues with delay balancing and feedback loops.

[智浩 刘]

Hi, I've recently been using the 2023b version and I'm still experiencing issues with delayed balancing and feedback loops. What should I do to fix it please? I feel very helpless.

[Steven Hatcher]

Can you take a look at the Delay Balancing Report in the Optimization Report? That is a good starting point. The report should be linked in the delay balancing error message. The report has been improved in R2023b.

One common issue we've seen is the old option PreserveDesignDelays when enabled prevents delay absorption. This option use to only affect Distributed Pipelining interactions, but now it also affects Delay Absorption. The option has been renamed to AllowDelayDistribution in R2023b.

https://www.mathworks.com/help/hdlcoder/release-notes.html?searchHighlight=allowdelaydistribution&s_tid=doc_srchtitle

Steven

[Steven Hatcher]

If you are modeling your algorithm at a slower data rate than the clock rate of your device, you will also want to leverage Clock-Rate Pipelining. There is a new optimization report for this optimization in R2023b, which should also be linked in delay balancing feedback loop error messages.

https://www.mathworks.com/help/hdlcoder/ug/clock-rate-pipelining.html

If you can't figure out what to do from those 2 reports, please respond with screenshots of the reports attached and I can try to help you.

[智浩 刘]

I'm very sorry, I misread the warning message, it was one of the previous tips.

The warning message that still exists is this: Unable to insert required number of pipeline registers because the block, MyBlock, is in a feedback loop and there are not enough latency budget at the output of the block. Number of registers required: 1; number of registers inserted: 0. Consider increasing the latency budget by adding more design delays in the feedback loop or using clock-rate pipelining.

It appears in this section of the Adaptive Pipeline Report.

Thanks very much！

Answer 2

[Alan Moses]

In some cases, when you have blocks inside a feedback loop, adaptive pipelining is unable to insert the required number of pipeline registers at the output. Delay balancing can then fail.

You may have to manually add/balance the delays in the loop. Refer this link for a similar explanation.