gnucap-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnucap-devel] temperature and simulation


From: Felix Salfelder
Subject: Re: [Gnucap-devel] temperature and simulation
Date: Sat, 30 Mar 2013 14:53:54 +0100
User-agent: Mutt/1.5.20 (2009-06-14)

hi there.

On Fri, Mar 29, 2013 at 08:48:06PM -0400, al davis wrote:
> On Tuesday 12 February 2013, Felix Salfelder wrote:
> > there are some issues with temperature which i'm not sure how
> > to fix. the results i get when running the attached files
> > seem wrong.
> 
> Temperature code isn't perfect.  It's old code, an attempt to do 
> it within a spice-type representation of everything, that turns 
> out to have some deep flaws.  It is not well tested.  The idea 
> was that temperature would be slow-moving, therefore not part of 
> the matrix.  As exists, temperature is strictly a preset, not 
> dynamically computed, so it doesn't support self-heating.   
> Spice, at the time and probably still, didn't even do that.

i think it's a good idea to not allocate a matrix node for bmm_semi
devices. the bug i discovered is not about self heating. it's just a
question about when/how the device evaluates (environment, constant)
temperature dependent parameters.

> Verilog considers local temperature to be like a voltage, so it 
> adds a new node for each temperature.  Some of the new spice 
> models (BSIMSOI) also do that.

this is implemented in gnucap-adms. at least sketchy. it abuses voltage
nodes for temperature (or other discipline) calculations, basically to
work without code changes on the gnucap-side.
finally, disciplines must be moved to e_node.h.

> Temperature is not an explicit 
> part of the language, but rather defined by the user as a 
> "nature".  That makes it possible to do self-heating if the 
> models support it.

doesnt verilog define $temperature?
this environment temperature, similar to the electric gnd node, is not
represented by an actual matrix node, but other temperature nodes must
communicate with it. (so temperature is not just any nature, is it?).

> That leaves a big question of what approach to take here.

i think its quite clear that (the simple) spice devices just 'see' the
constant environment temperature (which may change between simulations)
and everything else must be modeled as temperature nodes.

have fun.
felix



reply via email to

[Prev in Thread] Current Thread [Next in Thread]