Handle LUTNM Properties

[DallonTG]

Vivado may create LUTNM properties during synthesis, basically pre-packing pairs of LUTs together. If you place one cell with a LUTNM property, the other cell is automatically placed as well. The following is what I understand about these netlist properties:

• HLUTNM: Hierarchical Lookup Table Name. Used for cells within the same level of hierarchy.
• LUTNM: Lookup Table Name. Used to group two LUT components that exist in different hierarchies.
• SOFT_HLUTNM: Pairs unrelated functions into a fracturable LUT.
• USE_LUTNM: ?

Even when you use the -no_lc synthesis option, you can still end up with cells that have the HLUTNM property set (though this will remove SOFT_HLUTNM properties).

According to a Xilinx forum user, LUT combining is only when two unrelated functions are “combined” into a fracturable LUT. (Not sure if this is true). Vivado synthesis will supposedly always try to combine related functions into fracturable LUTs.

Options:

1. Use this information from Vivado-generated netlists to improve/match Vivado's packing
2. Remove these properties so there won't be any issues when importing TCPs to Vivado. Using the -no_lc option will at least get rid of the SOFT_HLUTNM properties, but other LUTNM properties may still remain. So we must remove these properties before exporting to a TCP. Here is a simple code snippet that I have been using to do this:

    /**
     * Removes HLUTNM, SOFT_HLUTNM, and LUTNM properties from a netlist.
     */
    private static void removeLutPairs(CellDesign design) {

        Iterator<Cell> cellIt = design.getLeafCells().filter(Cell::isLut).iterator();
        while (cellIt.hasNext()) {
            Cell lutCell = cellIt.next();
            lutCell.getProperties().remove("LUTNM");
            lutCell.getProperties().remove("HLUTNM");
            lutCell.getProperties().remove("SOFT_HLUTNM");
        }
}

[trharoldsen]

Alternatively, as these come out of synthesis, I don't think it is unfair to use them to guide the packer.

If we can come to a consensus in the next 2 hours, I'll try to fix it up tonight.

[DallonTG]

A bit more info from Page 251 of this document: https://www.xilinx.com/support/documentation/sw_manuals/xilinx2016_1/ug912-vivado-properties.pdf

It says:

LUTNM instructs the tool to place two LUT5, SRL16, or LUTRAM components with compatible inputs into the same LUT6 site. • Use LUTNM to group two LUT components that exist anywhere in the design, including in different levels of the hierarchy. • Use HLUTNM to group LUT components in a single hierarchical module, when you expect to have multiple instances of that module used in the design. • HLUTNM is uniquified per hierarchy.

It doesn't mention the "soft" properties. In any case, I think we will only see HLUTNM and SOFT_HLUNM properties since our designs are flat.

Anyway, I don't see anything wrong with using these properties as long as the packer can still work if a design doesn't have them.

[trharoldsen]

Alternatively, as these come out of synthesis, I don't think it is unfair to use them to guide the packer.

On 11/12/18 4:23 PM, Dallon wrote:

Vivado may create LUTNM properties during synthesis, basically pre-packing pairs of LUTs together. If you place one cell with a LUTNM property, the other cell is automatically placed as well. The following is what I understand about these netlist properties:

• HLUTNM: Hierarchical Lookup Table Name. Used for cells within the same level of hierarchy.
• LUTNM: Lookup Table Name. Used to group two LUT components that exist in different hierarchies.
• SOFT_HLUTNM: Pairs unrelated functions into a fracturable LUT.
• USE_LUTNM: ?

Even when you use the -no_lc synthesis option, you can still end up with cells that have the HLUTNM property set (though this will remove SOFT_HLUTNM properties).

According to a Xilinx forum user, LUT combining is only when two unrelated functions are “combined” into a fracturable LUT. (Not sure if this is true). Vivado synthesis will supposedly always try to combine related functions into fracturable LUTs.

Options:

1. Use this information from Vivado-generated netlists to improve/match Vivado's packing
2. Remove these properties so there won't be any issues when importing TCPs to Vivado. Using the -no_lc option will at least get rid of the SOFT_HLUTNM properties, but other LUTNM properties may still remain. So we must remove these properties before exporting to a TCP. Here is a simple code snippet that I have been using to do this:

|/* Removes HLUTNM, SOFT_HLUTNM, and LUTNM properties from a netlist. */ private static void removeLutPairs(CellDesign design) { Iterator cellIt = design.getLeafCells().filter(Cell::isLut).iterator(); while (cellIt.hasNext()) { Cell lutCell = cellIt.next(); lutCell.getProperties().remove("LUTNM"); lutCell.getProperties().remove("HLUTNM"); lutCell.getProperties().remove("SOFT_HLUTNM"); } } |

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/byuccl/rs-cad/issues/22, or mute the thread https://github.com/notifications/unsubscribe-auth/AMdCwmR-82Q2OxprffBmbhglMU2TFSv0ks5uuea7gaJpZM4YadaS.

[nelsobe]

I agree with Travis - if the synthesizer suggests them, he should use them to get the best results possible. That is likely preferable to removing them.

However, Dallon’s script did handle all but one of my cordic’s CRITICAL WARNING issues (how many of these tricks do you have up your sleeve Dallon? Let’s get them on the table … :-))

Here is the remaining critical warning which looks to be a packing mistake to me, once I trace through it. :

CRITICAL WARNING: [Vivado 12-2285] Cannot set LOC property of instance 'u2/gen_pipe[2].Pipe/Zo_reg[9]', for bel CARRY4 Routing contention at pips element BOUTMUX [/mnt/hgfs/nelson/Documents/git/RS2Benchmarks/benchmarks/cordic/cordic.tcp/placement.xdc:5559]

Here are the placements for the slice in question:

set_property BEL SLICEL.B5LUT [get_cells {Zo[17]_i_1}] set_property LOC SLICE_X47Y102 [get_cells {Zo[17]_i_1}] set_property LOCK_PINS { I0:A1 } [get_cells {Zo[17]_i_1}]

set_property BEL SLICEL.A6LUT [get_cells {Zo[12]_i_2}] set_property LOC SLICE_X47Y102 [get_cells {Zo[12]_i_2}] set_property LOCK_PINS { I0:A1 } [get_cells {Zo[12]_i_2}]

set_property BEL SLICEL.CFF [get_cells {u2/gen_pipe[1].Pipe/Yo_reg[19]}] set_property LOC SLICE_X47Y102 [get_cells {u2/gen_pipe[1].Pipe/Yo_reg[19]}]

set_property BEL SLICEL.AFF [get_cells {u2/gen_pipe[2].Pipe/Zo_reg[9]}] set_property LOC SLICE_X47Y102 [get_cells {u2/gen_pipe[2].Pipe/Zo_reg[9]}]

set_property BEL SLICEL.BFF [get_cells {u2/gen_pipe[2].Pipe/Zo_reg[11]}] set_property LOC SLICE_X47Y102 [get_cells {u2/gen_pipe[2].Pipe/Zo_reg[11]}]

set_property BEL SLICEL.CARRY4 [get_cells {Zo_reg[12]_i_1}] set_property LOC SLICE_X47Y102 [get_cells {Zo_reg[12]_i_1}]

And, if you look at the netlist, here are the connections that should be made between the BELs in that slice:

B5LUT.O —> external A6LUT.O —> CY4.S3 GND —> CY4.{S1, S0, DI0, DI2, DI1, CYINIT} VCC —> CY4.{S2, DI3} external —> CY4.CI CY4.CO3 —> external external —> CFF.D CY4.O2 —> BFF.D CY4.O3 —> AFF.D

If you draw the netlist out and look at the constraints, everything makes sense except the last 2 - they don’t seem to be possible. That is the net that is coming out of CY4.O3 in the netlist is driving the flip flop which the packer has placed at the AFF position. I don’t see how this is possible… Packing bug?

Brent

On Nov 12, 2018, at 9:59 PM, trharoldsen notifications@github.com<mailto:notifications@github.com> wrote:

Alternatively, as these come out of synthesis, I don't think it is unfair to use them to guide the packer.

If we can come to a consensus in the next 2 hours, I'll try to fix it up tonight.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/byuccl/rs-cad/issues/22#issuecomment-438043255, or mute the threadhttps://github.com/notifications/unsubscribe-auth/APjxbgLHz1QlCIvVHLqHmVwQYzlk55bbks5uue9fgaJpZM4YadaS.

---

---

[DallonTG]

I don't get this critical warning when importing the packed and placed cordic design.

Could you send your tcp to me and I'll look at it?