Codecov Report

Merging #624 (bd32c56) into master (abb2642) will decrease coverage by 0.00%.
The diff coverage is 84.84%.

@@            Coverage Diff             @@
##           master     #624      +/-   ##
==========================================
- Coverage   81.46%   81.45%   -0.01%     
==========================================
  Files          49       49              
  Lines        6446     6472      +26     
  Branches     1287     1299      +12     
==========================================
+ Hits         5251     5272      +21     
- Misses       1007     1010       +3     
- Partials      188      190       +2     

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update abb2642...bd32c56. Read the comment docs.

The ability to write GTKW files itself is auxiliary; it was added for parity with Migen. I don't think we should add any core language features purely to improve convenience of using GTKW files.

Yeah that's entirely fair, figured it was worth a shot as manually creating GTKW's and organizing the signals is kinda a pain.

Wasn't that much work anyway so no harm no foul~

I think there could be a nice way to implement that in downstream code if there was a way to attach something like tags to signals and later on collect all signals with a certain tag. This mechanism could also be handy for something like an ila or very ad-hoc debug CSRs.

I do like the idea of being able to add arbitrary tags (metadata?) to signals.

I'm not sure how I feel about signal metadata. It's certainly useful, but it's also liable to be the place where all the miscellaneous stuff gets put in, without structure or namespacing, leading to conflicts between different users of metadata.

Wouldn't it be possible to design the API in a way that avoids such problems?
One thing I could imagine would be that all metadata one can attach are objects of downstream classes. Then, one can query all metadata that is instance of a certain class.

One thing I could imagine would be that all metadata one can attach are objects of downstream classes. Then, one can query all metadata that is instance of a certain class.

That's the approach I picked for nmigen-soc, yeah. It could be applicable here, too; I like the idea!

That solution probably solves avoiding the mess. But it doesn't solve the potential for conflicting needs for similar metadata. Like a general "export this trace to gtkw" or "add to ILA group x" metadata class might be worth having as a built-in given just how common such features would be generally helpful (maybe not the ILA stuff if we're not going to include anything like that, but auto-add to gtkw/listing of interesting sim signals is probably worth it)