Fullchip physical block diagram

top level physical block diagram

The process of designing an ASIC top level requires the designer to start from functional block diagram of a chip, typically produced by the chip architecture team based the chip functionality and produces a physical block diagram.

The physical block diagram can then be used to create the device floor plan. In many cases the physical block diagram results in a change to the logical partitioning of the device, converting it into a design which is more robust and implementable.

A partition of the logic which is suitable for the physical constraints of the device can reduce the device area, and top level routing congestion. It can also significantly reduce the effort of timing closure and ultimately, the development schedule risks.

Let’s consider an example where the differences between the functional and physical block diagram is significant.

The below drawing shows the functional block diagram of a pipelined processing device where the data flow starts at one end of the pipe and ends in the other, the device implements two separate algorithms sharing the same system interfaces and a  central resource accessible from both sides. The pipes have some identical parts of the logic which is per input and output port (A1 and A3, B1 and B3) and some common logic (A2).

fullchip functional block diagram

 

You might think that the physical block diagram is trivial; we should just use the logical block partitioning, divide the chip into 3 parts. One for pipe A including A1, A2 and A3 and the other is for pipe B including B1, B2 and B3 and the third would include the central resource T1 and the muxes. Although this would seem logical, the better solution would be to bundle A1 with B1, A2 with B2 and the central resource T1 and finally, A3, B3 and the output muxes. This would result in better access to the I/O by both pipes as A1 and B1 would effectively be merged together. It would also improve the access to the shared resource by A2 and B2. The bellow drawing shows this partition option. This type of partition would make even more sense if you know that the T1 block is actually a very large memory array.

fullchip initial physical block diagram

 

The above example shows that partitioning the logic in a way that is in line with the physical perspective may require changes to the hierarchical structure of the chip, but will result in less routing at the top level, better timing and a floor-plan which is more robust.

Now let’s add some more physical constraints. We now assume that the ports are large parallel busses that cannot be placed on the same side of the device. The port connectivity we need is as described in the drawing below.

fullchip pin location

 

In this case, we need to rearrange the processing blocks differently, in order to avoid long routing of the input and output signals. The resulting physical block diagram would be as the drawing below. Note that this is a block diagram, no an actual floor-plan, so obviously you need to do something about the empty spaces.

fullchip final physical block diagram

 

If you look recall that the logical block in the same colors (A1-P0, A1-P1 etc..) are identical, you can come up with a single physical design block for all 4 sides of the chip and just place each one in its own rotation. This will result in only 2 physical blocks to design and significantly reduce the overall design effort.

This example shows the type of reasoning and thinking required in order to come up with a robust physical block diagram for your chip. Naturally every device is different, but this type of design can apply to any shape or structure producing benefits in area, power, schedule, risk and effort.

  1. The physical block diagram design process can be guided by the following questions:
  2. Where are the interfaces? Is there a match between the logical pin-out and the physical constraints for pin placement?
  3. Where are the top level large busses? How can you minimize the traveling distance of those busses?
  4. Are there any pieces of logic that are multiply instantiated? Are those a potential for block re-partitioning that would improve physical design predictability.
  5. Are there any shared resources, accessed from different blocks? Can those pieces of logic be joined together? What is the right way to partition the logic in this case?
  6. Where are the large embedded memory arrays of the device? What would be their impact on the floor-plan? Will a different partition enable better access to those memories? Can the data flow in the device go through those large memory arrays?

Ask yourself and your team those questions and you are half way to a better floor-plan.

 

 

Subscribe to RTLery articles feed:

Leave a comment

Leave a comment