Multiple wave per signal

[Peak25500]

Hi drom, Thanks for that tool which I was looking for for years :-) I'm not aware of all the aspects of the software, but why not having the possibility to have multiple "wave" definition for one signal? Something like: { signal: [ {name 'CS', {wave: '1.0....1.', phase: 0.5, ...}, {wave: ....}} ]} This would be nice to have different phases for the same signal at different times. Or maybe change the phase settings? Thanks in advance, Peak

[drom]

Thank you for the kind words. It is technically possible with a bit of syntax cleanup.

Option 1

Support additional options with numerical suffixes.

{signal: [
  {name: 'AB', wave: '0x3', phase: 0.5, wave1: '31x', phase1: 2},
]}

Option 2

Support new property concat ? g = group? ... that will do the trick.

{signal: [
  {name: 'AB', g: [{wave: '0x3', phase: 0.5}, {wave: '31x', phase: 2}]},
]}

Behavior

I see discontinuity problem, when waves may not stick together as one piece. In the following example: A and B combined present discontinuity in the picture:

{signal: [
  {name: 'A',  wave: '0x3'},
  {name: 'B',  wave: '31x'},
  {name: 'AB', wave: '0x331x'},
]}

But in general it is an interesting idea and can be done. PRs welcome.

[Peak25500]

Maybe option 2 seems a good idea with the "concat" keyword :-)

Why not simply use the dot "." operator on the second wave to say it should take the previous value (from the preceding wave) thus without discontinuity? But then I think it has impact on the "wave" object definition itself which should handle differently starting with a dot if concatenated or not.

[haimag]

This feature(Multiple wave per signal) is very useful for the differential signals and clocks (DDR) . The multiple waves' line can be used different colors or styles(solid/dotted/dashed line)

Behavior

I see discontinuity problem, when waves may not stick together as one piece. In the following example: A and B combined present discontinuity in the picture:

{signal: [
  {name: 'A',  wave: '0x3'},
  {name: 'B',  wave: '31x'},
  {name: 'AB', wave: '0x331x'},
]}

But in general it is an interesting idea and can be done. PRs welcome.

[Ganesh-AT]

The original issue and the recent September comment (DDR waveform with one regular clk_p and another dotted clk_n in the same lane, simultaneously) are actually orthogonal requirements. But, they can be addressed with a common proposal as described below. Can @drom give some comments on feasibility and overall impacts to legacy compatibility?

(1) Add the ability to override the skin on a per-signal basis (add a string member 'override_skin' to each signal array member, default value is the skin provided in the config object) - This can address the September comment about dotted lines - we could create a new skin that has dotted lines for selected bricks and use that for a particular lane alone (or keep clk_p at default and use override_skin: 'lowkey' for the clk_n).

(2) Add a wave character 'e' or 'g' - empty or gap - behavior is that nothing is rendered for the period in that lane, so the lane is transparent after rendering that span. (this is needed for the concatenation feature)

(3) Add ability to overlay the rendering of two signal lanes - and WaveDrom can decide that different lanes need to be overlaid (start at the same x,y position) if the name members are literally the same. In the unlikely case that a user wants to have two distinct signal lanes with the same name, they can add invisible zero-width spaces (U+200B) at either end of the name string. This is the only part of the proposal that could break backwards compatibility.

So, the clk_p / clk_n spec and the AB concatenation would look like this:

{signal: [
  {name: 'clk_p/_n',  wave: '010101010101'},
  {name: 'clk_p/_n',  wave: '101010101010', override_skin: 'lowkey'},
  {name: 'AB', wave: '0x3'},
  {name: 'AB',  wave: 'eee31x'},
]}

We can easily play around with the phase in AB (add more helper AB strings too, if needed) if we get any discontinuities.

I would love to hear your comments on this. I am slowly trying to figure out this Git development model with the PRs and all that, but I can try something out for the above set of 3 proposals. I have zero idea about SVG internal details other than that it is actually a bunch of text. Will have a bit of a learning curve figuring out (3) in the context of how WaveDrom implements the SVG rendering part, unless anyone else wants to volunteer.

[Ganesh-AT]

I poked into the code base a bit more, analyzed the SVG files created by WaveDrom, and looked up the SVG specifications to understand it. I dumped out two simple clocks with two different skins:

Default:

Lowkey:

Overlaid (created by manually modifying the text in one of the above SVG files):

The approach to get this using my proposals would involve the following fundamental changes:

1. The SVG defs created by svg2json.pl need slight modification - .s$a{$b} needs to be .s${a}_skinname{$b} : make sure all skin elements have the skinname as the suffix if we want to use multiple skins in one diagram , and the g id of all should have the skinname suffix too. So, .s1 needs to be .s1_default or .s1_lowkey and so on, and g id="pclk" of type s1 needs to become g id=pclk_lowkey of type s1_lowkey / g id=pclk_default of type s1_default

2. Still trying to figure out render-wave-lane.js : appears that the xlink:href referring to the g id with cont[1][i] needs to somehow get the skin name being used - either at that point, or, as part of cont[1][i] itself.

3. The lane.xs passed to translate in renderLaneUses needs to be fixed to refer to the xs of the first signal with that name.

This is just a rough outline of how it could be implemented - I am sure there will be pitfalls, and I welcome any comments from contributors more familiar with the code-base than I am.

[drom]

I agree, that there are two different ideas floating around:

1. concatenated waveforms
2. overlapped waveforms

I would like to see more useful examples before discussing implementation details.

Maybe we should add differential signaling brick if there is a demand for it.

[Ganesh-AT]

I was under the impression (based on looking at responses to previous issues) that adding another type of brick is 'very costly' in terms of the number of combinations that need to be supported. The differential pair is very easily generated by the overlapped waveforms scheme.

Another real-world example where overlapping would be useful is generation of signal lanes with internal delay added - See Fig. 1 and 2 of http://www.ti.com/lit/an/snla243/snla243.pdf

Btw, I do like the idea of getting CLK_P and CLK_N at the top and bottom of the signal lane - maybe we could add a formatting tag to support that type of signal name rendering similar to the overline scheme we are using now?

Major Edit: Adding additional overlap use-case (needing overlap of four '010'/'101'-type waves with different phases) : Figure 3 of https://www.analog.com/media/en/technical-documentation/data-sheets/ADV7533.pdf : I would also like to understand if any of the currently available WaveDrom features can help annotate the tSKEW arc in the above cited figure.

[drom]

Here are basic examples with transition uncertanty:

@Ganesh-AT about examples from datasheets above: It would be quite hard to support all possible types of timing diagram drawings. WaveDrom is not designed to support all of them. Any free-hand vector editor like Inkscape will be better for these cases.

[haimag]

For differential signal or clk, propose adding 4 wave characters, the true signal(pclk) function same as 'PpNn'

[Adivakersharma]

Hi @drom and @Ganesh-AT ,

I didn't get how 3rd waveform is obtained in the image shown below: Please let me know how it is done(Clubing 2 different phase signal with different skintone).