[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnucap-devel] bug in pulse
From: |
Felix Salfelder |
Subject: |
[Gnucap-devel] bug in pulse |
Date: |
Wed, 27 Nov 2013 10:05:47 +0100 |
User-agent: |
Mutt/1.5.20 (2009-06-14) |
if the rise time is 0, the pulse value at _delay is wrong.
try
"""
spice
v1 1 0 pulse iv=0 pv=1 delay=.1 rise=0
r1 1 2 1
c1 2 0 1
.print tran v(nodes) next(c1) event(v1) ev(v1)
.tran 0 .2 .2 trace=r
.end
"""
the pulse is evaluated to 1 at time=.1. i think this is wrong because
for any positive value of delay it is (should be) zero, and delay=0
should actually be treated as delay=epsilon with epsilon a positive
number somewhere between 0 and dtmin (if not just the limit -> +0).
the example above shows that _iv is required at _delay, as the first
event is interpreted as pre-rise by the solver (see output below).
i'm a bit unsure on how to fix this. also fwiw, there is a discrepancy
between the manual.pdf and the implementation wrt to ">" vs ">=" in
tr_eval, lines "if (time >= _delay+_rise+_width+_fall) {".
any clues?
regards
felix
"""output
#Time v(1) v(2) next(c1) event(v1) ev(v1)
0. 0. 0. 0. 0.1 0.
0.002 0. 0. 0.004 0.1 0.
0.004 0. 0. 0.006 0.1 0.
0.006 0. 0. 0.008 0.1 0.
0.008 0. 0. 0. 0.1 0.
0.01 0. 0. 0. 0.1 0.
0.1 0.99999 0.043062 0.03217 0. 1.
0.031111 0. 0. 0. 0.1 0.
0.1 0.99999 0.033297 0.051099 0. 1.
0.049877 0. 0. 0. 0.1 0.
0.1 0.99999 0.024449 0.066202 0. 1.
0.064889 0. 0. 0. 0.1 0.
0.1 0.99999 0.017253 0.076817 0. 1.
0.076148 0. 0. 0. 0.1 0.
0.1 0.99999 0.011785 0.084524 0. 1.
0.084405 0. 0. 0. 0.1 0.
[..]
"""
- [Gnucap-devel] bug in pulse,
Felix Salfelder <=