0
\$\begingroup\$

This is a question spans two fields - HDL synthesis and timing analysis.

In the design I define clock with specific frequency, and if design has

always@(posedge clk or negedge reset_n) begin
    if(!reset_n) begin
        // some reset circuit
    else begin
        // some operating circuit
    end
end

will make timing analyzer treat every operating circuit register-to-register delay to one clock period.

Sometimes you need circuit to work on slower frequencies, but within the same clock domain, for example:

reg slowdown = 1'b0;
always@(posedge clk or negedge reset_n) begin
    if(!reset_n) begin
        // some reset circuit
    else begin
        if(slowdown) begin
            // some operating circuit
        end
        slowdown <= ~slowdown;
    end
end

and this slowdown works as a kind of clock select within the circuit block.

Question: are modern tools (I use Quartus) able to understand such slowdowns and adjust timing analysis appropriately, and if yes, how the synchronous always block must be designed for this to happen?

Please withhold talking deep about pure manual design constraining, as it is clear the universal way to solve the issue is to explicitly tell the tool about 2 clocks path between registers in this circuit. I am interested in having the tool implicitly understanding of clock slowdown in the circuit, and using it in its timing analysis.

\$\endgroup\$

1 Answer 1

2
\$\begingroup\$

TL;DR; Don't know about other tools, but for Quartus specifically, the answer is basically no, it can't figure it out for itself. Or perhaps rather it won't, it's pessimistic by design.

The "proper" way, to answer the title question, is to apply multi-cycle path timing constraints.


For Quartus, there is some discussion here about multi-cycle path analysis. It talks primarily about the case of two different clock frequencies, but also shows this example diagram which matches your specific case - using an enable to make a path twice as long.

Clock enable making path two cycles long

The key take away from that page is:

To accommodate the system requirements, you can modify the default setup and hold relationships by specifying a multicycle timing constraint to a register-to-register path.

In other words, the way to tell the timing analysis to treat such a path is multi-cycle is to tell the synthesis tool using a timing constraint. They give no other information to the contrary, no mention of settings or HDL constructs.


The reasoning for lack of automatic inference is likely that the timing analysis by design assumes by default the worst case scenario. You have to be explicit with timing constraints if you want to relax these checks.

If we want to play devils advocate and say, well maybe it should be able to, or at least have that option. Well then, firstly, how can the synthesis tool know? It would surely have to actively simulate the behaviour of the circuit - without doing so, it can't really know that slowdown is always just toggling, and that any transfers between pairs of registers it is controlling are therefore guaranteed to be multi-cycle paths.

In this very simple example, where the signal can literally do nothing but toggle, the developers could invest time in programming a way for the tools to search for these specific constructs. Searching for such loops in millions of registers, and then searching for all of the registers that are then controlled by this toggling signal, then searching for all the paths between such controlled registers would be tricky.

If you then start adding in reset signals, the whole thing gets even more difficult. If the reset was asserted for one clock cycle, while slowdown was high, then there could actually be a register-to-register transfer that has only one clock cycle to complete. How then can it guarantee that the registers come out of reset on the same clock edge that the slowdown signal goes high (in this example), and that the reset is longer than one clock cycle? It can't.

And then there are the side-effects. You have written part of the design that you know is a multi-cycle path. But as we all know, these synthesis tools are rather wonderful at finding optimisations and patterns that the designers simply couldn't (without a lot of time finding them), after all, that's why we use behavioural constructs rather than gate level design. In it's infinite wisdom, it could find paths in the design that satisfy its ideas of multi-cycle paths, but what if they were in places that we hadn't noticed and worse what if were wrong?

In such cases then the only way it knows for sure is if you explicitly tell it that you will ensure this is the case - or have made the design able to tolerate it not being the case. You do this by telling it that the path is allowed to be multi-cycle.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.