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

pysim: option to capture simulation output in a python object #327

Open
mszep opened this issue Feb 28, 2020 · 9 comments
Open

pysim: option to capture simulation output in a python object #327

mszep opened this issue Feb 28, 2020 · 9 comments

Comments

@mszep
Copy link

mszep commented Feb 28, 2020

Would it make sense to have a way to capture simulation output in a python object, rather than having to use a vcd file and a separate reader program?

I'm building a physics simulator in nmigen and it would be super helpful when debugging to be able to plot a signal's trace (over eg 1000 timesteps) in matplotlib, within the same python session as the simulation.

Does this make sense as a workflow?
Is there already a way to do this?

@whitequark
Copy link
Member

Yes, it would make perfect sense as a workflow. Do you have any preferences regarding an exported API here?

@mszep
Copy link
Author

mszep commented Feb 28, 2020

Thinking about the API, I'd have no preference -- whatever's most convenient on the nmigen side.

I guess for consistency we could have a context manager similar to write_vcd, so something like

traces = {}
with write_dict(traces):
    sim.run()

where traces would then contain the signal identifiers as keys, and perhaps a list of (timestamp, value) pairs as values?

@awygle
Copy link
Contributor

awygle commented Feb 28, 2020

I'd like us to make sure that this can be used incrementally - that is, run for N clock ticks and return the traces, do something with them, then run for M more clock ticks and return those traces. This ties into my dream of an interactive simulator.

Note that I don't think the context manager API is incompatible with the above, just making a use case known. run_until and step in place of run should cover it.

@mszep
Copy link
Author

mszep commented Feb 29, 2020

Yes, that would be awesome! I was thinking of the possibility of making interactive simulations with ipywidgets, but if making it iterative will complicate the API or the implementation of the simple case, perhaps the simple case should take priority.

@whitequark
Copy link
Member

It wouldn't be hard to make it iterative; the VCD writer isn't, but only due to limitations of the VCD file format.

@mszep
Copy link
Author

mszep commented Mar 7, 2020

FWIW, I ended up just passing a StringIO object to the write_vcd context manager and parsing the vcd text data into plottable form.

Therefore, I think this issue can be deprioritized or closed altogether.

@whitequark
Copy link
Member

I think it would be an appropriate and highly useful feature to have: your workaround is... let's say suboptimal (no shade but it's pretty inefficient), and what @awygle wants here is also very reasonable.

alanvgreen added a commit to alanvgreen/nmigen that referenced this issue Aug 20, 2021
Adds an Observer interface to the simulator, allowing arbitrary code
to receive values from the simulation.

The implementation is based on the implementation of write_vcd. An
obvious next step would be to make _VCDWriter a subclass of Observer,
then
- rewrite Simulator.write_vcd() as a call to Simulator.oberve()
- remove PySimEngine._vcd_writers and associated code.

This commit is an RFC for amaranth-lang#327.
It is not intended to be submitted as-is.
@alanvgreen
Copy link
Contributor

This looks like a typical application for an Observer. The Observer is registered with the simulator, which then notifies it of interesting events.

I made a draft PR as an RFC. I think this is general enough to:

  • act as the interface for _VCDWriter
  • capture dictionaries of values at each step for @mszep's use case
  • intercept simulator state at defined numbers of clock cycles or timestamps for @awygle's use case

Please send comments.

@whitequark
Copy link
Member

@alanvgreen #628 (comment)

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

No branches or pull requests

4 participants