How can I cut a routing blockage in FE?

You can use another solution.
You can specify, attach to your block, a routing halo, like a placement blockage halo.
In the documentation it is specified that it prohib routing on top of the macro on the specified layer, but allow the router to connect macro pins on this layer (Straigth connection).

Hello,

To comment on this old post: Using a routing halo does not prevent the router to route over and fully across the macros on the specified layer. At least, this is what I am observing in my current design. Unfortunately.

Looks like, I have to go for obstruction layer defined for each macro instance, with the options to leave the acess to pin and special nets. (I want to avoid top level routing over memories)

Best Regards

patrice

 A Routing Halo is mean to prevent parallel wires at block boundaries, to avoid hidden SI issues. To completely block routing over a block, you need a routing blockage, as you said.

Thanks for raising this item up Kari. To create routing blockages above all hard macros in the design, pulled in by 5 microns for pin access one could do something like this:

foreach box [dbShape [dbGet [dbGet -p2 top.insts.cell.baseClass block].boxes] SIZE -5] {createRouteBlk -layer all -box $box}

Hi Bob,

Thanks for this feedback. I am trying to implement this but I have a couple of issue. As I am a beginner with dbGet, I did run some experiments but I am a bit stuck.

I am using SOC 8.1

There were complains about boxes (not recognized as attributes. Expected : box ?) and dbShape (ex: dbShapeRect now ?). So, I am cuurently with :

foreach box [dbShapeRect [dbGet -p [dbGet -p2 top.insts.cell.baseClass block].box] SIZE -5] {createRouteBlk -layer 5 -box $box}

I have added the -p to return pointers but dbShapeRect still complains it expects a pointer (I got: Usage: dbShapeRect <ShapePtr>)

However, If I type only : dbGet -p [dbGet -p2 top.insts.cell.baseClass block].box
0x11fa2f038 0x11fb5e5b0

that gives a list of pointers and seem correct, so i don't know what is the issue.

In case you could have a look as this is obviously a very useful ietms for many design.

Thanks

Patrice

The dbShape command debuted in 10.1 and dbGet didn't always expose the "boxes" field. Can you move to a newer version?

If not, you'd need to write your own shape maniuplation commands and retrieve the box list with getObjFPlanBoxList.

You may be better off adding the blockage shapes to the LEF (in which case you may not need to cut out around the pins because routers like NanoRoute can automatically access a pin covered with a blockage within a LEF).

Thanks,
Bob

Hi Bob,

I will move to 10.1 after completing this design.

In this design, I prefer not incorporate the blockage inside the LEF as I still allow power routing over the macro in the floorplan. So, it is nice to be able to generate those blockage on the fly and delete before checking for violation.

I am currently using this : foreach inst [dbGet [dbGet -p2 top.insts.cell.baseClass block].name] {createRouteBlk -cover -exceptpgnet -layer 5  -inst $inst}

layer 5 is my top metal.    That covers the macro.  That is already doing a good job. The sizing would have also allow access in the top metal to the pins. But not an issue for this design.

Thanks a lot for your answer.

Patrice