Skip to content

Finalize Probe #101

@timsherwood

Description

@timsherwood

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)

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions