Currently, clocking the circuit is bound by the QEventLoop, limiting the circuit to be clocked at ~5ms intervals at a minimum. If faster simulations are desired, the circuit should be moved to a separate thread from the GUI thread, using a faster clock triggering mechanism than what QTimer (and the Qt event loop) may provide.
Discussion:
As with any concurrency, this will increase the complexity of the program and potential for errors. It is a valid question to ask, whether it is even required to execute such high speed simulations in vsrtl, where the intention is to visually simulate the circuit - other than the "cool factor" of watching very large circuits light up in its active areas.
Signalling state changes between the circuit and the graphical representation becomes a challenge, given that signals are now to be emitted between threads. A Qt queued connection would be valid here, however, a signal/slot mechanism is not suitable for communication when signals are to be sent with such frequency. This also asks the question of when and how many updates are required? signal/slots are currently used to only redraw components which have changed. But with high-frequency simulations, it may be better to just run the component view at a 60fps update rate - however, querying all components in a view 60 times a second, with a large number of components, may be taxing.
Currently, clocking the circuit is bound by the QEventLoop, limiting the circuit to be clocked at ~5ms intervals at a minimum. If faster simulations are desired, the circuit should be moved to a separate thread from the GUI thread, using a faster clock triggering mechanism than what QTimer (and the Qt event loop) may provide.
Discussion: