Stats

  • Locked Locked
  • Replies 5
  • Subscribers 125
  • Views 15685
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

inconsistency while measuring sub-threshold currents.

geovol

Hi all,

I experience a strange issue when I simulate pmos and nmos devices operating in sub-threshold. The issue is as

follows:

I bias a pmos transistor of minimum channel length and width with ideal voltage sources: VG=VS=VDD, VB=VDD,

VD=0V. I perform a DC analysis and save the DC operating point. Surprisingly, when I annotate the DC operating

points, the ID of the transistor (which is biased in subthreshold) is lower than the DC current than is drawn from

the voltage sources connected at its Source and Drain terminals. The difference is significant, approximately an

order of magnitude or less depending on the bias conditions. This probably means that there is some extra leakage

current through the transistor which I am not able to see via the operating points. This issue is only present when

the transistor is biased in sub-threshold. In moderate and strong inversion, all currents are equal.



I have run this setup in several CMOS technologies, i.e. IBM 130nm, TSMC 0.35um, TSMC 90nm (all of them are

modeled with BSIM4.x). IC and Spectre versions are as follows:

IC 6.1.4-646.485 & IC 5.10.41_USR5.90.69 and Spectre 7.2.0 (64 bit).



Has anyone of you experienced a similar issue? Do you believe this inconsistency between current indications

might be due to modeling issues? Where does the extra leakage current come from, since both p-n junction diodes

are reverse-biased?



Thank you.

Parents
  • Andrew Beckett

    Given that all these currents are smaller than the usual tolerances (iabstol has a default of 1pA - and one of the convergence criteria is that the sum of the currents into each node should be less than reltol*current+iabstol), the currents actually look pretty accurate (with the exception of ids - but that's computed differently as an equation in the model, rather than being directly measured). I also don't know what you have gmin set to (it can't be the default, because that would lead to a 1e-12 conductance across the junction, which would give you a 3.2pA current across the junction (at least).

    I'd be surprised if the leakage currents in the models were that precisely modelled at this size of current, but if they are, then I think I'd need to see the precise simulator settings you're using before testing it myself to understand where the discrepancy comes from. It could be numerical simulator noise (although the currents through the sources add up, it may not be the current the device itself was expecting because it's below the tolerance).

    Perhaps you can post the complete input.scs you're using?

    Regards,

    Andrew.

Reply
  • Andrew Beckett

    Given that all these currents are smaller than the usual tolerances (iabstol has a default of 1pA - and one of the convergence criteria is that the sum of the currents into each node should be less than reltol*current+iabstol), the currents actually look pretty accurate (with the exception of ids - but that's computed differently as an equation in the model, rather than being directly measured). I also don't know what you have gmin set to (it can't be the default, because that would lead to a 1e-12 conductance across the junction, which would give you a 3.2pA current across the junction (at least).

    I'd be surprised if the leakage currents in the models were that precisely modelled at this size of current, but if they are, then I think I'd need to see the precise simulator settings you're using before testing it myself to understand where the discrepancy comes from. It could be numerical simulator noise (although the currents through the sources add up, it may not be the current the device itself was expecting because it's below the tolerance).

    Perhaps you can post the complete input.scs you're using?

    Regards,

    Andrew.

Children
No Data

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.