Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

unmatched nets in the layout

Status
Not open for further replies.

bwarlord01

Junior Member level 3
Joined
Sep 2, 2017
Messages
25
Helped
0
Reputation
0
Reaction score
0
Trophy points
1
Activity points
194
Hi guys, i badly need your help. i have been bothered by this error that says: "unmatched net in the layout"
i wondered whats wrong with my layout. i have done checking and tracing my schematic and layout many times, i also did relayouts many times. my layout looks like this whenever i click the error Capture2.JPG Capture.JPG This is in 65nm Tech Custom Compiler. and this is what my schematic looks like Capture3.JPG
 

To begin with, I see some "gnd" globals that are never
appropriate for on-chip use. These should be going to
a schematic supply pin or on-chip-appropriate ground
global (gnda!, gndd!, vssa!, vssd!, ...) that does not
attach to the zero node.

gnd! should be your measurement reference plane.
Any other use is "iffy" at best and usually ignores a
bunch of realities (such as packaging and PCB parasitic
features).

It's hard to deduce from the report or layout view
what the error is, but it seems to think there's a
short. Probing schematic mismatched and layout
mismatched nets one by one ought to home in on
what's messed up. Sometimes you have to go at it
visually and hope your eyes recognize "what should
have been".
 
A better layout should have a "Private Ground" such as my_gnd or similar.
As mentioned above, gnd! and likewise grounds are Global Grounds and they should be used in digital gate based layouts.
 
Your LVS tool report tells you about the most likely cause of the error: "Potential shorted nets in the layout".
Apparently, four schematic nets got shorted on the layout - so the LVS tool cannot establish a one-to-one correspondence (matching) between four schematic nets and one layout net.

Net name "N_2" sounds like an internal net name, I would expect its name be inherited from one of the schematic net names.
But I do not see a single internal net in your schematic - there are only external nets, with ports on them.

Did LVS tool report the schematic net names that got shorted?

I have a software tool that helps debug and identify the root causes of net shorts - write me a private message if you need a help.

By the way, did you try using your LBVS system debugging capabilities, to resolve net shorts issue? (are you using Calibre?).

Max
 
Thanks for the response.
Now i am very curious of what happened when the sources of my two nmos transistors **broken link removed** are fused into 1 input, the LVS Error is Clean **broken link removed** **broken link removed**

However, whenever i use my original circuit wherein two nmos transistors have their own inputs connected to the source **broken link removed** **broken link removed**, the LVS Error says these following error information in the images below:

**broken link removed**, it also says this **broken link removed** i dont understand why it says that the net57 and net54 in the layout is N/A, i have named my pin the layout the net57 and net54, and in the same order with the schematic. and also this nmos1.JPG even though i have the same transistor with the same aspect ratio in the layout and schematic.
 

Your attachments are invalid, it's impossible to make a sense out of your message without seeing the pictures...
 

Your attachments are invalid, it's impossible to make a sense out of your message without seeing the pictures...

i already triple checked it. and it is still the same
 

What is the same - LVS errors, or attachment being invalid?
Can you open links yourself, to your attachments?
 

What is the same - LVS errors, or attachment being invalid?
Can you open links yourself, to your attachments?

i got this error Capture.JPG Capture.JPG Capture.JPG

i already triple checked my Layout, and it matches the schematic but still i got this problem. I am using Custom Compiler 65nm CMOS Tech.
 

Your nets C and D appear to be merged (and hence missing in the layout) with some other nets - trace their connectivity and see what's wrong.
LVS system should tell what nets are they merged into.

You did not explain what changes did you do to your schematic or layout that LVS errors are now different.
 

Your nets C and D appear to be merged (and hence missing in the layout) with some other nets - trace their connectivity and see what's wrong.
LVS system should tell what nets are they merged into.

You did not explain what changes did you do to your schematic or layout that LVS errors are now different.

i am sorry for not stating what i did to my layout to remove previous errors, what i did is that i added some layers in my transistors.

The LVS System doesnt say what nets are merged

- - - Updated - - -

i think this is the main source of the error, Capture.JPG
and i dont know how to fix it.
 

Are you sure that the LVS does not produce some kind of
report file that lists every error? I know I always got one
(Cadence IC6, Silvaco Guardian). Maybe you have to tell
it to cough it up, or maybe it just goes somewhere you
don't usually look (like in the barf stream of the main log
file).

Can you not "display all merged nets" and see some kind
of listing?
 

Are you sure that the LVS does not produce some kind of
report file that lists every error? I know I always got one
(Cadence IC6, Silvaco Guardian). Maybe you have to tell
it to cough it up, or maybe it just goes somewhere you
don't usually look (like in the barf stream of the main log
file).

Can you not "display all merged nets" and see some kind
of listing?

The error says that in my Schematic, i am using nch_lvt which is true, but in the layout it says that i am using nch_lvt_mac, now i am very much confused what "MAC" means. I just copied the same layers used in nch_lvt in our TSMC65nm Library but the error stays the same.
 

"_mac" might mean "macromodel" which is a common approach
to getting RF simulation fidelity (embodying more of the close-in
parasitics that the compact model has nothing, for).

That's just one conjecture. The two (nch_lvt, nch_lvt_mac)
may have the same core layers and geometry but perhaps
the PDK has some "recognition feature" (like, say, "RF/drawing"
layer) that distinguishes the "just digital" device from the
"RF" device. Perhaps this is just bookkeeping, or perhaps
there are -supposed to be- specific features of the "RF"
device (such as gates strapped with Met1 and contacted
at both ends, a fixed or constrained W, etc.) and so an
enforcement of "tell me the same story the same way
twice" discipline makes more sense (preventing a surprise
of some sort).

Or maybe nch_lvt_mac is the device you're supposed
to use, and nch_lvt exists only to map the core device
of the macro to its model and has no layout view of
its own.

You could investigate these conjectures in the PDK
structure if you didn't have the more useful task of
fixing your schedule-bog by way of achieving design
consistency.

I'd bet there is a lovingly crafted library / modeling
document somewhere in said PDK that tells what's
what, feeling all lonesome because nobody ever
reads it.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top