cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
obruendl_psi
Adventurer
Adventurer
1,628 Views
Registered: ‎10-16-2017

Optimization of completely unrelated Signals in ISE 14.7

Jump to solution

I am working on timing-closure for a Virtex-6 Design (using ISE 14.7). I am facing the strange issue that ISE is obviously merging some logic together that is completely unrelated (the signals do not even run on the same clock frequency).

 

I already set the following options (for Synthesis and MAP/PAR where applicable) to avoid optimization of signals that are not related:

- resource_sharing off

- ignore_keep_hierarchy off

- LUT Combining off

 

Optmization of MAP and Synthesis is set to "Speed".

-keep_hierarchy is set to "Soft" and -hetlist_hierarchy to "Rebuilt".

 

I tired synthesyzing with -keep_hierarchy "Yes" but I run into tons of mapper error messages if I do so.

 

Attached you can find the timing report. The failing path is on line 11954. The signal "../fmc_raw_dat_dff_s" is on a different clock domain than all the "../inst_tmem_user/.." signals and they do not have to do anything with each other. The signals in "../inst_tmem_user/.." are related to the register bank for configuration, the "fmc_raw_dat_dff_s" signal is a pipeline stage directly after the ADC input that has no connections to the register bank (it is not configurable and has no runtime-clock enable from the register bank or anything similar).

 

The suspicious net-names like "lut77809_42134" for this path also catched my attention. The fact that no "human readable" names are used points into the directon that the tool optimizes different logic together and hence it cannot assign a readable name (because no such signal is present in my VHDL sources).

 

Does anybody know this (or a similar) problem? Any suggestions what I could try? 

 

0 Kudos
1 Solution

Accepted Solutions
chrisz
Xilinx Employee
Xilinx Employee
1,709 Views
Registered: ‎05-06-2008

Hello @obruendl_psi,

 

I recommend using the XBLKNM constraint on the components being merged together.  This will force MAP not to pack them together (page 231 of UG612 - https://www.xilinx.com/support/documentation/sw_manuals/xilinx14_7/ug612.pdf ).  More details on this constraint on page 316 of UG625 - https://www.xilinx.com/support/documentation/sw_manuals/xilinx14_7/cgd.pdf.   

 

Good Luck,
Chris

View solution in original post

5 Replies
obruendl_psi
Adventurer
Adventurer
1,620 Views
Registered: ‎10-16-2017

Here is the attachment. I had to pack the timing report into a ZIP since the Xilinx Forums do not allow ".twr" files... 

0 Kudos
chrisz
Xilinx Employee
Xilinx Employee
1,710 Views
Registered: ‎05-06-2008

Hello @obruendl_psi,

 

I recommend using the XBLKNM constraint on the components being merged together.  This will force MAP not to pack them together (page 231 of UG612 - https://www.xilinx.com/support/documentation/sw_manuals/xilinx14_7/ug612.pdf ).  More details on this constraint on page 316 of UG625 - https://www.xilinx.com/support/documentation/sw_manuals/xilinx14_7/cgd.pdf.   

 

Good Luck,
Chris

View solution in original post

avrumw
Expert
Expert
1,587 Views
Registered: ‎01-23-2009

You have to understand how things are named in ISE...

 

The result of synthesis is a netlist of BELs (Xilinx Basic ELements). These BELs are things like LUTs, FFs, MUXF7, MUXF8, carry chains, and other clocking, I/O and RAM related elements. Each of these BELs is given a name during synthesis.

 

During MAP, these BELs are packed into slices - there are 4 LUTs, 8 FFs, three wide MUXes and a variety of Carry elements in one SLICE. All the rest of the tool chain operates on a netlist of slices (not BELs) - this includes timing analysis. When the BELs are packed into SLICEs, the slice needs to be named. The packer chooses the name of one of the BELs that was packed into the SLICE for the name of the SLICE.

 

As a result, the name of the SLICE may not be an accurate representation of where it came from; if a SLICE gets BELs from two different hierarchical modules during packing, then a path that is clearly through the LUT from one module may have the slice name of the other module. This looks like logic from unrelated modules has been merged, but isn't really the case.

 

This is due to "unrelated packing" - this has nothing to do with any resource sharing nor any keep_hierarchy properties; these affect synthesis, whereas this renaming is done at mapping. And its jut that - stuff has the "wrong" name so that it looks like it belongs to another module.

 

Avrum

obruendl_psi
Adventurer
Adventurer
1,554 Views
Registered: ‎10-16-2017

In my case the register bank (inst_tmem_user) is placed at one end of the chip and the ADC input (fmc_raw_dat_dff_s) is at the other end of the chip. I can see that long routes are exactly where the timing path switches between those and I can also see the routes going accross the chip when I check the nets mentioned in the timing report in FPGA Editor.

 

So if it really is the case the MAP just packs the different LUTs in to the same slice, my Problem would be a "MAP" problem (because MAP should not pack things into one slice that are placed at oposite end of the chip) and my question would become "How can I prevent MAP from packing LUTs into one slice that are related to logic placed far apart from each other".

 

However, I also tried playing with keep_hierarchy attributes on the entity that contains both parts. If I add the keep_hierarchy attribute, things look way better. So for me it looks like it the issue is not caused by "unrelated packing".

 

Just for the sake of knowing it: Can I somehow disable "unrelated packing"?

 

0 Kudos
obruendl_psi
Adventurer
Adventurer
1,550 Views
Registered: ‎10-16-2017

@chrisz resolved my question. Using the constraint he mentioned allows me suppressing the packing.

0 Kudos