Delay balancing error using R2023b, but have not experienced this in R2017b

Hello,

I have currenlty updated my Simulink to R2023b from R2017b. In the past I have been abe to successfully build my models through the HDL workflow advisor or by script with no issues.

Since I have upgraded, to R2023b I am unable to build, as I receive the following error;

"Delay balancing unsuccessful because an extra 27 cycles of latency introduced by optimizations in the feedback loop cannot be offset using design delays for the loop latency budget"

What I do not understand is how the same Simulink project can build successfuilly with R2017b, but does not with R2023b?

I have done some breif reading and am aware of the suggestions, but I cannot help but think this is a settings related problem in the configuration parameters.

I have compared settings with a colleagues R2017b, and there are differences in relation to new settings that have been set in R2023b which do not exist in R2017b.

Can anyone confirm this could be as simple as that, or do I need to introduce latency with delay blocks?

It's hard to understand why the model would need to chage.

I can confirm the model is using clock-rate pipelining.

Regards

[Steven Hatcher]

Hi Dan,

There have been quite a few changes to delay balancing since R2017b. I recommend looking over our recent release notes.

One potential cause for the delay balancing error is a change to an option called PreserveDesignDelays in R2023b. This option was off by default, and I've seen many users turn it on in past releases. The option used to only preserve deisgn delays when using Distributed Pipelining, but now it also controls whether or not HDL Coder can leverage design delay to offset latency introduced by blocks and optimizations. The option has been renamed to AllowDelayDistribution, and it is on by default (option is inverse of prior option). If you had PreserveDesignDelays=on in your model, it will now show as AllowDelayDistribution=off in the same model in R2023b.

In addition to this change, there is also an improved Delay Balancing Optimization Report (also mentioned in the release notes). This report now gives detailed information on if delay absorption happened as well as what could have prevented it. This report is also directly linked in the delay balancing error message regarding feedback loops after that first sentence you quoted to help give contextual help when encountering these errors. Have you tried looking at it?

[Steven Hatcher]

There is also a new Clock Rate Pipelining Optimization Report in R2023b. If your design is using clock-rate pipelining to handle latency in feedback loops, it would also be good to take a look at it and see if there's any reported obstacles for the optimization. It is also linked in the delay balancing error message along with the Delay Balancing Optimization Report.

[Dan Lardner]

Hello Steven,

Yes I have viewed the obstacle that the error has reported on.

That still does not answer why this did not occur for R2017b.

I see below that Kiran has identified this is not expected operation, so I think we will have to go down the path of a tech support call to resolve this problem.

[Dan Lardner]

Hello Steven,

I apologies as I only read your second message. I have read your first posting now and I believe this is what the issue could be, however I have the inverse of what you described.

My colleagues R2017b has Preserve design delays off or "Unticked", however as you said R2023b Allow delay distribution is on by default "Ticked".

I have unselected "Unticked" this option and have begun another build. It's a very large model and takes a few hours to build, however the build failure has usually occured within in the first 45 minutes, so I will re-post to provide an outcome and if this solution has resolved the problem.

Thanks once again for your input.

Regards.

[Dan Lardner]

Hello Steve,

Unfortunatley this did not work, and ironically the error suggested to turn that setting back on. I have done that so I am back with the original configuration. However I added a delay downstream of the offending MATLAB function block and tried to build again. This time the same result, but the problem was with an assignment block. Needless to say I have added another delay block downstream of it also and it is currently building, so I will see what happens.

This just feels extremely odd to have to do this, considering in R2017b this is not a problem.

Regards.

[Steven Hatcher]

Hi Dan,

It is the the right configuration to leave AllowDelayDistribution set to on. That is equivalent to PreserveDesignDelay set to off. Sorry if that wasn't clear in my last message.

Let's try to resolve this problem in a phone call.

Steven

Answer 1

[Kiran Kintali]

The model fails code generation due to pipeline requests at the faster rate that need to be balanced. Need to review generated delay balancing reports and fix the blocks requesting the pipelines that cannot be balanced. More to follow on this.

[Dan Lardner]

Hello Kiran,

Thanks for the reply. Yes I agree with you.

I would be happy to have a tech support call to resolve this issue.

I am in Australia, however would be happy to take a call, so long as it is not in the early Hrs of the morning.

When can we organise this call?

It is especially important for the project that I am working on that this gets resolved very soon.

Regards.

[Kiran Kintali]

Please reach out to tech support and request a call with the dev team. Thanks