So – when is a DRC error not an error?<\/p>\n
That\u2019s a trick question\u2026sort of. DRC errors are always errors, but sometimes they just don\u2019t matter much. Maybe the error has such a minimal effect on yield or functionality that fixing it costs more than ignoring it. Maybe it\u2019s the result of a complicated rule that can\u2019t be run without generating a few false results. Whatever the reason, there\u2019s a solution that\u2019s been around for quite a while now\u2026error waivers.<\/p>\n
Although we\u2019ve found solutions for each new challenge in waiver management, the capture and storage of waiver data has become as complicated as the designs themselves. Who knows what\u2019s outside our known universe? Want to know more about current waiver processing, and the ongoing efforts to predict and anticipate future challenges? Check out our white paper Dark matter, dark energy\u2026 What about dark errors?<\/a> for a glimpse into the mysteries of the cosmos of IC design waivers.<\/p>\n![\"\"](\"https:\/\/blogs.sw.siemens.com\/wp-content\/uploads\/sites\/50\/2018\/11\/IP-Waivers.png\")
<\/a>Error waivers are a way to let designers know they can safely ignore certain DRC error results. Of course, you can\u2019t just waive any old error\u2014both the foundry and design company have to agree that the error is insignificant in the scheme of things. While that used to happen on a one-by-one basis, that approach just isn\u2019t practical any longer, especially for waivers associated with hard IP that is reused time and time again in multiple designs, or soft IP like SRAM.<\/p>\n