-
Notifications
You must be signed in to change notification settings - Fork 89
Description
I added a new function, "probe" which is super helpful for debugging. It wraps up John's work with the debug_mode to capture the call stack and his ".name" trick for seeing signals in the waveform. You can wrap it around any WireVector and it will do two things a) print the call stack of the place where the wire was constructed (should it be where it was assigned?) and b) add a named wire to the design so it shows up in the trace.
Probe can be inserted into a existing design easily as it returns the original wire unmodified.
For example y <<= x[0:3] + 4 could be turned into y <<= probe(x)[0:3] + 4 to give visibility into both the origin of x (including the line that WireVector was originally created) and the run-time values of x (which will be named and thus show up by default in a trace). Likewise y <<= probe(x[0:3]) + 4, y <<= probe(x[0:3] + 4), and probe(y) <<= x[0:3] + 4 are all valid uses of probe.
Questions:
a) Right now probe does actually add wire to the working block of w (which can confuse various post-processing transforms such as output to verilog). Should probe add a new wire or just give a name to the existing wire if it has none? Should probe add a wirevector or an output?
b) how should we talk about probe in example 4? Do we still need to mention the ".name" and call stack things? Are they useful for common things that probe would not be (and if so should I modify probe to capture them)?
c) right now it gives a name to the wire, but that name is not a valid verilog name and thus you cannot output a probed design to verilog. How should we handle that (or just ignore it -- which is probably fine with me)