cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Participant
Participant
1,378 Views
Registered: ‎12-19-2018

[Common 17-161] Invalid option value '20.000 20.000' specified for 'value'.

Jump to solution

Hello,

 

Since I've done some minor changes to the clock source of a design, I'm getting more than 100 critical warnings.

Each critical warning is related to a FIFO constraint.

Looking into the FIFO xdc file, I'm getting errors for each "set_bus_skew".

 

Here's the complete error message for a single FIFO:

[Common 17-161] Invalid option value '20.000 20.000' specified for 'value'. ["sources_1/ip/ddr3_data_sync/ddr3_data_sync/ddr3_data_sync_clocks.xdc":63]

[Common 17-161] Invalid option value '20.000 20.000' specified for 'value'. ["sources_1/ip/ddr3_data_sync/ddr3_data_sync/ddr3_data_sync_clocks.xdc":66]

 

I've checked post-synthesis schematic, and all clock tree seems to be connected and valid.

I've reset & generated the output products for all FIFOs, but the issue still remains.

Did anyone face a similar issue already?

 

Any hint or guidance is highly appreciated.

 

 

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Moderator
Moderator
1,291 Views
Registered: ‎01-16-2013

@squaringcircle 

 

I have sent you email from ezmove where you can upload the project archive and send it back.

50.00000000000000000 36.87200164794921900 36.87200164794921900

The above value is incorrect. The return value skew_value should return on one number.

 

--Syed

 

---------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.

Did you check our new quick reference timing closure guide (UG1292)?
---------------------------------------------------------------------------------------------

View solution in original post

12 Replies
Highlighted
Moderator
Moderator
1,336 Views
Registered: ‎05-08-2012

Hi @squaringcircle 

This message looks to be indicating incorrect command usage, or a constraints syntax error. Can the full text of the constraint be added?


-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------

 

---------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
---------------------------------------------------------------------------------------------
0 Kudos
Highlighted
Participant
Participant
1,324 Views
Registered: ‎12-19-2018

Hi @marcb ,

 

Thanks for getting back on this topic.

 

Here's the complete constraint:

 

################################################################################
#------------------------------------------------------------------------------#
# Native FIFO Constraints #
#------------------------------------------------------------------------------#

set wr_clock [get_clocks -of_objects [get_ports wr_clk]]
set rd_clock [get_clocks -of_objects [get_ports rd_clk]]
set wr_clk_period [get_property PERIOD $wr_clock]
set rd_clk_period [get_property PERIOD $rd_clock]
set skew_value [expr {(($wr_clk_period < $rd_clk_period) ? $wr_clk_period : $rd_clk_period)} ]


# Set max delay on cross clock domain path for Block/Distributed RAM based FIFO

set_max_delay -from [get_cells inst_fifo_gen/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.gcx.clkx/*rd_pntr_gc_reg[*]] -to [get_cells inst_fifo_gen/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.gcx.clkx/*gsync_stage[1].wr_stg_inst/Q_reg_reg[*]] -datapath_only [get_property -min PERIOD $rd_clock]
set_bus_skew -from [get_cells inst_fifo_gen/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.gcx.clkx/*rd_pntr_gc_reg[*]] -to [get_cells inst_fifo_gen/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.gcx.clkx/*gsync_stage[1].wr_stg_inst/Q_reg_reg[*]] $skew_value

set_max_delay -from [get_cells inst_fifo_gen/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.gcx.clkx/*wr_pntr_gc_reg[*]] -to [get_cells inst_fifo_gen/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.gcx.clkx/*gsync_stage[1].rd_stg_inst/Q_reg_reg[*]] -datapath_only [get_property -min PERIOD $wr_clock]
set_bus_skew -from [get_cells inst_fifo_gen/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.gcx.clkx/*wr_pntr_gc_reg[*]] -to [get_cells inst_fifo_gen/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.gcx.clkx/*gsync_stage[1].rd_stg_inst/Q_reg_reg[*]] $skew_value
################################################################################

 

This constraint is auto generated by the Vivado FIFO Generator.

The critical warning during implementation points to the line of $skew_value - 2 errors per file / 1 per write & read clock.

 

If its helpful, I could also provide the entire IP.

 

Thank you very much for your support.

 

0 Kudos
Highlighted
Moderator
Moderator
1,317 Views
Registered: ‎01-16-2013

@squaringcircle 

 

Try reset and regenerate the FIFO IP output products. The tool is getting incorrect value from constraints which is causing the issue.

 

--Syed

---------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.

Did you check our new quick reference timing closure guide (UG1292)?
---------------------------------------------------------------------------------------------
0 Kudos
Highlighted
Participant
Participant
1,312 Views
Registered: ‎12-19-2018

Hi @syedz ,

 

Thanks for the feedback.

I've already tried this for all IPs in the design - including FIFOs and the MMCM creating the FIFO clock, but no change in the results.

 

 

0 Kudos
Highlighted
Moderator
Moderator
1,303 Views
Registered: ‎01-16-2013

@squaringcircle 

 

Since you mentioned that value is from set_bus_skew, Check whats the value returned for the following command:

set skew_value [expr {(($wr_clk_period < $rd_clk_period) ? $wr_clk_period : $rd_clk_period)} ]

 

Can you share the project archive? 

 

--Syed

---------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.

Did you check our new quick reference timing closure guide (UG1292)?
---------------------------------------------------------------------------------------------
0 Kudos
Highlighted
Participant
Participant
1,298 Views
Registered: ‎12-19-2018

@syedz 

 

Thanks for getting back.

 

This is the response I'm getting from TCL:

set skew_value [expr {(($wr_clk_period < $rd_clk_period) ? $wr_clk_period : $rd_clk_period)} ]
50.00000000000000000 36.87200164794921900 36.87200164794921900

 

Do you need the entire project?

This is quite large - would need to upload it to an ftp or similar.

0 Kudos
Highlighted
Moderator
Moderator
1,292 Views
Registered: ‎01-16-2013

@squaringcircle 

 

I have sent you email from ezmove where you can upload the project archive and send it back.

50.00000000000000000 36.87200164794921900 36.87200164794921900

The above value is incorrect. The return value skew_value should return on one number.

 

--Syed

 

---------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.

Did you check our new quick reference timing closure guide (UG1292)?
---------------------------------------------------------------------------------------------

View solution in original post

Highlighted
Participant
Participant
1,253 Views
Registered: ‎12-19-2018

The solution was to completely re-create the project from scratch - including FIFO ip cores.

0 Kudos
Highlighted
Visitor
Visitor
851 Views
Registered: ‎11-11-2019

Hi Guys,

unfortunately i have the same issue at the moment...

After synthesis there is the following critical warning:

[Common 17-161] Invalid option value '2.000 6.250' specified for 'value'. [".../rtl/fifos/stream_fifo_independend_clk/stream_fifo_independend_clk/stream_fifo_independend_clk_clocks.xdc":65]

which points to this constraint:

set_bus_skew -from [get_cells inst_fifo_gen/gaxis_fifo.gaxisf.axisf/grf.rf/gntv_or_sync_fifo.gcx.clkx/*rd_pntr_gc_reg[*]] -to [get_cells inst_fifo_gen/gaxis_fifo.gaxisf.axisf/grf.rf/gntv_or_sync_fifo.gcx.clkx/*gsync_stage[1].wr_stg_inst/Q_reg_reg[*]] $skew_value

Is there any other way to resolve this, except re-create the project from scratch?

 

0 Kudos
Highlighted
Guide
Guide
834 Views
Registered: ‎01-23-2009

These constraint files are wrong... This is a known problem that has been fixed (like years ago)...

When you do

get_property PERIOD [get_clocks -of_objects <some_pin_net_or_cell>]

This works fine as long as there is only one clock on <some_pin_net_or_cell> - this returns a single number which is the period of the clock.

In fact, in general when you pass the get_property command a list of objects, it returns the property from every object in the list as a list of values.

In Vivado, a pin, net or cell can carry more than one clock. This can be done explicitly with a "create_clock -add" or "create_generated_clock -add" (although this is rarely the problem), or comes about naturally as a result of a clock multiplexer. If you have a clock MUX, with two inputs, and each input has a "create_clock" (or create_generated_clock) upstream of the clock MUX (as they should) then the output of the clock MUX (the O pin and anything downstream from it) carry both clocks. If this clock then reaches a module that uses the above command in a scoped XDC file, then the "get_clocks" command returns a list of two clocks instead of a single clock objects, and hence the get_property command returns a tuple {20.000 20.000} - this is not a legal input for an "expr" command or for the value of a set_max_delay - hence you get the error/warning.

To solve this problem, Xilinx added a new option to the "get_property" command - the "-min" option (or -max).

get_property -min PERIOD [get_clocks -of_objects <some_pin_net_or_cell>]

Instead of returning a list of property values, it always returns a single number, even if passed a list of objects to get the property of. In the case of the -min, the command returns the smallest value of the returned list (in this case, the shortest period of the clocks on this pin/net/cell)

This problem was discovered ages ago, and the get_property -min has been part of the tool for several years. In the intervening time, all Xilinx IP has been modified to use the -min option to avoid this problem. So you shouldn't be seeing the error/warning anymore. If you are, your IP is grossly out of date (since it hasn't migrated to using the new XDC files with the -min option).

Avrum

Highlighted
Visitor
Visitor
801 Views
Registered: ‎11-11-2019

Great Answer!

Thanks for clearing that up Avrum.

You are right, i have an old Vivado Project 2016.4 running and i have a clock multiplexer in my design...

 

0 Kudos
Highlighted
Visitor
Visitor
396 Views
Registered: ‎03-22-2014

Hi Avrumw

Your explanation makes totla sense.

Unfortunately I still seem to be seeing this problem in Vivado 2019.1 using the axi interconnect,

When I look at the auto-generated .xdc, it has constraints such as  

set_max_delay -from [filter [all_registers -clock $clock_aclk] {REF_NAME !~ RAMB*}] -to [filter [all_registers -clock $clock_axis_aclk] {REF_NAME !~ RAMB*}] -datapath_only [get_property PERIOD $clock_aclk]

.i.e. missing the -min switch.

 

0 Kudos