By James Paris and Armen Asatryan\u00a0<\/p>\n\n\n\n
Automated short checking during implementation lets design teams quickly find and fix these errors before full-chip verification, speeding time to tapeout.<\/em><\/p>\n\n\n\n Going through design implementation with multiple design elements in progress at the same time can make you feel like you\u2019re that magician trying to keep ten plates on sticks spinning simultaneously! You\u2019re supposed to have library exchange format (LEF) abstract representations for the physical intellectual property (IP) blocks that are being developed, so you can validate physical IP data at the chip-level context. But with everything happening at the same time, it\u2019s not unusual for the abstract size, pin locations, or boundary size to change. You might end up with LEF macros that don\u2019t match the IP data. Why is that a problem?<\/p>\n\n\n\n Errors found during these early stages of physical design implementation can require a change at the macro level, the chip level, or both. Data mismatches between the abstract macro and physical IP blocks can generate massively high error counts and mask the root cause, meaning you\u2019re going to have to invest a significant amount of time and effort to track down and fix all these errors. Can you hear your schedule falling and smashing to pieces?<\/p>\n\n\n\n Such systemic design issues, whose root cause creates many violations across a chip, block, or large area, can often be attributed to a single or multiple related layout issues that affect the fundamental integrity of the layout. Power\/ground shorts are a common example. Placing an IP block that is larger than the abstract footprint for that block in the system-on-chip (SoC) floorplan will create many shorts, all due to that single mistake.<\/p>\n\n\n\n Now, of course, comprehensive layout vs. schematic (LVS) short checking will find all these shorts, but that approach doesn\u2019t really work for a design integrity checking flow, because it happens after the SoC design is merged with the IP blocks. If any shorts are found, they must be fixed and the data re-merged, which adds additional overhead and time to the flow.<\/p>\n\n\n\n In contrast, a power\/ground short design integrity check can be applied during design implementation, using the same design exchange format (DEF) and LEF data used in the place and route (P&R) process. These LEF\/DEF data files define the abstract macros, pins, vias, routing, and other objects (such as fill) in the original P&R design. The Calibre platform contains foreign database interface (FDI) utilities that translate LEF\/DEF databases to either GDSII or OASIS format, mapping power\/ground net data into separate layers, then generate a rule deck to automate checking for direct and indirect interactions between power and ground nets. Best of all, you don\u2019t need to be a magician to make it work.<\/p>\n\n\n\n