Top-level routing with NanoRoute fails in Encounter top-down hierarchical flow using black-boxed partitions

Dear all,

I'm currently working on a full-chip design by adopting Encounter top-down hierarchical methodology with a master/clone flow on repeated instances defined as black-boxes. According to various steps described in reference documentation (EDI System User Guide, ch. 13 - Partitioning the Design)
everything works fine up to partition and savePartition commands in my design that uses black-boxes. Both pin assignment and trial-routing work properly and all nets that connect to black-box pins are properly trial-routed when invoking the trialRoute command with necessary options. All my problems arise when after saving partition data I try to proceed with the top-level flow. In fact the NanoRoute engine doesn't route nets that should connect to black-box pins with the  following strange behaviour as reported in Encounter console:

#WARNING (NRDB-629) NanoRoute cannot route PIN <pin name> of INST <instance name>, as the PIN  does not have physical port (pin geometries).

NR will ignore the PIN as if it does not exist in the NET. To fix the problem, add proper pin shapes to the PIN in the library.

where <instance name> is exactly the name of a previously-defined black-box and <pin name> a pin assigned to that black-box.

Just for better clarity,  I've investigated this issue with a (let me say)... minimal NON working example. Let consider the following very simple snippet of structural Verilog:

module TOP(
   input  clk,
   input  rst,
   output clk_out );


   UNDEFINED_MODULE   BBox( .A(clk), .B(rst) ) ;

   CKBD0 g1( .I(clk), .Z(clk_out) ) ;


endmodule

where  CKBD0 is a sample buffer cell that comes with the STD cell library of the technology that I'm working with, whereas UNDEFINED_MODULE is a module that for the moment is not yet specified, hence will be defined as a black-box in Encounter hierarchical flow.

After importing the Verilog code in Encounter the schematic view of the circuit is pretty obvious:

Next I perform a very simple floorplan. Most important, I define my UNDEFINED_MODULE as a black-box using the specifyBlackBox command. As a result UNDEFINED_MODULE becomes a green, unplaced macro on the right-side of the floorplan view:

Next I can pre-place the black-box just as any other hard-macro and finally assign both I/O pins and black-box pins, e.g. using the editPin command:

editPin -pin clk      -assign {4.0  0.0} -layer M2 -fixedPin -snap TRACK
editPin -pin clk_out  -assign {4.0 20.0} -layer M2 -fixedPin -snap TRACK

editPin -cell UNDEFINED_MODULE -pin A -layer M4 -assign {5.0 0.0} -fixedPin -snap TRACK
editPin -cell UNDEFINED_MODULE -pin B -layer M4 -assign {8.0 0.0} -fixedPin -snap TRACK

Then I run placeDesign and trialRoute. The buffer is placed and all nets are properly trial-routed to the black-box:

Finally I commit my partition and I save partition data:

partition
savePartition -dir ./partitions

As you can see, up to this step everything is OK, the black-box changes its colour since it is now replaced by a LEF and becomes a hard-macro:

At this point according to top-down hierarchical flow the block-level implementation (partition) and top-level implementation should become two independent tasks. Maybe someone else is in charge of the actual physical implementation of the committed black-box, but now I want to proceed in top-level design.

So for example, I select the net clk and I tell NanoRoute to route only clk in non timing-driven and non SI-driven mode:

setNanoRouteMode -routeTopRoutingLayer     3
setNanoRouteMode -routeBottomRoutingLayer  2
setNanoRouteMode -routeWithTimingDriven    false
setNanoRouteMode -routeWithSiDriven        false
setNanoRouteMode -routeSelectedNetOnly     true

selectNet clk

routeDesign -globalDetail

Surprisingly, NO ROUTING is performed by NanoRoute for the selected net clk that should connect to my black-box! In fact, as you can see clk is only routed to the buffer, but the connection to black-box pin A is completely IGNORED !!!

By checking the log file I retrieve the following warnings:

#WARNING (NRDB-166) Boundary for CELL_VIEW UNDEFINED_MODULE,abstract is not properly defined. To fix the problem, properly define the SIZE of the corresponding MACRO in the library.
#WARNING (NRDB-733) PIN A in CELL_VIEW UNDEFINED_MODULE,abstract does not have physical port.
#WARNING (NRDB-733) PIN B in CELL_VIEW UNDEFINED_MODULE,abstract does not have physical port.
#WARNING (NRDB-629) NanoRoute cannot route PIN B of INST BBox from NET rst, as the PIN does not have physical port (pin geometries).
NR will ignore the PIN as if it does not exist in the NET. To fix the problem, add proper pin shapes to the PIN in the library.
#WARNING (NRDB-629) NanoRoute cannot route PIN A of INST BBox from NET clk, as the PIN does not have physical port (pin geometries).
NR will ignore the PIN as if it does not exist in the NET. To fix the problem, add proper pin shapes to the PIN in the library.

This is actually strange, since the black-box has a well-defined size as specified with the specifyBlackBox command. Moreover if I toggle the visibility of the cell content both pins A and B exist, they have a well-defined layer and width/depth:

This is also confirmed by a quick database query on black-box pins:

encounter> dbGet [dbGetInstByName BBox].cell.terms.name                      
A B

encounter> dbGet [dbGetInstByName BBox].cell.terms.pins.allShapes.shapes.rect
{4.85 0.0 4.95 0.52} {7.85 0.0 7.95 0.52}

encounter> dbGet [dbGetInstByName BBox].cell.terms.pins.allShapes.layer.name
M4 M4

Furthermore, I tried to import in Cadence IC the DEF file that comes with partition data saved using the savePartition command and all pins exist in Virtuoso Layout Editor! 

So what's wrong with my black-box flow or with NanoRoute and prevents it from performing proper routing on nets that should connect to my black-box pins?

Any suggestions to help me in fixing this problem would be very appreciated! Thanks in advance

Luca