Setting constraints with hierarchical designs

[AhmadHouraniah]

Hello,

I am trying to set the constraints for a hierarchical design. I'm using the following syntax: set_max_delay -from [get_pins -hierarchical {submodule/wire_name}] -to [get_pins -hierarchical {sub_module/sub_sub_module/wire_name}] delay_amount_in_ns

However, this is not working. I get warnings such as pin 'sub_module/sub_sub_module/wire_name' not found. No valid object specified for -to/-from.

If there is no hierarchy, I am able to set the constraints directly by directly using the wire name for the -from and -to options (e.g. set_max_delay -from wire1 -to wire2 1.67).

Is my syntax correct? Are there any additional flow configuration variables I should add to support hierarchical constraints?

Thank you, Ahmad Houraniah.

[jjcherry56]

Without a netlist and the specific command it is nearly impossible to know what the problem. It is obvious that a "wire" is not a pin though, so it is no surprise no objects match the get_pins (you have to get that part working first). A wire defines a net. I also seriously doubt that -hierarchical is called for if you use a hierarchical path.

[AhmadHouraniah]

Thank you for your reply. I attempted to resolve the issue by using get_nets and get_ports, but it did not make any difference. My goal is to set constraints for the input and output ports of submodules.

When working with nonhierarchical paths, I utilize set_max_delay -from x to y 1.7 directly, and it works correctly. However, for hierarchical paths, I have tried writing them directly and using get_pins, get_nets, and get_ports, but I still encounter the same issue. That's why I included -hierarchical since I believed it was related to the issue.

Any suggestions you could provide me with would be greatly appreciated.

This is the command I am currently using: set_max_delay -from [get_pins -hierarchical {logical_tile_clb_mode_clb__0/clb_I[0]}] -to [get_pins -hierarchical {logical_tile_clb_mode_clb__0/logical_tile_clb_mode_default__fle_0/fle_in[0]}] 1.7

clb_I[0] is the input to sub_module logical_tile_clb_mode_clb__0 fle_in[0] is the input to the sub_sub_module logical_tile_clb_mode_default__fle_0

I have also provided a trimmed version of our netlist below.

module grid_clb(prog_clk, in1,  in2, in3, in4, in5, in6, in7, in8, in9, in10, clk, ccff_head,
                out1, out2, out3, out4, ccff_tail);
    input prog_clk;
    input in1, in2, in3, in4, in5, in6, in7, in8, in9, in10;
    input clk;
    input ccff_head;
    output out1, out2, out3, out4;
    output ccff_tail;

    logical_tile_clb_mode_clb_ logical_tile_clb_mode_clb__0 (
        .prog_clk(prog_clk),
        .clb_I({in1, in2, in3, in4, in5, in6, in7, in8, in9, in10}),
        .clb_clk(clk),
        .ccff_head(ccff_head),
        .clb_O({out1, out2, out3, out4}),
        .ccff_tail(ccff_tail));

endmodule

module logical_tile_clb_mode_clb_(prog_clk, clb_I, clb_clk, ccff_head, clb_O, ccff_tail);
    input prog_clk;
    input [0:9] clb_I;
    input clb_clk;
    input ccff_head;
    output [0:3] clb_O;
    output ccff_tail;

    wire [0:9] clb_I;
    wire clb_clk;
    wire [0:3] clb_O;

    // some more wire declarations and module instantiations.

    logical_tile_clb_mode_default__fle logical_tile_clb_mode_default__fle_0 (
        .prog_clk(prog_clk),
                //mux1-4_out are driven by other submodules based on the clb inputs and some other internal logic 
        .fle_in({mux1_out, mux2_out, mux3_out,  mux4_out}),
        .fle_clk(direct_interc_4_out),
        .ccff_head(ccff_head),
        .fle_out(logical_tile_clb_mode_default__fle_0_fle_out),
        .ccff_tail(logical_tile_clb_mode_default__fle_0_ccff_tail));

endmodule

module logical_tile_clb_mode_default__fle(prog_clk, fle_in, fle_clk,  ccff_head,  fle_out, ccff_tail);
    input prog_clk;
    input [0:3] fle_in;
    input fle_clk;
    input ccff_head;
    output fle_out;
    output ccff_tail;

    // more wire declarations and module instantiations.

endmodule

[jjcherry56]

I am not willing to try and pretend to be a machine running opensta on partial files. By test case I mean a tar file with an opensta tcl command file along with all of the files referenced by the command file.

[vijayank88]

@AhmadHouraniah

If you're raising any issues, create reproducible test case. So the developers just run your test case with source run.tcl or just ./run.sh. So create similar executable and attach here to get resolve your queries.

[AhmadHouraniah]

I understand. Unfortunately, I cannot share the documents, so I will close this issue. Thank you for your replies.

Best regards.

[jjcherry56]

Since the issue seems to be related to a basic understanding of how timing exceptions work you should be able to reproduce it with a small verilog netlist that uses the public liberty libraries in sta/examples.