Collect the initial set of requirements

[drom]

A general task to collect the initial set of ideas, requirements that need to address one or more of initial goals:

• Fast enough to render large timing diagrams [Fast rendering #3]
• Zoomable & Scrollable enough to see small details and the big picture [Zoomable & Scrollable #2]
• Embeddable so it can be integrated as a component into bigger UI application [Embedding #9]
• Composable with custom code and behaviors [Composition #6]
• Reactive to render required parts of the continuous stream of from simulator [Input Data Stream #14]

[DrSensor]

For fast rendering, how about using different implementation depend on the density of the data?
For example, use SVG when there are fewer lines to be rendered and switch to WebGL if there is a huge amount of lines.

[Paebbels]

Here are some thoughts from my side:

1. I would like to use Zoom (like WaveDrom) in Sphinx for generating documentations on ReadTheDocs or any other GitHub-Pages / GitLab-Pages HTTP(s) deploy server.
2. I would prefer if Zoom's input format is somehow compatible with the capabilities (not the binary format) of GHW from GHDL. If so, GHDL could add another output format to write such Zoom files. (Referring to the VCD format from Verilog is not enough, because not all VHDL types can be represented in VCD waveform dumps.)
3. Because such files might get bigger then current WaveDrom files, it might be needed to support z-compressed files.
4. Maybe it's possible to convert Zoom files to TikZ-Timing files. If so, documentation written in Sphinx could render with Zoom in HTML and with LaTeX to PDF including waveform diagrams.

[Paebbels]

Other thoughts after reading #2, #3.

• Records or user defined signal groups should be collapsible
• Maybe, a marker for the mouse position, snapping to edges would be some good advanced feature helping to understand bigger waveforms.

[wifasoi]

I have some idea (if i can add):

• shadow on logic high: colorize the shadow under a high pulse to improve readability.
• specify signals group/encoding: a way to specify via cli or file(json or similar) how signal must be grouped/showed, and the encoding you want Zoom to show you. I think that have so you can define wish signals to group/encode via a regex rule would be a nice touch.
• cursors: have a cursor(or multiple) and show the data value (corrisponding the cursor position) somewhere. If you have multiple cursor show some useful statistic (delta T or/and frequency for example)
• analog trace: have a way to show analogue data
• plugins: support plugins that can create/annotate metadata based on the waveform (big word for having a way to create decoder/checkers that can, for example, color the trace that trigger a condition), or generate new traces (user-case: pwm to analog, and why stopping there.. analog/digital to Fourier transform)

those feature are not what i expect from a MVP, but I toss the bone.. maybe someone bites :)

If i can add some of my though: My user-case for using Zoom would be in a CI settings. I wold like to run unit-test on gitlab runners and if they fail, a way to show the result via web-browser.

[DrSensor]

Big +1 for extensibility via plugins. Maybe there is a need to separate Github issue for discussing plugins idea. From there we can conclude the core features that need to be implemented. I think we need to address 3 things: architecture, core features, and the common use-cases (for plugins).

It's a little bit opinionated but maybe using (or just take an inspiration from) svelte could be a good idea since it's just a compiler which can produce either a library or a WebComponents

[nturley]

I'm not sure if I'd call these requirements, but if we are brainstorming on ideas for features, here are some ideas.

• I'm not sure how well it would work, but maybe some kind of mini-map view to orient myself instead of just relying on the scrollbars. I love minimap views in text editors.
• When the hierarchical signal name doesn't fit in the box, by default, show the end of the signal name instead of the beginning ("...dparent/parent/sig" instead of "grandparent/paren...")
• Save/Load the viewer state (position and scale) so I can go back to a specific place in a waveform or compare the same position with two different data dumps. Maybe like a bookmark kind of thing.
• export as png button so I don't need to screenshot it
• annotations
• a sane starting zoom level. I get tired of opening a new waveform and having to hit the zoom out button a million times to see a single clock tick.
• @Paebbels kinda mentioned this, but specifically in regards to VHDL/myHDL data types:
  • enums
  • std_logic values like 'U', 'X', and 'Z'
  • records, (although I guess you covered that when you mentioned "bundles")
• Protocol interpretation. I was debugging an issue with communication with an atmel crypto chip over a one-wire protocol and I found a logic analyzer that knew how to interpret the protocol and command set it used. It displayed what commands I was sending to the device and highlighted parts that violated the spec. That would be super neat to have that in simulation.
• display signal values in decimal, hex, bit string, and line chart and somehow remember the display setting for this signal when I open up the next data dump.

[fusedFET]

It would be nice to have a "phantom" wave which is an overlay on named traces. It could be used to compare captured traces to configured timings (from datasheet / mock) to highlight errors. This could be used complementary with #10. Maybe as plugin?

[Paebbels]

@fusedFET verification by using waveform compares is not a good approach. It has a lot of disadvantages.

[fusedFET]

@Paebbels Sure, but it has a high didactic value for beginners and also is a very useful tool in some situation.

[drom]

It would be nice to have a "phantom" wave which is an overlay on named traces. It could be used to compare captured traces to configured timings (from datasheet / mock) to highlight errors. This could be used complementary with #10. Maybe as plugin?

It does look like plugin related to #10