[Gnucap-devel] two event queue questions

[Felix Salfelder]

Hi Al, hi List.

playing with the icarus code generator (see iverilog-devel), i am
wondering about the following:

verilog uses a discrete time (uint64_t), while gnucap runs with double
(also 64 bit) time. unless time is really big, it's no problem to
schedule all the events of a verilog device after converting to double.
but then, i don't see why gnucap does use double for the master time.

lets say dtmin is 1e-12, and we want any time be precise up to
dtmin/1000 = 1e-16. then a simulation must stop some time around 1s.
with the same constraints and uint64_t, there are 1800 seconds to go.
similarly, if a simulation takes 1ms, with double and steps above dtmin
i get an error around 1e-21, in contrast to 2^64/1e-3, which is around
1e-23. i know this inspection isnt watertight, but it gives an
impression that using uint64 wouldnt break anything.

looking at the code, i find many places where rounding and elimination
errors must be treated. this wouldnt be necessary if the master time was
discrete. so what's the reason for using double here? are there slow
conversions involved with int64? is this for spice compatibility?
anything else?


and a second question. in icarus/vvp events are callbacks, while gnucap
only uses a priority queue filled with doubles and let all devices
figure out whether they are concerned. and then, there is a comment in
s__solve.cc that reads

/* finish_building_evalq
 * This function scans the circuit to queue for evaluation anything 
 * that is relevant that the devices missed themselves.
 * For now, it scans the whole circuit, but this will change.
 * This is slow, but the result is still faster than not having a queue.
 * The plan is .. every node knows whether it needs eval or not, and
 * only those nodes needing eval will be scanned.
 * Its purpose is to catch nodes that wake up after being dormant
 */.

what's the state of this more sophisticated queuing? and how would it
affect digital device simulation? is there anything worth considering?

regards
felix