From: Kai Keskinen ([email protected])
Date: Thu Mar 23 2000 - 04:20:03 PST
Thanks for the replies. I believe Andrew has answered my query. We ran the
sim for ~220nS which was not enough time to charge up the caps. Can anyone
recommend a really good book on spice simulation that covers little tidbits
like this?
Cheers,
Kai Keskinen
Equipment and Network Interconnect
Nortel Subsystems and Performance Networks (NSPaN)
(613)-765-3506 (ESN 395)
[email protected] <mailto:[email protected]>
-----Original Message-----
From: Ingraham, Andrew [SMTP:[email protected]]
Sent: Wednesday, March 22, 2000 3:43 PM
To: Keskinen, Kai [KAN:0G15:EXCH]
Cc: '[email protected]'
Subject: RE: [SI-LIST] : HSPICE Start Up conditions
> I had a lot of problems getting a spice model of a gigabit
ethernet chip
> to run properly.
...
Not knowing how this gigabit Ethernet chip works, my concern is over
DC
biasing. I think you said the outputs of one chip are AC-coupled to
the
transmission line, and the far end of the line has a terminating
resistor
between the wires of the pair but not to ground or some other
reference. So
what determines the common-mode DC level on the t-line?
Presumably there is some sort of biasing circuit inside the second
chip, or
else HSPICE would have complained about no DC path to ground. I'd
be
curious what this biasing circuit is.
Whenever SPICE starts up, it finds the initial state by effectively
ignoring
all capacitors (treating them as open-circuits) and inductors
(treating them
as shorts) and solving for DC. It doesn't precisely "charge up" the
capacitors the same way a real circuit would. You can force it to
do that,
by initially setting ALL voltage sources to zero and then ramping
them up as
if the power supplies were turning on. This would probably make for
a very
long simulation, however, since it would need to span milliseconds
or
seconds, rather than nanoseconds.
In certain cases, particularly if something in the circuit has
multiple
stable states, SPICE could arrive at a different initial state than
it would
if everything had to actually charge up like the real circuit does.
Also (and this might be the key to your problem), in a transient
simulation,
SPICE assumes quiescent conditions at t=0, meaning all time-varying
signals
are effectively turned off for all time prior to t=0. Then at t=0+,
they
suddenly turn on. When signals are AC-coupled, this can indeed
upset the
bias conditions. Does the real circuit ever operate with no signals
for an
extended period of time (~seconds)? I bet it doesn't.
In SPICE, if the driver chip initially has one output high and the
other
low, SPICE probably initially sets the output side of the coupling
capacitors to equal voltages, i.e., UNequal bias voltages across the
two
caps. Over a VERY long time, perhaps measured in seconds, and with
a ~50%
duty cycle signal, the two caps would re-bias to have equal voltages
across
them. But in the meantime, the conditions would be offset. There
is
nothing wrong with SPICE; it is just telling you what the real
circuit would
do if you had no signals for a few hours, then turned them on.
One way around that, is to set the initial voltages on the two
coupling
capacitors, as it appears you have done.
SPICE can't do this itself, because the initial bias point across
those
capacitors is a function of the time-varying signals, which weren't
running
for t<=0.
Your bias time-constant is roughly 5 usec. If you didn't set the
initial
conditions correctly, you might need to run the simulation for
several
time-constants (many thousands of bit periods) for the bias point to
correctly re-establish itself.
Andy
**** To unsubscribe from si-list or si-list-digest: send e-mail to
[email protected]. In the BODY of message put: UNSUBSCRIBE si-list
or UNSUBSCRIBE si-list-digest, for more help, put HELP.
si-list archives are accessible at http://www.qsl.net/wb6tpu
****
**** To unsubscribe from si-list or si-list-digest: send e-mail to [email protected]. In the BODY of message put: UNSUBSCRIBE si-list or UNSUBSCRIBE si-list-digest, for more help, put HELP.
si-list archives are accessible at http://www.qsl.net/wb6tpu
****
This archive was generated by hypermail 2b29 : Thu Apr 20 2000 - 11:35:51 PDT