Support monitor/driver pattern

[leonardt]

I think with the new control flow and conditional features, we should be able to implement these. We should create some tests/examples showing how this is done in fault.

[benreynwar]

I'm curious why you decided against using cocotb, or taking a cocotb approach where the python is driving the simulation during execution. What's the rationale behind generating test benches rather than directly writing the test in python?

[leonardt]

I would happily support efforts to integrate cocotb, but as you noticed, it would first require fault to support a python driven simulation environment. We have an open issue for this (see https://github.com/leonardt/fault/issues/19), but basically, the fault interface could be used in a mode that fires up a verilog simulator and uses the DPI to drive the simulation from python. Perhaps we could leverage cocotb as a backend target to do this.

The choice to generate test benches was partially an artifact of our background (we have a lot of experience working with generating code, not so much with the verilog DPI). However, there are some interesting use cases for running the simulation in a single environment. On the first order, it avoids the overhead going between two environments (e.g. Python and ncsim) which could become a non-trivial cost for complex, long running test bench. We are also interested in supporting emulation targets, so ideally a fault test bench could be compiled into a standalone design that could be synthesized onto an FPGA. Naturally, I imagine that we won't be able to synthesize all the capabilities that are required/desired for test bench writers, so we will likely need to design/develop some infrastructure for host code running in Python.

[leonardt]

Another interesting use case is the integration with CoSA. We have already done work on compiling coroutines (similar in spirit to cocotb's semantics) to RTL (verilog). If we can write monitors using coroutines in fault, this would provide us a hook for compiling coroutines into an FSM model that CoSA could then interpret. So, the staged metaprogramming approach provides the basic capabilities required to abstract over simulation and formal.

[benreynwar]

That makes sense.I think having a python driven simulation environment is really valuable for the power it gives to quickly write complex tests. The path of least resistance to that would just be throwing a python wrapper around the verilated code, which is probably what I'll do if I try to write something of a meaningful size in magma. Interfacing with the cocotb backend would be better, since it would support more simulators, but would be way more work.

[leonardt]

I'd be interested in seeing/using your code to wrap the verilator code when you get around to it. I have a task coming up in the medium term future that involves that feature, so I'd be happy to collaborate on it (I'll check in when I get to the point when I need it, if you haven't started, happy to share what I come up with)

[benreynwar]

I played with python and verilator a few months ago in https://github.com/benreynwar/verilate. The meat of it is copied from the pymtl folks. Do you all have a gitter or irc channel for questions?

[leonardt]

We don't have one setup, I'd be happy to join an existing one you use if it makes sense (w.r.t. to the channel topic). Otherwise, I can confer with others in my group and see about setting one up (we'll probably want to start with an umbrella channel that covers our HW tools).

[rdaly525]

I think setting up a gitter channel would be a good idea.