ERROR: [XOCC-1] auto frequency scaling failed



I’m running into the following error when building a design:

ERROR: [XOCC-1] auto frequency scaling failed becaused the auto scaled frequency '26.7 MHz' is lower than the minimum frequency limit supported by the runtime (60 MHz).

…presumably the RTL design being generated is very inefficient, probably due to some error in my coding style. How do I go about finding out where the bottlenecks in my design are?



Hi Mark,

You presume correctly, most designs should run at 250MHz so generating one that can only run at 26.7MHz implies something’s wrong with your design. My advice is to run reco graph gen on the code and see what the generated graph looks like. This docs page will help you interpret the graph


Hi Mark,

If this only started showing up after the last release, it’s probably an issue with the way in which we are now being more aggressive with pipeline stage removal - which means trying to squeeze more combinatorial logic between each set of registers. We didn’t see any regressions in our internal tests so we probably ought to run some tests against your code. Is this the AES example you have up on GitHub?



Hi Chris,

I think its much more likely that my code is creating issues rather than your toolset.

I had a go at creating the graphs as Max suggested but it either errors out or times out, almost certainly another indication that there are problems in the code.

I’ll put the latest version of my AES example on Github in the next 10 minutes…



Chris, Max - I’ve done some testing with the graph generation and I think I’ve identified at least one function that seems to generate alot of logic and very little pipelining. Can you take a look at it and see if I’m on the right track?

I’ve put the code and its graph here:



Hi Mark,

That function looks like it needs some latches! Internally we’re compiling your code using an older version of our compiler that’s less aggressive about latch removal to see if that brings your design back up to speed. Depending on the results of that test we may need to make changes to the production compiler. In any case we’ll keep you posted.



Hi Mark,

We’ve done some internal testing with the code you posted and did find that we were being too aggressive in removing intermediate pipeline stages for graphs which are dominated by a large number of cascaded fork and join primitives (such as the complex permutations in your example). We’ve made some modifications to the cost functions which are used to drive pipeline stage removal and these will be available in the next compiler release scheduled for Thursday. It will be interesting to see if these fix the problems you were seeing.



Hi Chris,

I’ll give that a try when its available.

Is there some easy way to know the following for a single function:

  • latency (in clock cycles)
  • clock frequency achieved
  • resources used



Hi Mark,

We don’t offer that ability today, but we will discuss internally on how we can provide it.



Hi Mark,

We’ve released v0.17.5 with the fix we mentioned: v0.17.5 is released 🎉. We tested this release against the test case you provided, and found we could place and route with a 250Mhz clock.

Thanks for your help in finding this bug!



When I try to generate the graph for the test case ( I get an error message:

preparing graph
done. Graph ID: f82655a4-7fd5-4bbb-806d-5cb7c076002e

Error: unknown error occured


…maybe 'cos I have no build hours left?


You can make as many builds, sims and graphs as you like. We only limit the number of deployment hours you can use.

This appears to be a different problem. I’m investigating it now.


Hey Mark,

Looks like the graph generation issue is fixed now, but do let us know if we can help further.