The Designer's Guide Community Forum
https://designers-guide.org/forum/YaBB.pl
Modeling >> Behavioral Models >> Addressing Parasitic Extraction on Top-level Routing
https://designers-guide.org/forum/YaBB.pl?num=1604967443

Message started by rhanna on Nov 9th, 2020, 4:17pm

Title: Addressing Parasitic Extraction on Top-level Routing
Post by rhanna on Nov 9th, 2020, 4:17pm

Credits to: The Designer's Guide to Verilog-AMS
Ch.2 Top-down Design - 3.4. Multiple Passes

==============================
Hello everybody,

Following this principle, design early problems could be captured. The process starts by developing a Top-level behavioral model of the system which is refined until it's believed that it's an accurate estimate of the desired architecture. Top-level routing is then possible, leading to parasitic extraction which directly impacts simulation performance and may result in design early changes and/or verification plan modifications.

My questions:
---------------
1. How can parasitic extraction be done on a top-level behavioral architecture?

2. on block-level verification where certain block/s is represented as transistor-level design, how can we study the correlation between the internal parasitics of a block with parasitics of the top-level architecture?
i.e. parasitics as a result of block-to-system interconnects

Thanks in advance for your time,
Ramy Hanna

Title: Re: Addressing Parasitic Extraction on Top-level Routing
Post by Maks on Nov 13th, 2020, 10:57pm

This book was written in 2004 - when parasitics were by several orders of magnitude less important than now (in 2020 - at 7nm, 5nm nodes).

Parasitic extraction is done not on architecture, but on the layout.

It's very hard to decouple parasitics at the block level with parasitics at the higher hierarchy level, as there may be a lot of interaction between these two levels - both resistive interaction (where metals at the lower hierarchy level are used for top-level routing - for example, power nets), and capacitive coupling.

As an example, many IR/EM effects and problems can be happening at the top hierarchy level - that is finished late in the deign process, and the size becomes too big even for industry standard, sign-off level IR/EM tools to handle it.

Title: Re: Addressing Parasitic Extraction on Top-level Routing
Post by rhanna on Nov 14th, 2020, 11:49am

Hi Maks,

Thanks a lot for your reply. I appreciate your answer.

So far, I went through recent papers to address this task as a part of the verification flow.

According to the attached verification project time plan (credits to "Verification of Complex Analog and RF IC Designs, by Henry Chang, Senior Member IEEE, and Ken Kundert, Fellow IEEE"):
========================================
Verification engineers can run post-layout mixed-level simulation once block layouts are accomplished by block designers (highlighted in red).

When the design lead and block designers layout the hierarchy and top-level post-layout verification can be explored (highlighted in green).

My question:
========
On the top-level of abstraction, it's clear that will be no extensive pre-layout simulation (early checks) as it's running on the constructed behavioral models.
But how would be the case when the Hierarchy layout and the integrated design are needed in the post-layout simulation?

Thanks in advance,
Ramy Hanna

Title: Re: Addressing Parasitic Extraction on Top-level Routing
Post by Maks on Nov 14th, 2020, 3:28pm

I am not an expert in functional verification.

I have looked through that paper, and some statements there, may have been true in 2007, are wrong in the year 2020, when you are dealing with FinFET technologies (16nm and lower nodes).

For example, this: "Near the end of the design, the transistor level representation can also include the parasitics."

The difference in circuit behavior for schematic simulation and for post-layout simulation is so huge, that pre-layout simulations are meaningless, and are not used any more.
That's because of the huge impact of parasitics - on everything - IR drop, signal delay, matching, etc.

Also, is you verify your blocks then combine several blocks together - they may behave differently, because of the global IR drop effects, or clock, etc.

You do need to verify at the top hierarchy level.
But doing a straightforward post-layout SPICE simulation is simply impossible, because of the huge size of the system.

Even doing IR/EM analysis at the top level is nearly impossible, using standard IR/EM tools - because they have to be sign-off, i.e. accurate, and use SPICE for current sources calculation.

The Designer's Guide Community Forum » Powered by YaBB 2.2.2!
YaBB © 2000-2008. All Rights Reserved.