01-31-2018 11:36 AM
I use Vivado for Synthesis and compilation in non-project mode.
In the past, when I assigned XDC constraints to a signal, I usually also added a KEEP (or DONT_TOUCH) attributes to the signals to make sure they were not deleted and make sure that the constraint were applied.
Unfortunately placing KEEP and DONT_TOUCH on registered vctors or records can cause problems where only a subset of signals are actually used. In both cases I have seen that registers are instantitated with some strange feedback logic (that uses unnecessary resources and sometimes breaks timing!)
To better define what I would like to do: we have common modules with registers for large records which require Multi Cycle (MC) paths. The following are the potential topologies for individual bits of the multi-cycle constraint record registers with the desired outcome:
If I add a KEEP constraint, the registers I would like to see dropped are still there with the funny loopback topology, even after compile time optimizations (with a KEEP I would have thought that post synthesis stages would have trimmed these out, but they don't, and sometime do not meet timing!).
Here is my question . . . if I remove the KEEP attributes and load the MC XDC constraints prior to synthesis (I use non-project mode), am I guaranteed that the MC constraints are applied correctly and that optimization does not rebalance the logic across the registers potentially breaking my MC path timing?
NOTE: I tried this and it seems to work, but I want to make sure that it was not just a fluke, as it would be very hard to debug if the MC paths get applied incorrectly.
01-31-2018 11:46 AM - edited 01-31-2018 11:52 AM
In theory, if you've applied valid MC timing constraints on the registers, Vivado should take this into account during back end mapping and retiming.
I would propose something that will go a step further. Use a custom VHDL attribute on the register to mark it for multi-cycle timing, then run a script after design optimization (opt_design) and before placement that dynamically creates the multi-cycle timing on the marked registers. This way, you won't have to maintain an XDC file as you modify the design. Just creating a new register in the RTL will be enough to get it constrained by the script. [EDIT] After 30 seconds of thought, I realize this approach won't relax the timing for synthesis the way you get with your approach. This may result in a higher LUT usage as it tries to meet single cycle timing on the register inputs.
02-01-2018 05:26 AM
I would rather not do anything special as long as the tools are already ensuring correct application of the XDC constraints without a KEEP attribute when the constraints are loaded and applied to the synthesis step. Intuitively, I would think it should be ok . . . but I have not been able to find anything written, and this is a pretty important detail.
Does anyone know for sure?