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

Nengo GUI integration #28

Open
wants to merge 2 commits into
base: master
from

Conversation

Projects
None yet
3 participants
@tcstewar
Copy link
Contributor

tcstewar commented Aug 24, 2018

This adds a few more tweaks on top of #27 (which this PR is based on) that were needed to get it to stop and restart fine in nengo_gui. So now you can do nengo --backend nengo_loihi and it behaves almost like you'd expect (i.e. you can stop and continue, and change the code and it'll rebuild), with one slightly odd caveat: you can't have it run forever, and it's not a good idea to set that upper limit of how long it runs very high. Here's why:

The Simulator will now attempt to stop any snips that are running if it is closed. Unfortunately, I can't figure out a way to actually stop the execution, so the model will still run for however many timesteps were requested, but at least the snips won't cause the execution to halt (to wait for new input).

This means that we can't have nengo_gui do something like sim.run(1000) and expect it to work well. That'll work fine once, but the moment you interrupt it, the chip will be unresponsive until it has run 1000000 time steps.

So, to get around this problem, we need to let nengo_gui users specify this maximum run time. The easiest thing I could think of was to add a magic variable max_loihi_time. It defaults to 1.0 and if you set it in your gui code, it'll use whatever you say.

To run this, you need nengo_gui branch loihi.

If anyone has stumbled across a way to tell loihi to stop its execution in the middle of a run, let me know! :) Barring that, I think this is the best we can do.

[EDIT: ] This PR probably needs to be re-thought in light of the changes to the communication protocol between chip and host introduced in #26

Terry Stewart added some commits Jun 30, 2018

Better stopping behaviour for snips
We now send an explicit stop signal, and once that is received
the snip will just return immediately.
@hunse

This comment has been minimized.

Copy link
Contributor

hunse commented Oct 29, 2018

With #121, I think we have a better ability to stop simulations mid-way, so we should re-examine this PR in light of that.

@tbekolay tbekolay force-pushed the master branch from 701f997 to 1fe237c Nov 11, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment