FAQs

Why do we start with clock routing first in physical design?
On an average most of the designs have clocks and huge number of sequential cells are controlled by these clocks. 
In my view its not like whether clocks or data first, its about who is more critical or more vulnerable to variations or who are at greater frequency or who have huge load or who should travel longer to get connected to all sinks etc.. These factors decide the priority of the routing. In all synchronous designs, clocks are the key control signals which controls sequential cells. Due to the facts that clock network has many loads,higher freq and should be with very less variations, we start routing clocks first and then data signals. Since the whole design is free, clock routes will have greater scope to use variety of NDRs, specific set of metal layers to achieve specific timing targets. 
We often do few critical signals routing even prior to clock routing if those signals are even more critical !!

What is blockage and halos in physical design in VLSI?

Blockages:
Let’s assume that for some reason you don’t want to place any logic (can be a specific set of cells as well) or you don't intend to allow certain metal layers in a specific area or you are reserving a space for later stage additions (could be a room for top design related ) :
in all these cases you can use ‘blockages’ to reserve/restrict/block a specific area either from preventing std cell placement or avoiding specific layer metal shapes. ( 1) placement blockages 2) routing blockages).

Halos:
Lets say you are designing an SoC which consists of many sub IPs/blocks.Physical implementation of these top SoC and sub blocks is usually handled by different owners. (As you know every physical geometry in VLSI layout should be as per design rule). Basic idea is that a physical layout should be fab DR clean by construction when top level designer integrates the sub blocks. This can only be done if methodology/fab/process team guides all the sub designs and top design to follow specific patterns of layout on all boundaries ( as a best design practice) of their designs. So top integration guy knows what’s going to be the pattern of all sub blocks at least on the interface and he follows some strategies to ease up their integration at top level. To ease up this, they come up with a HALO cells with the recommended patterns ( different types of halos for respective edges). So sub and top blocks must use these HALO s appropriately on all sides.

So with halos cells used for all designs - no confusions,everybody follows rules (per-defined set of rules :)) so the integration becomes smoother and at the end of day everybody goes home happier :-)

Duplicate shapes on existing net segments  why do you remove them ?

At a first glance it doesn’t look like a problem as the layout is just a modelling of the actual mask. But you should be very careful about how the rest of the tools/methodologies treat these duplicate shapes and how does it gets translated onto the mask

If you don’t see any problems with implementation tools like ICC/Innovus, then you are ok till final route database is out, but how does the extraction engine behaves or how about GDSII interpretation for these scenarios ?

 Most of these tools are based on the modelling and they just assume these cases as a double thickness shapes and so the cap gets affected !!

 - either fix in the design or guide the modelling of extraction engine to avoid this

Let's say we are out of the extraction engine radar safely :)  GDSII creation could face issues as well, it can treat them as a polygon of double thickness and can mess up the design ?

Why these can occur in first place :

 EDA tools will never create these duplicate shapes at any cost. Only time these can come is with the manual ECO's (could be many reasons in manual ecos..)

First things first :

  It is not advised to have duplicated net shapes on top of each other. It just doesn’t give any clue to tool to flag it as an issue. May be some PD tools report it as a bug while saving the database (may be because of the inability to create object id's)