Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Execute simulator in separate thread #9

Open
mortbopet opened this issue Feb 27, 2019 · 0 comments
Open

Execute simulator in separate thread #9

mortbopet opened this issue Feb 27, 2019 · 0 comments
Labels
Core Issues related to the Core (non-graphics) library of VSRTL enhancement New feature or request

Comments

@mortbopet
Copy link
Owner

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.
@mortbopet mortbopet added Discussion A feature should be discussed before an implementation is decided enhancement New feature or request labels Feb 27, 2019
@mortbopet mortbopet added Core Issues related to the Core (non-graphics) library of VSRTL and removed Discussion A feature should be discussed before an implementation is decided labels Oct 18, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Core Issues related to the Core (non-graphics) library of VSRTL enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant