add event variables to vcd

[programmerjake]

it would be quite useful to be able to output event variables to vcd since that can be used for debugging, allowing an indication of when a process does something. They have no effect on the simulation.

I'm planning on using this functionality to indicate when all the signal values are read in test cases.

example nmigen API:

# in nmigen/sim/pysim.py
class Event:
    def __init__(name=None):
        if name is not None and not isinstance(name, str):
            raise TypeError("Name must be a string, not {!r}".format(name))
        self.name = name or tracer.get_var_name(depth=2 + src_loc_at, default="$signal")
        ...

class Simulator(...):
    ...
    def register_event(event: Event):
        ...

usage:

class M:
    def __init__(self):
        self.i = Signal()
        self.o = Signal()
    def elaborate(self, platform):
        m = Module()
        m.d.sync += self.o.eq(self.i)
        return m

def simulate():
    m = M()
    sim = Simulator(m)
    ev1 = Event()
    ev2 = Event()
    sim.register_event(ev1) # can register events before write_vcd
    with sim.write_vcd(vcd_file=...):
        sim.register_event(ev2) # can register events after write_vcd but not after simulation starts running
        sim.add_clock(2e-6)
        def gen_process():
            yield Delay(0.5e-6)
            yield m.i.eq(1)
            yield ev1 # trigger ev1
            yield Delay(2e-6)
            yield m.i.eq(0)
            yield ev1 # trigger ev1 again
        def check_process():
            yield
            yield Delay(0.5e-6)
            yield ev2 # trigger ev2
            assert (yield m.o) != 1
            yield
            yield Delay(0.5e-6)
            yield ev2 # trigger ev2 again
            assert (yield m.o) != 0
        sim.add_sync_process(gen_process)
        sim.add_sync_process(check_process)
        sim.run()

[whitequark]

I agree that functionality similar to what you propose can be useful. However, at the moment I find it more important to have feature parity between pysim and cxxsim, and cxxsim's model (where the VCD file is written in C++ code) does not easily admit this feature.

Because of this I have no immediate plans to introduce extensions like this one. We can revisit this feature once cxxsim stabilizes and once someone proposes a good way to integrate it in both simulators.

[programmerjake]

additional comments:
http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2020-July/008548.html

[whitequark]

@programmerjake Would it help if you were able to print debug messages, similar to Verilog's $display, from both HDL and your testbenches? Because that functionality fits much better into the existing system and it can be added relatively quickly.

[whitequark]

I think we could hack something so that $display'd messages go into VCD files or otherwise end up in gtkwave-parseable form. It's going to be quite gross but by this point I consider VCD a fallback format of sorts; poorly filling the hole in the ecosystem where a much nicer format ought to be.

[programmerjake]

I would think events would be pretty easy to add -- all you need is to create the additional vcd vars and then tell the c++ vcd writer to write an event to a specified var -- basically a message-less $display associated with a variable. it would use basically the same mechanism that $display might. I can try my hand at it if you like

[whitequark]

then tell the c++ vcd writer to write an event to a specified var

So, currently you can't do that. The C++ VCD writer is sampling the state of the simulation--the inverse of the way it's done in pysim. It's not really clear to me at the moment how to add support for either $display/$assert or events, but I'm much more interested in adding support for the former because it presents a much larger immediate benefit and the time I can spend on this is limited.

[whitequark]

Here's my proposal: once Display/$display are added to nMigen/Yosys and implemented in pysim/cxxsim, let's take another look at this feature, and hopefully implement it using the same mechanisms. Sounds good?

[whitequark]

Reopening since Display will likely force the necessary refactoring to be done early.

[whitequark]

This would need to go through an RFC these days, and it also seems unlikely that the issue author still needs it.