"get_cells -include_replicated_objects" doesn't return any object

[pzahedi]

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:

original line:

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

changed to:

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?

Thanks,

[hpoetzl]

Hey @pzahedi,

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,

Herbert

[pzahedi]

Doesn't the filter clause define a search pattern? 

[avrumw]

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".

Avrum

[pzahedi]

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?

[hpoetzl]

Hey @pzahedi,

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,

Herbert

[hpoetzl]

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,

Herbert

[pzahedi]

Thank you very much Herbert. 

[hpoetzl]

You're welcome!

All the best,

Herbert