08-29-2017 10:38 AM
I am trying to compile a Vivado project based on a DSP SysGen IP. I include the constraints file generated by SysGen tools in my project along with IP source files. project compile fails due to lots of timing errors. the constraint file is basically a set of multicycle paths commands but it looks like it doesn't cover all the multicycle paths. I had this idea that some paths cannot be found in the search pattern because of replicated cells so I tried to change the original set_multicycle_path commands by replacing -of arguments with -include_replicated_objects as below:
set_multicycle_path -from [get_cells -of [filter [all_fanout -flat -endpoints [get_pins $rateCexMyModel2/Q]] IS_ENABLE]] -to [get_cells -of [filter [all_fanout -flat -endpoints [get_pins $rateCexMyModel4/Q]] IS_ENABLE]] -setup 2
set_multicycle_path -from [get_cells -include_replicated_objects [filter [all_fanout -flat -endpoints [get_pins $rateCexMyModel2/Q]] IS_ENABLE]] -to [get_cells -include_replicated_objects [filter [all_fanout -flat -endpoints [get_pins $rateCexMyModel4/Q]] IS_ENABLE]] -setup 2
I just replaced -of with -include_replicated_objects in -from and -to search patterns. the way it explained in ug835 it seems that -include_replicated_objects returns a superset of objects that include both original and replicated ones, Is that correct? if yes, can anybody explain what is wrong with this constraint command?
Any idea how I can add replicated cells to my set_multicycle_path constrants?
08-29-2017 10:49 AM
As explained in UG835, the -include_replicated_objects option requires a pattern search.
Unfortunately this cannot be combined with -of_objects in the same command, so your command just interprets the given objects as patterns which do not match anything.
Hope this clarifies,
08-29-2017 11:07 AM
So in this case, what you are trying to do doesn't make sense.
The way this multicycle path (MCP ) is constructed is based on the "all_fanout" command from a given pin. This means that the -from/-to contains any "cell that has an 'enable pin' that can be combinatorially reached from a given pin"
Using this mechanism, any replication that occurs would be covered by this constraint - a replicated FF would also be reachable from the same pin.
BUT, I worry (a lot) about this kind of constraint. The IS_ENABLE property of a pin is set on the CE of any flip-flop. However there are many optimizations that can be done to change the functional implementation of a "chip-enable" to one that doesn't actually use the CE pin. For example, if you use a MUX in front of a flip-flop that feeds back the output of the FF, this is the equivalent of a "chip-enable" functionality. However, in this case, the "enable signal" propagates to the D pin of the flip-flop (which doesn't have the IS_ENABLE property set) rather than the CE pin (which does).
So, I am not convinced that this constraint is "safe".
08-29-2017 11:18 AM
Thank you very much Avrum.
I guess I have a better understanding of what is wrong with the original MCP now. is there any way to include other functional implementations of chip-enable in this constraint?
08-29-2017 11:24 AM - edited 08-29-2017 11:25 AM
Doesn't the filter clause define a search pattern?
No, the [filter ... ] command filters a list by a certain condition, but it will still return the objects you got from [all_fanout ...] which are perfect for -of_objects but are not a pattern.
Hope this clarifies,