cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
wpd
Adventurer
Adventurer
13,526 Views
Registered: ‎05-18-2011

What to do about set_false_path: Object Type 'RTL_MUX3' used for 'from' is currently not supported for elaborated netlist warning

Jump to solution

I have a design with some control registers accessed via the AXI bus from a processor.  These control registers are written seldomly (or perhaps even never), but they configure processing done by my signal processing chain, which is clocked independently (and slightly faster) than the AXI bus.

 

So I created a false path constraint with:

 

set_false_path -from [get_cells xbac*control_inst/slv_reg*] -to [get_cells xbac*_video_inst/*]

 

I'm still not sure how best to specify items when setting constraints, but my intent is to say "ignore the outputs from any of the slv_reg registers that control stuff in the video processing chain."  When I attempt to synthesize my IP standalone, I get the following critical warning (along with 2 other similar warnings):

 

[Constraints 18-441] set_false_path: Object Type 'RTL_MUX3' used for 'from' is currently not supported for elaborated netlist. ["C:/hai/fpgawork/fpga/modules/xbac_1.0/xdc/xbac.xdc":1]

I have been assuming I could just ignore this warning, but I hate that word ("assume").  Is there a better way to structure my design or to specify the false paths between seldomly changing control registers that control operation in a different clock domain?

 

--wpd

 

0 Kudos
1 Solution

Accepted Solutions
avrumw
Guide
Guide
21,795 Views
Registered: ‎01-23-2009

The problem is with your -to option - the wildcard you used here says "to any cell at the top level of the instances xbac*_video_inst.

 

So there are a couple of potential problems...

 

One is that this wildcard finds all cells at this level - this includes combinatorial cells and sequential cells. This is what is giving you the warning about RTL_MUX3; a combinatorial cell is not a valid endpoint of a static timing path, and hence the warning. Dries's suggestion of using the filter will fix this.

 

However, you need to understand that this syntax will only get cells at the top level of xbac*_video_inst. If there are any sub-modules of these instances; those will not be found by the wildcard; the * at the end cannot take the place of a hierarchy separator.

 

So, if you wanted to include all sub-modules as well (all the way down the hierarchy) you would need to change it to

   - to [get_cells -hier -filter {(NAME =~ xbac*_video_inst/*) && IS_SEQUENTIAL}]

 

Avrum

 

 

View solution in original post

4 Replies
driesd
Xilinx Employee
Xilinx Employee
13,521 Views
Registered: ‎11-28-2007

Hi Wpd,

 

indeed you can safely ignore this warning.

Warnings are indeed just warnings and are not "critical". For that we have critical warnings and errors.

 

However, to be clean, you could fine-tune your constraint. I would recommend to first synthesize, open the synthesized design and then create such a "get_cells" command that only targets the particular cells you target.

For example, I would add -filter {IS_SEQUENTIAL} to only target sequential elements.

 

Otherwise, a technique that is very useful, is to create constraints by right-clicking paths in the report_timing table.

 

 

Best regards,

Dries

--------------------------------------------------------------------------------------------------------------------
Please mark the Answer as "Accept as solution" if the information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented by clicking the star next to the post.
avrumw
Guide
Guide
21,796 Views
Registered: ‎01-23-2009

The problem is with your -to option - the wildcard you used here says "to any cell at the top level of the instances xbac*_video_inst.

 

So there are a couple of potential problems...

 

One is that this wildcard finds all cells at this level - this includes combinatorial cells and sequential cells. This is what is giving you the warning about RTL_MUX3; a combinatorial cell is not a valid endpoint of a static timing path, and hence the warning. Dries's suggestion of using the filter will fix this.

 

However, you need to understand that this syntax will only get cells at the top level of xbac*_video_inst. If there are any sub-modules of these instances; those will not be found by the wildcard; the * at the end cannot take the place of a hierarchy separator.

 

So, if you wanted to include all sub-modules as well (all the way down the hierarchy) you would need to change it to

   - to [get_cells -hier -filter {(NAME =~ xbac*_video_inst/*) && IS_SEQUENTIAL}]

 

Avrum

 

 

View solution in original post

wpd
Adventurer
Adventurer
13,493 Views
Registered: ‎05-18-2011

Hello Dries & Avrum,

Thank you for the tips.  I modified my constraint file as you suggested and synthesized the module.  I found the following warning message buried in the logfile:

 

WARNING: [Constraints 18-929] The number of objects selected for the constraint defined at line 1 of constraint file 'c:/hai/fpgawork/fpga/modules/xbac_1.0/xdc/xbac.xdc' exceeds the default limit of 1000, this constraint will be excluded from synthesis.

 

Perhaps this is innocuous -- if this particular constraint is ignored during synthesis, but still used in implementation, then this doesn't matter.  But if it gets ignored during implementation as well (I'm about to find out when I kick off the compile), then I need to address this.

 

But I'm still wondering if I'm missing something fundamental here.  I have a design in which code runs on a microprocessor (the ARM cores on the Zynq) that needs to set up some control registers for a signal processing chain running in programmable logic.  For all intents and purposes, the AXI bus microprocessor clock is interdependent of (and slower than) the signal processing clock, but the control registers are static for the lifetime of processing the data.  This seems like it should be a fairly common thing to do.  Is there are correspondingly common way to address the false paths between the static control registers in the processor clock domain and the logic that they control in the signal processing clock domain?

 

Should I resample the control registers with my high rate clock?  If so, what is the recommended technique for identifying those registers as false path targets?

 

Is there some other standard way of handling this?

 

Thank you again for the tips.  Please keep them coming.

 

--wpd

 

0 Kudos
wpd
Adventurer
Adventurer
13,483 Views
Registered: ‎05-18-2011

OK, now I've got it.

 

I decided to resample the control registers in my signal processing chain with

 

// Retime the control registers with the high rate clock
reg [31:0]   reg0_retimed, reg1_retimed, reg2_retimed, reg3_retimed,
             reg4_retimed, reg5_retimed;
always @(posedge S_AXIS_ACLK) begin
   reg0_retimed <= reg0;
   reg1_retimed <= reg1;
   reg2_retimed <= reg2;
   reg3_retimed <= reg3;
   reg4_retimed <= reg4;
   reg5_retimed <= reg5;
end

and to resample the status register in the AXI (processor) clock domain with:

 

reg [31:0] video_status_retimed;
always @(posedge S_AXI_ACLK) video_status_retimed <= video_status;

and to write my constraints as:

 

set_false_path -from [get_cells -hier -filter {(NAME =~ *xbac*control_inst/slv_reg*) && IS_SEQUENTIAL}] -to [get_cells xbac*_video_inst/*retimed*]
set_false_path -from [get_cells -hier -filter {(NAME =~ *xbac*video_inst/status*)    && IS_SEQUENTIAL}] -to [get_cells xbac*_control_inst/*status_retimed*]

I haven't fiddled with this too much (as each iteration took the better part of a half hour, and I had to go through a number of iterations before I finally got something that worked), but I found that I needed to add the splat before my module name in the (NAME =~ *xbac*control_inst/slv_reg*) clause in order for the constraints to apply when I compiled my IP at the top level.  I was trying to figure out how to construct the constraint file as part of my IP module such that I could synthesize the IP module, check for errors, check to see that the constraints applied, etc... Independent of the project as a whole.  Then I pulled the IP into my project as a whole (through IPI) and synthesize & implemented the project.  Once I finally got this to compile without errors, and (more importantly) with the false path constraints applied, I decided I'd had enough for the day :-)

 

Thanks again for the tips.  I still wish I could figure out some way to wrap my head around the right/best way to do this and to sort through the differences between get_cells, get_pins, get_ports, and the way that constraints can be scoped hierarchically.

 

Maybe someday.

 

--wpd

 

 

0 Kudos