10-02-2018 10:14 PM
I am wondering if the optimization will cross clock domains as part of its optimization or will it only optimizes in one clock domain? I would hope that it would not cross a boundary but I cannot find any statement that Register Re-timing is clock domain aware.
Can anyone say for sure?
10-03-2018 08:43 AM
While I haven't seen any documentation that discusses this, I would have to assume that the tool will not cross clock boundaries. This would be illegal...
Furthermore, all the metastability resolution chains in your design (the back to back flip-flops on the destination domain) should all have the ASYNC_REG property set on them either in your RTL code or in the constraint file (the designer is required to do this). One of the functions of the ASYNC_REG property is to declare the cells as DONT_TOUCH - cells that have the DONT_TOUCH on them cannot be modified as part of register retiming or replication.
10-03-2018 09:23 AM
Thanks @avrumw. @nickh initiated this topic based on a question I asked him. I think the original question was slightly misunderstood, so I feel like I should add a bit of detail to the original post to assist the experts like yourself when answering.
Imagine we have a circuit in clk domain CLKA. The circuit in CLKA has two register stages that we are concerned with. The first stage contains multiple bits. The second stage contains a single bit, where stage_2 = f(stage_1). The single bit in stage 2 is then fed into a synchronization chain to help it cross into clk domain CLKB.
My question does not relate to retiming over crossing between CLKA and CLKB. Instead, I am curious if the tools will recognize that stage 2 in CLKA is feeding a synchronization chain in CLKB and, as a result, protect CLKA stage 2 from getting somehow retimed somewhere into the cone of logic between CLKA stage 1 and CLKA stage 2. You can assume that ASYNC_REG property is set on the synchro chain in CLKB and that a false path is set between CLKA and CLKB.
10-03-2018 10:39 AM
That is a good question.
Again, my assumption is that the tools understand this and will not push logic from before the stage_2 flip-flop to after, but I can't prove it. I have certainly never seen the tool do this (but I never use register retiming, so that isn't surprising), nor have I ever heard of the tools doing this.
The good news is that even if Vivado did do something like this, it would then be able to tell you that the resulting synchronizer is illegal. The report_cdc command analyzes all clock crossings, and determines if the structure around the clock crossing is "legal". The resulting structure (with combinatorial logic driving the first flip-flop on a different domain) will fail this check.
Finally, if you wanted to be certain that this couldn't happen, you could always put the DONT_TOUCH attribute on the stage_2 flip-flop - this would prevent the tool from doing any retiming that involves this flip-flop. But, again, I don't think this is necessary - I highly suspect that the tool will not touch this flip-flop.
(Or, alternatively, don't enable register retiming!)
10-03-2018 11:15 AM
10-03-2018 11:34 AM
From UG901 (v2018.2 p. 56):
Note: Cells with DONT_TOUCH/MARK_DEBUG attributes, cells with timing exceptions (false_path,
multicycle_path), and user-instantiated cells will block this attribute.
So, I am pretty sure that if you have a set_false_path or set_max_delay between the last FF on CLKA and the first FF on CLKB it will fall under the case of "cells with timing exceptions".
While this describes the "RETIMING_FORWARD" and "RETIMING_BACKWARD" properties, I suspect that it applies to global retiming as well.