In a continuous-build design flow, at which level should your error markers be addressed?
Almost all of today’s chip designers use the continuous-build environment approach in contrast to the waterfall methodology of the past. In a continuous-build model, teams working on block-level designs work parallel to the chip-level designers, who instantiate work-in-progress blocks into the chip’s floorplan. Periodically, the chip-level team merges chip-level data and incomplete block layouts exported from place and route (P&R) tools in the OASIS or GDS format to perform incremental physical verification. Running chip-level verification at intervals throughout the design implementation flow lets chip-level designers find and fix block placement issues early in the design flow, while they are still relatively easy to adjust.
However, when the incomplete block data does not yet comply with design rule checking (DRC), block-level contextual errors can be promoted to the chip level. Because they are contextual, they cannot be fixed by the chip-level designers, but because they aren’t identified as such, they cause a lot of unnecessary debugging and even tapeout delays. Removing these from the chip-level context and pushing the error reporting in this instances down into targeted blocks benefits both the block and chip owners. It simplifies chip-level debugging while providing block owners with actionable information they can use to debug and fix these errors within their blocks. And wouldn’t it be even better if you could do all this automatically?
Why it happens
Chip-level designers typically identify block-placement issues by looking for routing violations in the interface region where blocks abut in the design floorplan. Groups of violations between block regions can identify shifted placements or overlapping blocks that chip designers can easily fix. For example, in Figure 1, the multiple interface-error markers between instance D1/C1 and D1/D2 show that the placement of instance D1 shifted.
During chip development, when block-level data is still ‘dirty’, ignoring errors outside the interface regions streamlines chip-level DRC debugging and reduces DRC iterations. However, some errors reported at the chip level, whether over the block core area or related to chip-level context, require block-level correction. If these errors were reported at the block level, block-level designers could identify and correct mistakes in their block that are only visible in the chip-level context.
For example, a failure to specify the appropriate metal-routing blockage layer during block routing creates routing at the block level on a layer reserved for chip-level routing. Contextual violations reported over multiple instances of a block may help block-level designers identify ports sensitive to antenna violations, enabling them to insert routing jumpers or apply another method to make the block more robust.
Error reporting at the block level where you identify such cases makes both the chip- and block-level teams more effective, and takes full advantage of the parallel implementation methodology. But implementing an effective process that will ‘push’ these markers to the appropriate level requires an understanding of how and when these errors should be reassigned.
Splitting overlapped markers
Chip interface regions may extend the minimum wide metal width from the edge of a block boundary or similar small value. Error reporting that interacts with the interface region and extends into the block-core region may be needed for both chip-level and block-level DRC debug. Markers from these reports interacting with multiple blocks may be similarly useful in both blocks. One way to support multiple debugging needs is to split an error marker’s geometry at the block boundaries, and report the portion overlapping blocks at the appropriate block level. This is shown in Figure 2. Splitting error-marker geometries and pushing them into the appropriate level enables effective and efficient debug at every level. Chip-level designers have access to the marker at the block interface, while block designers see complete markers (which overlap their block’s core area), or partial markers when they interact with other blocks.
Block pushdown target regions
In addition to rectangular blocks with abutted placements, blocks often include rectilinear bounding boxes to define a cell’s layout region, as shown in Figure 3. Error markers that overlap bounding boxes cannot be allowed to overlap the data in both of the blocks. Error markers pushed from the chip level into block boundaries can be incorrect, as shown by example (2) in the diagram.
Similarly, the chip-level interface region must follow the target block’s routing region, not just the cell boundary. Because error markers overlapping a block’s bounding box are not necessarily inside the block’s routing region, pushing markers from the chip level into blocks requires a different strategy for rectilinear routing regions defined in blocks. Routing regions are used to define the target layer within each block to which the chip-level error markers should be pushed. Figure 4 illustrates how to push markers into the appropriate block based on their interaction with a block’s routing layer. Although the routing regions are shown in different colors for visualization, they are typically on the same layer.
Composite error reporting
In Figure 5, there are two placements of block A, three of block B, one of block C, and three of block D. While all of these errors are reported at the chip level, each placement may result in unique block-level violations. Reporting all chip-level errors over each block instance as a composite view at the block level, as shown in A’, B’, and D’, provides debug guidance block designers can use to fix the errors in parallel with the chip-level interface checking.
Implementing a push process
Moving error-marker reporting from the chip level to the block level, and supporting cases such as those described here, requires a method to split and report error markers at the block level when they interact with targeted block layout markers. Pushing markers changes their reporting level from one point in the design hierarchy to a lower level in the hierarchy.
Distributing chip-level error markers between abutted blocks requires a solution that splits error reporting at the routing-marker layer before pushing the markers down into block-level reporting. Designers need a way to identify the block names into which the chip-level markers will be pushed, and identify the block’s target routing layer defining the block’s layout boundary.
Some EDA companies provide automated solutions to help chip-level and block-level designers manage reporting-level issues such as these. Figure 6 shows a basic process flow for an automated push solution.
Managing the error reporting of DRC markers at the right levels enables a more collaborative approach to chip-level DRC iterations in a continuous-build design flow. Pushing block-level markers down to the block owner simplifies chip-level interface debug. As an added benefit, chip-level owners can provide valuable insights to block-level teams and help guide them through the debug of contextual placement issues. Implementing a push-marker technique for error reporting into your production flow improves communication between chip and block-level designers, simplifies chip-level debug, and enables both teams to fix errors early in the design flow, when correction is easier and faster.
James Paris is a Technical Marketing Engineer with the Design to Silicon Division of Mentor, a Siemens Business, supporting Calibre design interfaces. Prior to joining Mentor, he was responsible for analog/mixed-signal physical design implementation and flow development for various IC design companies. James holds a B.S. in Computer-Aided Design Engineering and an M.B.A in Marketing.