Render cool terminal version of wavedrom output

[mithro]

It would be awesome if undulate could render wavedrom output to console compatible output.

Here Is an example; https://github.com/mithro/i2cslave/blob/ad4335fb1ef5bb46d652e44b813c559f71b37409/i2cslave/targets/i2c_munger.py#L83-L98

             S   0       1       2       3       4       5       6       7       A
sda    ▔▔\▁▁▁▁▁----XXXX----XXXX----XXXX----XXXX----XXXX----XXXX----XXXX----▁▁▁▁▁▁▁▁▁/▔▔▔▔▔▔▔
sda_oe ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔\▁▁▁▁▁▁▁▁/▔▔▔▔▔▔▔
sda_w  ▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁
sda_r  ▔▔\▁▁▁▁▁1-------0-------1-------0-------0-------0-------0-------0------------/▔▔▔▔▔▔▔
scl_r  ▔▔▔▔\▁▁▁/▔▔▔\▁▁▁/▔▔▔\▁▁▁/▔▔▔\▁▁▁/▔▔▔\▁▁▁/▔▔▔\▁▁▁/▔▔▔\▁▁▁/▔▔▔\▁▁▁/▔▔▔\▁▁▁/▔▔▔\▁▁▁/▔▔▔▔

             S   0       1       2       3       4       5       6      7
sda    ▔▔\▁▁▁▁▁----XXXX----XXXX----XXXX----XXXX----XXXX----XXXX----XXXX----XXXX----
sda_oe ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔\▁▁▁▁▁▁▁/▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
sda_w  ▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁
sda_r  ▔▔\▁▁▁▁▁1-------0-------1-------0-------0-------0-------0-------0-------/▔▔▔
scl_r  ▔▔▔▔\▁▁▁/▔▔▔\▁▁▁/▔▔▔\▁▁▁/▔▔▔\▁▁▁/▔▔▔\▁▁▁/▔▔▔\▁▁▁/▔▔▔\▁▁▁/▔▔▔\▁▁▁/▔▔▔\▁▁▁/▔▔▔

[mithro]

Example from https://github.com/UCSBarchlab/PyRTL/issues/101#issuecomment-132857403

                                         ▏0                        ▏5                        ▏10                      

(Probe-1 : v[0] : tmp110_surfnoc_line95) _________________________ _______________╱‾‾‾‾╲____ __________

(Probe-2 : v[1] : tmp164_surfnoc_line95) _________________________ _________________________ __________

(Probe-3 : v[2] : tmp218_surfnoc_line95) _________________________ ╱‾‾‾‾╲___________________ __________

(Probe-4 : v[3] : tmp272_surfnoc_line95) _________________________ _________________________ _____╱‾‾‾‾

                                 data_in 0x1  ╳0x2 ╳0x3 ╳0x4 ╳0x5  ╳0x6 ╳0x7 ╳0x8 ╳0x9 ╳0x0  ╳0x1 ╳0x2 

                                    full _________________________ _________________________ __________

                      read_buffer_select 0x0  ╳0x2 ╳0x1 ╳0x3 ╳0x0  ╳0x2 ╳0x1 ╳0x3 ╳0x0 ╳0x2  ╳0x1 ╳0x3 

                             read_enable ‾‾‾‾‾‾‾‾‾‾╲______________ ╱‾‾‾‾‾‾‾‾‾╲____╱‾‾‾‾╲____ ╱‾‾‾‾‾‾‾‾‾

                             read_output 0x0                       ╳0x5 ╳0x0 ╳0x7 ╳0x6 ╳0x0  0x0  ╳0x7 

                                   valid _________________________ ╱‾‾‾‾╲_________╱‾‾‾‾╲____ _____╱‾‾‾‾

                     write_buffer_select 0x2  ╳0x0 ╳0x3 ╳0x1 ╳0x2  ╳0x0 ╳0x3 ╳0x1 ╳0x2 ╳0x0  ╳0x3 ╳0x1 

                            write_enable ____________________╱‾‾‾‾ ‾‾‾‾‾‾‾‾‾‾╲_________╱‾‾‾‾ ╲____╱‾‾‾‾

[mithro]

There are some very cool examples at https://github.com/UCSBarchlab/PyRTL/pull/284

[mithro]

And https://ucsbarchlab.github.io/PyRTL/

[LudwigCRON]

Note for later: seems to support only a fraction of characters For now, only lh01npxzm| symbols [x] Based on the desired slope can have | or / => we cannot use '|' with a top bar on the same terminal slot and did not find a specific character in the Unicode tables for that. Thus the proposal of pyRTL is complete to have the most beautiful drawing.

Shall we stick to ASCII? How to detect utf8 compatible terminal?

for utf-8 only waveforms: [x] up arrow and down arrow for N and P => cannot make a clean representation with arrows...NP are replaced with np [ ] for small down glitches cyrillic izhitsa or canadian syllabic pe => not yet see the purpose of glitches representation [ ] for small up glitches hangul jongseong sios or canadian syllabic pi => not yet see the purpose of glitches representation [x] use up arrow from bar for impulse => unfortunately the bar is not aligned with underscore and box bottom line [ ] use mysical arpeggiato up for time ellipsis => not yet see the purpose of time ellipsis representation

for utf-8/ASCII waveforms: [ ] use X for data transition [ ] use ~ for metastable [ ] use -- for high impedance [ ] use ! for time ellipsis => need a monospaced font to have proper alignment from one line to the other windows terminal supports Unicode and UTF-8 by default. in powershell the default is UTF-8 No BOM in cmd, the default is cp850 or cp1252. But this can be changed with chcp 65001 to support utf-8 on linux distributions, I did not get a terminal not supporting utf-8 to do the experiment

for data representation: [x] 1 row representation as pyrtl (inverted foreground background color)

:interrobang: pyrtl representation is the simplest and can keep ASCII only output. ncurse? Windows support?

[LudwigCRON]

Utf8 and poor man fallback to ASCII is presented in the class _WaveRendererBase

[LudwigCRON]

Here is an example of the output generated by this new renderer

[LudwigCRON]

Added support to increase interline with option --eol for instance by using undulate -f term -i ./tests/wavetest.yaml --eol lflf -o - (lf for line feed \n and cr for carriage return \r)

[mithro]

This is super cool!

BTW You might find https://github.com/pieter3d/simview interesting.

[Jbalkind]

How about a graphical terminal output like we've been doing with sootty (https://github.com/Ben1152000/sootty)? Another UCSB project like PyRTL :)

[LudwigCRON]

Hello Jonathan,

It is interesting indeed. After a quick look up into the code of sootty, I see a call to rsvg-convert to convert an SVG into a PNG and then call viu. I was not aware of Viu. the results are impressive on iTerm or Kitty but here is the result I get on gnome-terminal in fullscreen (also valid on Kterminal...so most linux stations, xterm seems to support libsixel I need to check).

The image below presents from top to bottom the png image generated by undulate, the viu rendering, and the rendering from undulate in the terminal.

While I'm convinced of a potential of a terminal rendering (synthesis debug tool or helper for multi-clocks design constraints, ...), I have difficulty foreseeing the potential of viu coupled with this application (teams I'm working with are on linux or windows for specs and synthesis)

I'm currently thinking for a subset of annotations to supports in the terminal renderer and such propositions as yours are welcome

[Jbalkind]

Yeah that's the tradeoff which we specifically wanted to embrace with sootty. From our minimal investigation, only the modern terminals will render it correctly, but if you're using those then you can get this nicer experience. Still a bit slow to render, though.