Picking corner dependent variables for monte carlo simulation

Apologies, the link above should have been https://community.cadence.com/cadence_technology_forums/f/custom-ic-design/37847/detecting-process-corner-from-within-veriloga-model

This link would have been helpful if I was only running corner sims. I could have hard coded the corner parameters based on the results from the calibration sim results.

But since I want to run Monte Carlo, I am a bit lost as to how to do this.

Dear SunnyB,

I have a thought that I will pass by you for your consideration...

Since your initial corner simulations result in 5 calibration codes, I assume the fact that the calibration codes exist and are within the required range suggests that the circuit performance is sufficient at each corner.

Given this information, what remains is to verify performance in the presence of device mismatch. In essence, it seems your initial corner simulations verify that the performance is adequate over process. If this is accurate (subject to your scrutiny), then it appears a set of Monte-Carlo simulations are best performed at a specific process corner with only device mismatch enabled. Therefore, the calibration code to use for a given set of Monte-Carlo simulations is known since the corner is known. Further, in my experience, this limits the Monte-Carlo device mismatch simulation sets to the slow, fast-n/slow-p, or slow-n/fast-p corners as these three corners have the potential for the greatest amount of absolute value of threshold mismatch.

This may avoid the need to identify the specific process corner to select the appropriate calibration code in a set of process Monte-Carlo simulations.

Shawn

Hey Shawn, thanks for the reply.

Although I could do it your way, I would still prefer doing it the way I want simply because I want a 500 point global+local mismatch rather than having 125 points at FF (with mismatch), 125 points at SS (with mismatch), 125 points at FS (with mismatch) and so on..

This might affect my 3 sigma yield and accuracy. I want the mean to be centered around the typical case when the monte carlo performs statistical variation mismatch and samples. 

Thanks,

Sunny

Dear SunnyB,

Although I could do it your way, I would still prefer doing it the way I want simply because I want a 500 point global+local mismatch rather than having 125 points at FF (with mismatch), 125 points at SS (with mismatch), 125 points at FS (with mismatch) and so on..

This might affect my 3 sigma yield and accuracy. I want the mean to be centered around the typical case when the monte carlo performs statistical variation mismatch and samples.

Well, I've had some time to think about your basic question and your recent comment and now have a two part concern...but also a possible workaround that may be of interest. Let me know your thoughts if you the patience to read the following - and patience with m SunnyB!

My concern:

In the methodology you described in your initial post, as I understand it, you plan on performing two distinct sets of simulations: a set that uses 7 process corner simulations to estimate the value of calibration word cal_code<4:0> for each of 7 process corners.; and a second set of process+mismatch Monte-Carlo based simulations using the appropriate value of cal_code<4:0> for each simulation based on the "corner" for each Monte-Carlo simulation.

I see two issues with this approach.

a. When performing Monte-Carlo simulations under the process and mismatch corner, the silicon process type is "hidden" under the process design kit (PDK) called for a process Monte-Carlo simulation corner. In the PDK's I use, the corner called does not contain an identifier that indicates where the specific corner falls in the spectrum of the 7 non Monte-Carlo simulations you noted. Hence, to my knowledge, from the netlist alone for the specific Monte-Carlo iteration it is not possible to determine the non Monte-Carlo corner to which it most resembles.

b. Even it is was possible to determine the "corner" of a specific Monte-Carlo process and mismatch simulation set, I think your use of the appropriate value of cal_code<4:0> will not realistically examine the robustness of your calibration algorithm. Why do I say this? Basically, I am concerned that the 7 set of values for cal_code<4:0> using your calibration algorithm in the corner simulations do not cover the range of values of cal_code<4:0>. Any device in your process and mismatch Monte_carlo simulation population will have variation due to both mismatch and some deviation from the typical silicon process corner, and I am not convinced that these two effects will result in any of the 7 values of cal_code<4:0> from your corner only simulations. In effect, I am thinking it is unrealistic to assume your calibration algorithm produces a unique value of cal_code<4:0> independent of the amount of device mismatch.

Do my comments make any sense SunnyB - or should I better clarify my thoughts?

A posible workaround:

If you are using Assembler, a thought which I believe overcomes this issue - but will extend your simulation time - is to create a Run plan. The Run plan will have two Monte-Carlo simulations over process and mismatch. However, you will specify the same seed for each Monte-Carlo simulation set. The use of the same seed suggests that netlist i of the two sets of N Monte- Carlo simulations you submit will be the same. Hence, if you save the i'th value of cal_code<4:0> from your i'th calibration simulation, you can use it as a variable in the i'th simulation of the second set of N non-calibration Monte-Carlo simulations you submit. Therefore, this methodology truly tests the robustness of the calibration algorithm over process and mismatch and provides the actual range in circuit performance - not the range of circuit performance using your 7 selected values of cal_code<4:0> that may not fully reflect the full spectrum of cal_code<4:0> values from calibration processes in the presence of mismatch and process.

A Rapid Adoption Kit (RAK) detailing how you use the results of a simulation set in a Run Plan to a second simulation in the Run Plan may be found at URL:

support.cadence.com/.../articleattachmentportal

If you use oceanXL to control your runs in lieu of a Run Plan, the use of multiple Monte-Carlo runs is discussed in its latest manual (October 2020) at URL:

support1.cadence.com/.../ocnxl.pdf

Alternatively, do a Cadence Support Site search for the oceanXL function "ocnxlSetCalibration()"

Please excuse the length of my comments SunnyB. I hope my thoughts provide you some insight, and possibly, some help with your goal!

Shawn

You are right Shawn. I had misunderstood the requirement of the simulation. 

Initially, I had thought the closest we could simulate to real life is by simulating corners to get the calibrated code and then using that corner simulated code, run a monte carlo.

However, what I do now is that I run a monte carlo (e.g. 60 points) at nominal corner and save the 5 bit codes in a global variable. (I use calcVal for this)

Then I run the same monte carlo (60 points) with same seed (so each iteration represents the same silicon wafer as before). But this time, I run it at 8 different corners (varying voltage and temp) using the code from the previous monte carlo. Essentially this becomes 60 points x 8 corners  = 480 simulations. This emulates the exact real life condition and is exactly what I need. 

Thank you for your help!

The pre-run script approach in the rapid adoption kit that Shawn referenced also allows you to do this with a single test. So I would take a look at this too.

Regards

Andrew

Dear SunnyB and Andrew,

Andrew Beckett said:

The pre-run script approach

Thank you, Andrew, for explicitly mentioning this to SunnyB!

SunnyB said:

However, what I do now is that I run a monte carlo (e.g. 60 points) at nominal corner and save the 5 bit codes in a global variable. (I use calcVal for this)

 

Then I run the same monte carlo (60 points) with same seed (so each iteration represents the same silicon wafer as before). But this time, I run it at 8 different corners (varying voltage and temp) using the code from the previous monte carlo.

Thank you, SunnyB, for having the patience to read through my note and consider its contents! Your updated approach sounds much more realistic given the "continuous" spectrum of process cases provided by the process and mismatch corner - great!

If I may mention one other item with regard to your methodology - and you may be doing this already. I don't know the explicit voltage and temperature variations of your circuit, but in some calibrated circuits that I have been responsible for I have found the most stressful condition from a calibration perspective is when calibrated at the minimum or maximum temperature and then operated at the opposite temperature extreme (I term these the "inverted" temperature cases). Hence, I run two calibration with a total of four operation simulations as follows:

1. Calibrate at minimum operating temperature, save and load calibration code and operate at minimum and maximum temperature to verify sufficient performance at both temperatures.

2. Calibrate at maximum operating temperature, save and load calibration code and operate at maximum and minimum temperature to verify sufficient performance at both temperatures

This methodology, in my experience, is more stressful than running a calibration  simulation at a nominal temperature and then set the temperature to its maximum and minimum value with the calibration code corresponding to the nominal temperature.

Perhaps this is not an issue for your circuit, but wanted to at least mention it.

Thank you, again, for letting us know your thoughts and new approach SunnyB!

Shawn