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

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?

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.

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.

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

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.

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.

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.

@alanvgreen #628 (comment)