The Designer's Guide Community
Forum
Welcome, Guest. Please Login or Register. Please follow the Forum guidelines.
May 17th, 2024, 5:54am
Pages: 1
Send Topic Print
Why duplicating devices 4 mismatch simulation ? (Read 4921 times)
Riad KACED
Community Member
***
Offline



Posts: 93
Swindon, UK
Why duplicating devices 4 mismatch simulation ?
Apr 28th, 2008, 5:27pm
 
Dear Community,

I'm using a submicron PDK from a well known foundry and I've noticed the duplication of almost all of the devices in "DeviceName_mis" variant to allow mismatch simulation when running MC mismatch.

I was a little bit surprised by this methodology since I've used many other PDKs from other companies and that's the first time I'm seeing this.

Well, this was really anoying me and some of the designers I'm working with because you need to suplicate every single schematic sheet ...
I went through the Spectre model file and I managed to write a parser that makes a slightly different Model file with Sections ordered differently. This allowed me to use a single schematic and just switch bck and forth between the sections when including the model file. So the problem of duplicating the schematics is resolved so far but ... I'm still wondering why the models are duplicated ?????

I made a diff between the "NmosX" subckt/Bsim_model and the "NmosX_mis" and the difference stands only for the mismatch-impacted parameters (VT, Tox, ...). But this difference appears only in statistical simulation since the mean/DC value of the Delta_for_Mismatch is ZERO. In other words, if you simulate both "NmosX_mis" and "NmosX" in a non-MC (let say a DC OP), you will get exactly the same results. I dumped the Spectre DC info results into ASCII files (input.info.models, input.info.output ...) and compared them all : NO DIFFERENCE.
I've done the same job for the passives and all devices duplicated into "_mis" variant. Same results in DC.

My conclusion at this stage is that the models are just redundant ...
Well, I think the guys who made this from this company are clever enough to avoid duplicating data, that's why I believe there is a reason behind but I don't see it actually ...

Any comment on this is more than welcome !

Thanks in advance.

Riad.   Wink
Back to top
 
 

Riad KACED
PDK, EDA Support Engineer.
View Profile   IP Logged
BWhite
New Member
*
Offline



Posts: 3

Re: Why duplicating devices 4 mismatch simulation
Reply #1 - May 1st, 2008, 4:19pm
 
I think the reason is to provide maximum flexibility in simulating mismatch.  Sometimes you want to understand the effect of mismatch in a specific set of matching devices without worrying about mismatch in all the other devices in the circuit.  

My understanding is that devices with no correlation statements default to "uncorrelated" and to apply overall mismatch randomization to your entire circuit assuming uncorrelated devices everywhere may be too pessimistic or provide too much extraneous variation in some cases.

That's just a guess though.
Back to top
 
 
View Profile   IP Logged
Riad KACED
Community Member
***
Offline



Posts: 93
Swindon, UK
Re: Why duplicating devices 4 mismatch simulation
Reply #2 - May 1st, 2008, 5:42pm
 
Yes, you’re right and I was thinking about the flexibility as well but this solution is not really clever. You can do this flexibility without any symbols duplication just by adding a local mismatch switch (let’s say MisLoc) into the :

1. Instantiation form
2. Spectre model card

The idea is to write a given mismatch-impacted model parameter like this:

Vth=Vth-mean + (Alpha*DeltaVthProcess)+ Beta*DeltaVthMismatch*MisLoc)

With (Just an example)
Statistics{
  Process{
     Vary DeltaVthProcess dist=gauss std=1
  }
  Mismatch{
     Vary DeltaVthMismatch dist=gauss std=1
  }
}

Vth-mean, Alpha and Beta are Process parameters (!= 0)
DeltaVthProcess and DeltaVthMismatch are nil in non MC mode
MisLoc =1 by default.

MisLoc is just a check-box that you add in your base CDF with a default value at ‘1’

When your run MC Mismatch on your design, all the devices are varying by default.
If you prefer to disable the mismatch from all the devices but those who are correlated (DiffPairs, CurrentMirrors …), you’ve just to switch on/off the check boxes on your design’s devices. The flexibility is done here : You’ve got a single schematic/instances with a flag that allows you switching on/off your mismatch locally.

The problem with duplication devices like this is to ensure that the ‘DEVICE_mis’ has got all the features of ‘DEVICE’ in terms of LVS/layoutXL …etc which is not the case quite often, means you’ve to create a schematic for simulating mismatch and another one for layout purpose (XL, LVS). This is very dangerous because you have to update one schematic at every single change of the other one …

Duplicating data is a huge source of errors, designers are humans after all !

So I still wonder whether I’m missing a link in the string …

Thanks for your commentary anyway  ;)
Back to top
 
 

Riad KACED
PDK, EDA Support Engineer.
View Profile   IP Logged
Riad KACED
Community Member
***
Offline



Posts: 93
Swindon, UK
Re: Why duplicating devices 4 mismatch simulation
Reply #3 - May 1st, 2008, 5:45pm
 
Ouuuuppps, Correction of the above equation (Sorry  :-[)
Vth=VthMean + (Alpha*DeltaVthProcess)+ (Beta*DeltaVthMismatch*MisLoc)

Riad.
Back to top
 
 

Riad KACED
PDK, EDA Support Engineer.
View Profile   IP Logged
vivkr
Community Fellow
*****
Offline



Posts: 780

Re: Why duplicating devices 4 mismatch simulation
Reply #4 - May 25th, 2008, 11:12pm
 
Hi Riad,

There is one more possibility. Some simulators allow you to perform mismatch simulations at a specific process corner to see how much safety margin you have if you are at the limits, or for instance how good some mismatch-dependent parameter is when the process also is unfavorable. For instance, if you are doing simulations of CMRR in an amp and the worst-speed corner is the worst for you.

You could set the default cmos model to "ws" and allow mismatches with the stat model. I am not sure though if even this could not be directly added to the
default model.

Regards
Vivek
Back to top
 
 
View Profile   IP Logged
Pages: 1
Send Topic Print
Copyright 2002-2024 Designer’s Guide Consulting, Inc. Designer’s Guide® is a registered trademark of Designer’s Guide Consulting, Inc. All rights reserved. Send comments or questions to editor@designers-guide.org. Consider submitting a paper or model.