Intermediate format for waveforms

[eine]

As shown in 1#issuecomment-379972520, with wavedrom it is possible to get a SVG from a WaveJSON (JSON) file. Although WaveJSON is not the best format for complex signals, it is good enough. I'd like to try to export the VCD output of the full_adder example to an intermediate format that can be then exported to WaveJSON, or to other format, such as tikz-timing.

Following the comments here, @Nic30 what intermediate format are you using between the VCD and the input to your viewer? Is it a JSON or a python structure?

[eine]

Can I use it as a library? I.e. script -i mywf.vcd -o mywf.json.

[Nic30]

Currently it is not possible because functionality is integrated to Flask (webserver) project.
I extract it as separate library tonight.

[Nic30]

I deleted my comment with json format description and added it to readme of new project (format is slightly different than I told before).
https://github.com/Nic30/pyDigitalWaveTools/

https://github.com/Nic30/pyDigitalWaveTools/blob/master/pyDigitalWaveTools/vcd/parser.py
should do the job.

[Nic30]

I also have D3 based renderer for this json format. But it is only prototype.

https://github.com/Nic30/hwtIde/blob/master/hwtIde/static/wave/app.js

[eine]

You are so fast! It is ok that the description of the format is not exactly the same. I will try to write the 'transpiler' as soon as I have a couple of free days.

About the D3 render, (as commented here and here) I think that WaveDrom/WaveJSON is limited by two design decissions:

• It is only meant for synchronous systems, so every signal is read in fixed time intervals.
• A symbol is used for every interval, even if the value of the signal did not change. This means that a signal that is keep 'high' for 10 clk periods is drawn as 10 lines, instead of a single long line.

Because of this, I think that the JSON format you described is very interesting, as it is much more compact for long waveforms with lots of signals. Also, I believe that a different approach is required when creating the SVG, and with your JSON format it is easier to draw the minimum number of lines/symbols without additional pre-computation.

However, I am not sure about rendering (printing the JSON to SVG) in the frontend. It can be quite a heavy task that could be better done in the backend. Then, my approach is to try ajstarks/svgo. I have already used it to mimic WaveJSON in a compiled CLI tool, and I am willing to adapt it to your format. I believe that, once the waveform itself is provided by the backend, D3.js can be used for drawing cursors, zooming, dragging, hiding/showing/expanding/collapsing, adding/deleting arrows, etc.

Following the same path, and just because of curiosity, why did you choose to draw everything with D3.js instead of combining it with some python library such as svgwrite?

---

Just as a reference of what I mean with 'heavy'. Yesterday I did some experiments with threejs.org#webgl_interactive_draggablecubes, because why not try editable 3D schematics (using the modified ELKjs in #1 to layout each layer). The point is that I could create 200 simple cubes, 4k, 10k... but when I tried 100k it could not handle it. 1ms of simulation time with a clock frequency of 100Mhz can easily produce more than 100k values/entries. D3.js is more lightweight than three.js, but I think we should still consider scalability.

[Nic30]

I am not using D3.js as golden hammer (I hope so). It is just coincidence that two data-visualization project are well suited for this library.

Also I think that JS part should be self sufficient visualization tool. SVG importing from server can collide with this principle.