If the distribution is Gaussian, the mean and median are equal.

(Mean is defined as where is the probability distribution function (PDF) of —that is, it’s a average of X, weighted with the probability density of . The median defined as —that is, the point where is equally likely to be lower than or greater than (50% probability).)

Many times in engineering and process control, we keep track of the mean and standard deviation. One of the reasons is that if the thing we’re trying to control is Gaussian, the mean/median and standard deviation give us good design criteria to minimize failure: if we allow our system to tolerate 3 standard deviations () around the mean/median, then it has a 99.7% chance of success (0.3% chance of failure).

However, we can generalize this: if we wanted to be more lax, we could only design (or require) the system to tolerate 2 standard deviations (4.5% failure). In some cases, systems are designed to tolerate 4 standard deviations (0.006% failure). So, one can design the system to tolerate , where is some factor (3, 2, 4 for example) that determines the probability of failure.

However, what if the distribution is bimodal? Take for example, two modes of operation (each more or less Gaussian):

Due to the asymmetric distribution, the mean and median are now not the same. In this case, we could posit that some secondary mode (or external factor) causes that second hump. Let’s call the main hump the primary mode and the smaller hump the secondary mode. If things are behaving “normally” we get the first hump, but some failure or aberration causes the second hump.

However, what if the system was more sensitive to this failure (secondary mode). Then, we’d see something like:

Notice what happened? The median stayed exactly the same. However the mean mislabeled “average”) moved proportionally to that secondary hump. Incidentally, the standard deviation () also moved proportionally to the distance between the two humps—but let’s focus on the fact that the mean just changed.

The question you’re probably asking is “what’s so bad about that”? Well, if you’re computing six-sigma-like design criteria, you’re taking . Recall, however, that we could pick any factor depending on the probability of failure we want (I should say want to avoid). So, when both the average and the standard deviation change, how can we be sure we’re getting the right value for ?

The nice thing about picking the median as the average is that it doesn’t depend on the magnitude of the secondary mode—only on the probability of the secondary mode. The magnitude of failure impacts the standard deviation. I like to view these (median and standard deviation) sas two independent metrics that tell different stories.

Another thing to note is that one could view the 2nd illustration above as an input to a nonlinear amplifier (for example) and the 3rd illustration as the output. That’s another nice thing about the median: it commutes with a monotonic nonlinearity. That is, if is monotonic, and , then . So, we don’t have to worry so much that we’re measuring the correct independent variable. Our median will give us the same information (albeit in a different, nonlinear domain).

I had been working on a pulse-width-modulation (PWM) design. It was a pseudo-digital implementation, in that the output was clocked by a high-speed clock. The actual switching rate was much lower than this clock. I wanted to simulate this design in Cadence/Spectre by running a transient and then taking an FFT.

However, I ran into a bit of a snag: the quantization clock and my input clock rates were defined by the design, and they weren’t up to me. Moreover, these weren’t related by a power of 2. Unfortunately, Cadence Ocean (Skill) commands only allow for a radix-2 (power of 2 length) FFT. So, I was stuck. I needed a way to do a non-radix-2 FFT in Cadence. Here’s how I solved it using Matlab and getting Cadence and Matlab to talk (in a limited fashion).

What I ended up doing was writing some Skill IPC (inter-process communication) code that:

1. Dumped the time-domain data to a text file on disk (in Cadence/Skill)
2. Read the time-domain data using Matlab
3. Perform the FFT (in Matlab)
4. Write the frequency-domain data to a text file (in Matlab)
5. Read the frequency-domain data (in Cadence/Skill)
6. Plot FFT and compute SNR/SNDR (in Cadence/Skill)

The scripts

These files are copyright Poojan Wagh, 2009. They are released under the GPL. See http://www.gnu.org/licenses/gpl.txt.

These files come with absolutely no warranty, expressed or implied. Use at your own risk. If these scripts destroy your entire design database, that’s your fault for using them.

The Ocean Script

Here’s the ocean script I used. It’s called text.txt, because it is actually contained as a cell-view (text file type). Here’s a run-through of the code:

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; copy this into CIW:
; runscript( "pwm3_sim" "reg0650_tran_paw" "ocean_ultrasim_getsndr_baseline" )
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

I’ve defined runscript() as a function which loads and executes a text-file cell-view.

; Copyright (c) 2009 Poojan Wagh
; Released under GPL (http://www.gnu.org/licenses/gpl.txt)
; $Revision: 1511 $
library = "pwm3_sim"
cell = "reg0650_tran_paw"
view = "config_baseline"
proc= "typ"
cap = "typ"
res = "typ"

library, cell, view, proc (typ/wcs/bcs), etc. are all defined as skill variables for easier changing & for future corner simulation

lsfqueue =  nil
jobname = "reg0650_tran_paw_baseline"

In case we want to use LSF for load-balancing

wad = getShellEnvVar("WORKAREA_DIR")
dumpfile = strcat(wad "/matfft/reg0650_tran_paw_baseline.pwm")

WORKAREA_DIR is the area where cadence is started. The PWM dump-out file will be in a mattfft subdirectory of it.

runit = t;
plotpsd = t;

runit determines whether we run the simulation or just plot the FFT/SNR/SNDR. plotpsd determines if we plot the power spectral density (PSD) or not (mostly for debugging).

;;;;;;;;;  Max Amplitude
inputmag =1.8;
vidc = 0.0;
fR = 460k;
ncs = 36;
fQ = ncs*fR;

inputmag is how high of an input signal we are sending to the PWM modulator. fR is the switching rate. fQ is the sampling rate. Note that fR=36*fQ, so this we don’t want a radix-2 FFT. Doing a radix-2 FFT would result in spectral leakage (and corrupt our SNR measurement).

;Changes 1024 pts **************************************
ncyc = 1024;
kcyc = 512;
simtime = (ncyc+kcyc)/fR
fbin = fR/ncyc;
fin = 13*fbin;
bw = round(20E3/fbin)*fbin;

I run the simulation for a total of $$\over{ncyc+kcyc}{fR}$$ cycles of fR. However, I throw away the first kcyc cycles to allow for startup transients.

; procedures used in this script:
; write a command to matlab
procedure( writemat(mipc cmd )
  ipcWaitForProcess(mipc)
  ipcWriteProcess(mipc sprintf(nil "disp 'Executing %s'\n" cmd));
  ipcWaitForProcess(mipc)
  ipcWriteProcess(mipc sprintf(nil "%s\n" cmd));
  )

This (above) is a little wrapper skill function that sends a command to Matlab. I made it so that it also displays the command being executed in Cadence (for debugging).

The following function computes the PSD by sending commands to Matlab

; compute psd from matlab
procedure( matpsd( dumpfile fR ncs ncyc)
  let( (fin psdfile fswfile freqvec psdvec persist matlog)
    printf("Starting matlab to compute PSD\n")
    sprintf(matlog "%s.log" dumpfile)
    printf("Matlab log file: %s\n" matlog)
    workareadir = getShellEnvVar("WORKAREA_DIR")
    mipc = ipcBeginProcess(strcat("cd " workareadir "/matfft && matlab -nodisplay -logfile " matlog))
    writemat(mipc "clear all");
    writemat(mipc "global ncs dt fsw")
    writemat(mipc sprintf(nil "fsw = %g" fR));
    writemat(mipc sprintf(nil "ncs = %u" ncs));
    writemat(mipc sprintf(nil "ncyc = %u" ncyc));
    writemat(mipc "dt = 1/(fsw*ncs)");
    writemat(mipc sprintf(nil "[yout, xin] = readpwm('%s');" dumpfile))
    writemat(mipc "[Py, freq] = getpsd(sign(yout), ncs*fsw, ncs*ncyc);");
    sprintf(psdfile "%s.psd" dumpfile);
    writemat(mipc sprintf(nil "fout = fopen('%s', 'w')" psdfile))
    writemat(mipc "fprintf(fout, '%.12g %.12g\\n', [freq(:) Py(:)]')")
    writemat(mipc "fclose(fout)")
    writemat(mipc "exit");
    printf("Waiting for Matlab to finish");
    ; wait for matlab to finish:
    while( ipcIsAliveProcess(mipc)
      printf(".")
      ipcSleep(1)
    )
    fin = infile(psdfile);
    freqvec = nil;
    psdvec = nil
    printf("Reading results from Matlab\n");
    while( fscanf(fin "%f %f" frq psd)
      if(!freqvec then
        freqvec = drCreateVec('double list(frq))
      else
        drAddElem(freqvec frq);
      )
      if(!psdvec then
        psdvec = drCreateVec('double list(psd))
      else
        drAddElem(psdvec psd)
      )
    )
    close(fin);
    psdpwm = drCreateWaveform(freqvec psdvec)
  ) ; let
  psdpwm        ; return psdpwm
) ; procedure

You’ll notice that the skill variables are actually sent to matlab, not hard-coded anywhere. So, changing the variable assignments in the skill/ocean file will be reflected in Matlab. Several Matlab helper functions are used:

• readpwm reads the text file
• getpsd computes the psd
  • bh4 defines a minimum 4-term blackman-harris window; when I wrote this script, it was not available in Matlab

Each of these Matlab .m files are included in the attached tarball. In addition, I define a few Ocean/Skill helper functions:

sumpsd sums up spectral power over a frequency range (fstart to fend):

procedure( sumpsd( psd fstart fend)
  if(fstart < fend then
    integ( clip(psd fstart fend) )
  else
    0.0
  )
)

getpow gets the spectral power of a tone centered at fc and takes into account spectral growth around fc by speclobew bins of the FFT:

; get power of signal centered at fc
procedure( getpow( psd fc fbin )
  let( list( (speclobew 5) )
    sumpsd(psd fc-speclobew*fbin fc+speclobew*fbin)
  )
)

Define simulator, output directory, etc:

simulator( 'UltraSim )
resultsDir( strcat( wad "/simulation/" library "/" cell "/" view "/" simulator() ) )

In case we want to use LSF for load-sharing:

if(lsfqueue then
  hostMode( 'distributed )
else
  hostMode( 'local )
  )

Define the test bench cell to be simulated (in read-only mode):

design(	library cell view "r" )

Define model files. Note that the proc,cap, etc. Skill variables are used:

printf("$Revision: 1511 $ Using rev1e model files\n")
modelFile(
    list("/pdk_dir/amsmodels/spectre/rev1e.scs" "base")
    list("/pdk_dir/amsmodels/spectre/rev1e.scs" strcat(proc "_fet"))
    list("/pdk_dir/amsmodels/spectre/rev1e.scs" strcat(proc "_bjt"))
    list("/pdk_dir/amsmodels/spectre/rev1e.scs" strcat(cap  "_capacitor"))
    list("/pdk_dir/amsmodels/spectre/rev1e.scs" strcat(res  "_resistor"))
    list("/pdk_dir/amsmodels/spectre/rev1e.scs" strcat(proc "_diode"))
)

Define the simulation time and analysis options:

sprintf(sstop, "%.12g", simtime);
analysis('tran ?stop sstop  ?saveOP t  ?write "spectre.ic"
		?writefinal "spectre.fc"  ?method "gear2"  ?strobeperiod "1.0/fQ"  ?maxstepU "1.0/(16*fQ)"  )

Define design variables. Note that these are assigned from the Skill variables, so changing just the skill variables at the top of the file propage down through the design netlist and into matlab

desVar(	  "fR" fR	)
desVar(	  "vdd" 2.5	)
desVar(	  "vidc" vidc	)
desVar(	  "inputmag" inputmag	)
desVar(	  "fin" fin	)
desVar(	  "fQ" "36*fR"	)

UltraSim simulation options:

option(	'tol  "0.001"
	'dc  "spectre DC (3)"
	'scale  ""
	'wf_format  "PSF"
	'pn_method  "keep"
	'analog  "off"
	'speed  "Extreme Accuracy (1)"
	'sim_mode  "Analog (A)"
)

saveOption('UsimOptionDepth "20")
saveOption('UsimOptionAllAnalogNV t)
saveOption('UsimOptionProbeAnalog t)
temp( 27 )

Actually run the simulation:

; either this:
if(runit then
  startrun = getCurrentTime()
  if(lsfqueue then
    run( ?queue lsfqueue ?block t ?jobName jobname)
  else
    run()
  )
  endrun = getCurrentTime()
  runtime = compareTime(endrun, startrun);
  printf("Run took %d hours %d minutes %d seconds\n" floor(runtime/60/60) mod(floor(runtime/60), 60) mod(runtime, 60));
else
  openResults(resultsDir());
)
selectResults( 'tran )

Dump out the time-domain file:

if(dumpfile then
  printf("dumping to file %s\n" dumpfile)
  ocnPrint(v("/PWM_P")-v("/PWM_M") ?output dumpfile ?precision 12 ?numberNotation `none)
)

Compute the PSD through Matlab

if(plotpsd then
  psdpwm = matpsd( dumpfile fR ncs ncyc )
  ; PSig = sumpsd(psdpwm fin-5*fbin fin+5*fbin)     ; Signal Power
  PSig = getpow(psdpwm fin fbin)                                        ; Signal Power
  PND = sumpsd(psdpwm 0 min(bw fin-6*fbin)) + sumpsd(psdpwm fin+6*fbin bw) ; Noise Power
  PN = PND;
  exbw = 0;
  ; for SNR measurement, exclude odd-mode distortion
  ; from 3*fin to bw
  for( k 1 floor(bw/2/fin)
    fex1 = (2*k+1)*fin-5*fbin
    fex2 = min(bw (2*k+1)*fin+5*fbin)
    psdex = sumpsd(psdpwm fex1 fex2);
    ; printf("k = %u Excluding distortion from %f kHz to %f kHz (%g - %g)\n" 2*k+1 fex1 fex2 PN psdex)
    PN = PN - psdex;
    exbw = exbw + (fex2-fex1);
    ; printf("Excluding distortion from %f kHz to %f kHz (%f kHz)\n" fex1/1.0k fex2/1.0k (fex2-fex1)/1.0k);
  )
  PN = PN / (1 - exbw/bw)           ;compensate for frequencies we have excluded
                                    ;(assuming white noise)
  SNDR = PSig/PND;
  SNR = PSig/PN;
  SNDRdB = db10(SNDR);
  SNRdB = db10(SNR);
  printf("SNDR [%s/%s/%s]= %.2f dB\n" library cell view SNDRdB);
  printf("SNR [%s/%s/%s]= %.2f dB\n" library cell view SNRdB);
  sprintf(wintitle "PSD of Digitized PWM [%s/%s/%s] SNDR = %.0f dB NSR = %.0f dB" library cell view SNDRdB SNRdB)
  plot(db10(clip(psdpwm, fin-5*fbin, fin+5*fbin)) db10(psdpwm) ?expr list("Desired Signal" wintitle))
  xLimit(list(0 bw))
)

I use vim

; vim: ft=ocean

ReadPWM

This little matlab function reads the text file and assigns variables in Matlab:

function [yout, xin] = readpwm(filename)
  [time, pwm, xin] = textread(filename, '%f %f %f', -1, 'headerlines', 5);
  yout = pwm;

GetPSD

This matlab function gets the PSD from the time-domain data:

% function [ypsd, freq] = getpsd(x, fs, [psdlen])
%   return psd ypsd and frequency scaling of signal x
%   with sample rate fs and psd length psdlen.
%   copied from getpsd.m
function [ypsd, freq] = getpsd(x, fs, psdlen)
  x = x(:)';
  if(nargin > 2)
    if(psdlen < length(x))
      y = x(1:psdlen).*bh4(psdlen);
    else
      y = x .* bh4(length(x));
    end
  end
  ypsd = abs(psd(y, psdlen)).^2;
  freq = (0:psdlen-1)*fs/psdlen;

Note that it also does the limiting function (using only the last psdlen values in the time-domain data).

BH4

Minimum 4-term blackman-harris window:

function [bh] = bh4(N)
% w = bh4(N)
%
%    Generates Blackman-Harris window of length N
%
a0=0.35875;
a1=0.48829;
a2=0.14128;
a3=0.01168;
theta = (0:N-1)*2*pi/N;
bh=a0-a1*cos(theta)+a2*cos(2*theta)-a3*cos(3*theta);

The Tarball

All the above scripts are contained matfft.

IPC

All of the above was done using Cadence IPC. This is basically a set of functions that let you remote-control another command. The standard input/output (stdin/stdout) of the child process is connected to the Cadence instance. Using ipcReadProcess in Cadence reads the child’s stdout. Using ipcWriteProcess writes to the child’s stdout. In theory, one could run any Matlab program from Cadence using this method.

However, one could read/write to any text-mode program using this method. For a while, I thought about using FFTW and coding a small C program to compute the above FFT’s. The same C program could be controlled using IPC. However, I wasn’t getting paid to program (at the time), and I already had most of the functions already in Matlab.

Update 2008-12-19

This post probably didn’t make sense to many of you. I was representing C-bar (negation of C) by an underline. Unfortunately, WordPress (or maybe my theme) wasn’t rendering this underline, so $$\overline{C}$$ didn’t look any different from $$C$$. I’ve (obviously) rectified this ambiguity through the magic of Latex. If there are any errors now, they are solely my fault. (Let me know.)

Consider the cross-coupled inverters shown below:

The two inverters chasing their tail to the right of the input inverters represent a memory unit (i.e. a latch). When one output is high the other one is forced low. This low output then reinforces the first output being high. These two inverters form a positive feedback system.

I will represent almost all circuits as fully differential. That is generally how I’ve encountered these structures, and it also more general. If one wants a single-ended version, simply lop off one of the input structures (but keep the cross-coupled inverters).

This system has two stable states: the top output high (at supply) and the bottom output low (at ground) or vice versa. One additional trait of these cross-coupled inverters is that it takes a bit of effort to flip them from one state to the other. One must essentially cause the top output to go from high to low by overcoming the inverter driving the top output. In other words, the input inverters (on the left) must be sized larger than the cross-coupled inverters.

Our desire, however, is not to have the state change at random. We want the latch state to change only upon the transition of an external clock. This can easily be accomplished by passing the input inverter’s output through a transmission gate controlled by the clocks $$C$$ and $$\overline{C}$$.

Now, we have a true latch. I won’t repeat Wikipedia in analyzing a flip-flop as two successive latches triggered on opposite phases of the clock signal.

Now, let’s look closer at the inverter and T-gate combination in more detail:

The PMOS controlled by $$\overline{C}$$ does very little when the output of the inverter is low. It is basically there for pull up. Similarly, when the inverter output is high, the NMOS controlled by $$C$$ does very little; it is basically there to pull $$\overline{out}$$ low. As a result, we can lose the connections between the PMOS and NMOS in the T-gate and incorporate the T-gate into the inverter:

This structure has the advantage of allowing an contactless diffusion between the series PMOS devices and another contactless diffusion between the series NMOS devices, as I illustrated in the MOS diffusion parasitics article.

Another manipulation we can perform on this structure is to reverse the roles of input gates and clock gates (switching the connections of $$in$$/$$\overline{in}$$ and $$C$$/$$\overline{C}$$):

Note that while both PMOS clock devices (driven by $$\overline{C}$$) are turned on, only one is actively pulling up an output. For example, the PMOS devices on the left pulls $$\overline{out}$$ up when $$in$$ is low. However, the upper right PMOS device (driven by $$\overline{C}$$) does nothing because the PMOS in series with it is off ($$\overline{in}$$ is high).

I will draw this structure as a gated inverter in the future:

Up to this point, the input structure has always had to fight the memory effect of the cross-coupled inverters. Essentially, the input structure must inject enough current into the cross-coupled inverters to force them to switch states. This contention can result in considerable power draw. This power draw can be alleviated by gating the cross-coupled inverters (enabled on the opposite phase than that of the input structures):

Finally, the PMOS clock devices  can be combined into one device; and the NMOS clock devices (driven by $$C$$) can be combined into one device. I have omitted the cross-coupled inverter devices for brevity:

Doing so has the benefit the PMOS clock device can be twice as large while maintaining the same capacitive load on $$\overline{C}$$. Similarly, the NMOS clock signal $$C$$ can see the sum of the device widths from the previous configuration yet whichever NMOS is on ($$in$$ or $$\overline{in}$$) is now in series with a device twice as wide.

Finally, one can omit some level of gating by pre-charging the latch. That is, instead of waiting for the input to determine whether we pull the output high or not, we pull the output high during the first half of every cycle. During the second half, we pull down only if the input should really be low. The following flip-flop structure achieves this pre-charging. Once again, I have omitted the cross-coupled structures:

The first stage’s PMOS pulls up whenever $$\overline{C}$$ is low on every cycle. Then, on the next half-cycle (when $$C$$ is high) the NMOS pulls down only when $$in$$ is high. Since the first stage only has one PMOS device (rather than two in series), the pull-up action is faster. Since we want to clock the second latch stage on the opposite phase (to form a full flip-flop), we need to invert the pre-charge and pre-charge low (rather than high).

The main problem with the pre-charge architecture as shown is that the first stage (for example) pulls up on every cycle even when the input $$in$$ is always high (and the output should be low). This represent a great deal of charging and discharging on the output of the first stage and thus dissipates power. However, this represents a fundamental trade-off: that one can gain increased speed at the expense of power.

Supply Switch

The simplest method to reduce leakage in standby is to provide a switch to supply that opens during standby. Since the sea of digital devices are then disconnected from supply, their gates cannot be at supply and therefore their gate leakage goes away. In this case, I have represented the sea of gates as an inverter, with its supply and ground connections explicitly shown:

The bigger concern is active operation. The PMOS switch has some finite on-resistance. Current spikes during the transition of the digital circuits will cause voltage spikes on the supply of the digital circuit as Ohmic loss builds through the PMOS switch. In effect, the PMOS switch reduces the pull-up capability of every gate in the digital circuitry:

This transient supply droop can be alleviated by sufficient bypassing. The problem and solution follow identically my previous post on supply regulation except that in that case of a feedback regulator, the low on-resistance is more frequency-dependent than with the PMOS switch. To keep the static supply droop under control, the PMOS switch should be made adequately wide. Doing so can cause the supply switch to have a size on the order of the entire digital circuit area.

Reverse Body Bias

The back-gate or body can also be used to reduce leakage. Essentially, leakage gets reduced when the threshold is increased—decreased (increased in magnitude) for PMOS devices. Biasing the body below the source for NMOS or above the source for PMOS can increase the magnitude of the threshold voltage.

To do so, we allow two connections for the body. I have picked the PMOS case for the body switching because typically, there is one ground available but two supplies (a higher-voltage I/O supply and a lower-voltage core supply):

When the enable EN signal is asserted high, EN will be low and therefore turn on the PMOS device that ties the body of the core circuit’s PMOS device to VDDCORE. When EN is deasserted low, EN will be pulled high and turn off this connection. In its place, the secondary PMOS device will pull the core body connection to VDDIO, effectively increasing the magnitude of the Vt of the core PMOS device, and thus reducing leakage in the inverter.

The main difficulty with the above technique is that it requires a separate connection for the PMOS body. Typically, in standard cell logic, the body is directly connected to supply.

There is also a risk that if these body-connecting PMOS devices have too large of an on-resistance, they can cause latch-up. Care should be taken to ensure that the on-resistances of these deices are low. However, the size of the resulting PMOS devices in this case would still be much less than that required of an equivalent PMOS supply switch.

One of the main benefits of the reverse body bias technique is that it allows for circuits which hold state (static memory cells). This is out of my range of experience, but it may also improve the required refresh rates on dynamic memory cells, too—thus slowing down refresh clock rates and therefore greatly reducing power.

Core Devices

Typically, foundries offer a few variations of there processes. I will call them general purpose (GP) and low power (LP). They differ in what I call the core devices, after which a process is usually named—for example, CMOS090 (90 nm) or TSMC 0.18μm.

GP

The GP represents the state of the art and usually drives large digital IC’s, including general purpose microprocessors and DSP’s. The traits of the GP process are a lower threshold and supply voltage, and possibly smaller effective gate length.

LP

The LP is usually a variant of the GP process optimized to reduce leakage (at the expense of speed). The LP option is usually used for highly integrated analog & RF CMOS IC’s, such as radios (RF transceivers), ADC’s, etc. Typically, the LP allows for a slightly higher supply voltage and sometimes has a slightly larger effective gate length. However, the main trait of the LP process is that the threshold is increased a bit from the GP process to allow for lower leakage. I’m not entirely sure if the higher supply voltage and gate length are intentional or are a byproduct of the higher threshold.

I/O Devices

Almost universally, all modern processes offer an “I/O” device. This is essentially a device from a prior process node (1.8 V, 2.5 V, or 3.3 V) with a larger gate length (0.18 um, 0.25 um, or 0.35 um). They are provided from a digital perspective as devices for pad drivers etc. However, they usually form the workhorse of analog/RF IC’s especially at baseband.

Device options

In both the GP and LP flavors, there are additional device options not necessarily universally, but usually:

• High-Vt: a core device with the threshold increased for lower leakage. This is also useful for larger output range on a diff pair—which depends on the input devices’ Vt—but usually an I/O device is even better.
• Low-Vt: a core device with the threshold decreased for higher performance (at the expense of leakage)
• Zero-Vt: a core device with a zero threshold voltage. This is useful for bypass switches and source followers.

These devices usually require additional mask steps and therefore incur additional processing costs.

Leakage

Basically, to minimize leakage, one should use the device with the highest threshold voltage that gets the job done. In order of preference:

1. I/O Device
2. High-Vt core device (if it is already available or if the expense makes sense)
3. Core (medium-Vt) devices

Of course, each of these options have the implicit tradeoff of performance/speed at the expense of leakage. What do you do when you want performance during active operation and low leakage during a standby mode? I will detail two methods in a future article.

Consider a free subscription: RSS (via a newsreader such as Google Reader, My Yahoo, Windows Live Mail, IE7, Firefox) or email (delivered to your email inbox).