There's a GUI environment called BDW, available in the repo , which automates the connection to the GTKwave VCD viewer and provides the scripts for displaying enums and tags as their source code names, and for separating struct fields and vector elements into separate lines.? That code could probably be extracted into a command-line tool, if one would prefer not to use a GUI.? The BDW GUI also supports viewing the source code module hierarchy (including intermediate modules that have been inlined) and users can click on interfaces, state elements, and rules, to automatically add the related signals to the attached GTKWave viewer.
As Mieszko said, I only use VCDs for those things -- method ports, state elements, and rule firings -- which have clear naming in the generated code.? I don't debug combinational logic that way, though you can use Probes as Mieszko said.? I tend to use display statements etc.
The reason why the word 'request' doesn't show up is because you haven't specified that module for separate synthesis -- BSC inlines submodules.? If the logic for 'request' gets merges with logic from the calling location in the parent module, then there won't necessarily be any signal in the generated Verilog that corresponds to 'request'.? If there's a signal in the generated code that appears to have the same definition as 'request', then it's possible that there's a correctable bug in BSC that we can try to fix -- see if you can create a small example and open an issue.? BSC does generally try to keep source names where it can.
But during elaboration, sometimes BSC has to create new signal names, for subexpressions or newly created expressions, and those start with names that are just unique numbers, like "__d1", "__d2", __d3", etc.? That's entirely unhelpful, so BSC attempts to give more meaningful names to these, based on the expression that they are assigned to.? This is defined in "src/comp/SignalNaming.hs", I believe, and I think I've written an explanation of it before -- but for example, if you had:
__d1 = x?+ y
then BSC would name it "x_PLUS_y__d1".? And this:
__d2 = x[2:0]
would be named "x_BITS_2_0__d2".
During elaboration, case expressions becomes nested if-then-else and everything is optimized down to bits, so examing of tags is just equality on extracted bits, so your expression probably was something like this:
__d3 = if (foo[3:3] == 1) then ...
which gets named "IF_foo_BITS_3_3_EQ_1_THEN_..." but to avoid generating really long names, they are truncated at some point and just end with "_ETC__d3".? I agree that these longer names are not so helpful, but still better than just "__d3".? Suggestions on how to format these descriptive names is welcome, if you have better ideas.
My suggestion, though, would be to insert a synthesis boundary on the "mkTagEngine" module etc. ?(It's worth nothing that Mieszko's suggestion of using "interface" is only going to be helpful on a separately-synthesized module.? You can also try out PR #729, which implements a feature in BSC to split method input ports into separate ports for each field or sub-element.)
If you don't want to insert synthesis boundaries, you might try the BDW GUI's module browser.? As I said, it allows for viewing the inlined intermediate module hiearchy, and I believe that you can click on those modules to send any associated signals (that have remained in the Verilog) to the GTKWave viewer.
Note that BSC elaborates all the way to bits for Bluesim just as it does for Verilog.? Bluesim is able to linearize the rule execution, but isn't currently doing anything more high-level for the logic execution within each rule.? In theory, it may be possible to implement an evaluator that doesn't expand as far, so that simulation can be kept at a higher level (preserving types and perhaps some loops etc) -- I once experimented with this by trying to tweak the existing evaluator, but ran into some snags, it's probably a significant project.? Also note that the Verilog backend does some optimization of the signals, inlining ones that are simple or only used once, etc; whereas Bluesim doesn't do much optimization.? So you might see more signal names in the Bluesim VCD -- if you're debugging from VCD, I would tend to use the Verilog, which might be less cluttered. ?(Also, you might even see if Verilator on the Verilog simulates faster than the Bluesim anyway, for a given design.)
As for Tcl and Python, embedding the current Bluetcl in Python would be straightforward and would be great to see, if someone wants to give it a go.? I described a little about this in a previous email thread.? But basically, the functions are implemented into Haskell and that's exported to C and compiled in with a Tcl kernel.? I haven't embedded Haskell functions in Python to know if there's a more direct route, but certainly one could export to C and then import them into Python.? The only bit of work, really, is that the current Haskell functions are a little specific to Tcl in how they expect to receive and return data, and so one might want to decouple the underlying behavior from the specifics of the interface a little more, so that it can be shared by a Tcl wrapper and a Python wrapper.
J
Julie Schwartz