Signal visualisation: GTKWave and disassemblers

[MarkMLl]

I note one mention of GTKWave in the entire archive of this forum, which was in this topic about a year ago.

Has anybody had any success getting an external filter program working with it? Using e.g. this as a dummy:

Code: (perl) [Select]

#!/usr/bin/perl

$| = 1;                             # Unbuffered output
while (<>) {
  if (/_1/) {
    $_ = 'GPS';
  }
  print($_);
}

I can see the program being entered but I've never actually seen GTKWave pass data to it. From this I conclude that there is some magic bit of GUI configuration that I'm missing on a signal-by-signal basis, but neither the documentation nor Google are any real help.

I appreciate that Perl isn't everybody's cup of tea, but since it has a long-established history for writing filters thought it would be the best example. GTKWave is 3.3.98 running on Debian Linux x86_64.

MarkMLl

[SiliconWizard]

I note one mention of GTKWave in the entire archive of this forum, which was in this topic about a year ago.

Uh, really? Searching for GTKWave in the forum shows 44 results.

I routinely use it.

Has anybody had any success getting an external filter program working with it? Using e.g. this as a dummy:

Code: (perl) [Select]

#!/usr/bin/perl

$| = 1;                             # Unbuffered output
while (<>) {
  if (/_1/) {
    $_ = 'GPS';
  }
  print($_);
}

I can see the program being entered but I've never actually seen GTKWave pass data to it. From this I conclude that there is some magic bit of GUI configuration that I'm missing on a signal-by-signal basis, but neither the documentation nor Google are any real help.

I appreciate that Perl isn't everybody's cup of tea, but since it has a long-established history for writing filters thought it would be the best example. GTKWave is 3.3.98 running on Debian Linux x86_64.

Now I'm sorry - while I've been using GTKWave for a long time now, I've never used filters, and I don't know much about Perl.
For Perl, I know a few people on here would be able to help you. But for GTKWave filters, I'm not so sure.

[MarkMLl]

Now I'm sorry - while I've been using GTKWave for a long time now, I've never used filters, and I don't know much about Perl.
For Perl, I know a few people on here would be able to help you. But for GTKWave filters, I'm not so sure.

I've re-run the search and I was obviously being too specific: 44 it is :-)

I've knocked together another little test program which can generate different line-endings etc. and can confirm that that script works from the command line. I'll start looking at things on a character-by-character basis in case I'm missing something obvious, but will ask on the GTKWave support ML if necessary (and will, of course, report back particularly if I'm making some silly mistake).

Apart from that I'm looking at the feasibility of a general-purpose disassembler which can accept a .vcd from a logic analyser, but thought I'd check what GTKWave could do first.

MarkMLl

[SiliconWizard]

Sorry I can't help here, but I'll be keeping an eye on the topic, as using filters may prove useful one of these days. I've only used GTKWave paired with GHDL so far, and using almost exclusively the format that works best for this, which is ghw and not vcd.

But what exactly do you want to achieve? Would you like to have a disassembler inside GTKWave so that you can see both signals and decoded assembly (for instance for simulating a CPU?)

[MarkMLl]

But what exactly do you want to achieve? Would you like to have a disassembler inside GTKWave so that you can see both signals and decoded assembly (for instance for simulating a CPU?)

Initially, capturing a few hundred asynchronous transitions possibly with partial decoding.

The more-general disassembler is, in part, just to go into the toolkit but I've also got some memory-access stuff I want to look at (40-pin connector going to a Black Blob on a PCB).

I don't necessarily want to express all instrument settings etc. as code, but I /do/ like to have things in a format where they can be permanently archived.

I've now modified one of the filter programs to log every incoming byte, and I can see that GTKWave starts the filter program and releases it in good order when it terminates but never actually writes anything to it. Guess it's time to ask the ML.

MarkMLl

[golden_labels]

Data formatting works per-signal and filters aren’t an exception. Did you select the target signals before applying the filters? Not receiving any input suggests no signals were selected for formatting.

Aside from that, even if you receive the data properly, it’s possible you will still not get the desired result. GtkWave requires the filter program to explicitly flush the output stream after each line.⁽¹⁾ It may or may not appear to work otherwise, but — if it does — it’s a coincidence.

⁽¹⁾ Strictly speaking not after each line, but after all responses GtkWave must receive. But the filter program has no means of reliably determining when that is. So effectively it’s after each line.

[MarkMLl]

Data formatting works per-signal and filters aren’t an exception. Did you select the target signals before applying the filters? Not receiving any input suggests no signals were selected for formatting.

Yes, selected individually etc.

Aside from that, even if you receive the data properly, it’s possible you will still not get the desired result. GtkWave requires the filter program to explicitly flush the output stream after each line.⁽¹⁾ It may or may not appear to work otherwise, but — if it does — it’s a coincidence.

⁽¹⁾ Strictly speaking not after each line, but after all responses GtkWave must receive. But the filter program has no means of reliably determining when that is. So effectively it’s after each line.

Yes, I could see that from the limited examples provided. It effectively expects a one-to-one relationship between input and output.

I've now got another program which reads and logs every byte received: GTKWave isn't sending anything.

MarkMLl

[golden_labels]

Were they selected before applying the filter? Perhaps see if it works if you right-click the channel(s) and select that from a context menu.

I wrote a simple Python script to test the issue and it receives the data. I can only reproduce your description if I don’t select channels to apply the data formatting to.

[MarkMLl]

Here's what I'm doing.

* Start gtkwave, "File" -> "Open New Tab" and select my test file scratch2.vcd.

* In the top-left pane, click on "Top".

* In the bottom-left pane, control-click to select four signals and press "Append".

* In the main menu, "Time" -> "Zoom" ->"Zoom Best Fit".

There are now four traces visible, green on black.

* In the "Signals" pane, select the first signal (timing_ch_1).

* Right-click on this signal, "Data Format" -> "Translate Filter Process" -> "Enable and Select".

* "Add Proc Filter to List" and select my compiled filter (gtkwave_pps).

* Under "Process Filter Select", click on the filter name and then "OK".

There is no visible change to the GTKWave display, but a trace file showing exactly what gtkwave_pps is doing has logged that it has started.

My original VCD file was sparse, with only some leading edges since I was interested in the relative timing. I've edited that to make sure that there are both leading and trailing but it appears to have had no effect.

So it's either something peculiar to this specific version/variant of GTKWave, or I still haven't got the GUI interaction right.

Alternatively GTKWave doesn't like my test data... please could you take a quick look at the attached file using your setup.

MarkMLl

[golden_labels]

Your file contains no data to be translated. For that to be possible, you needs such data. In the case of your file, which only contains wire signals, you may e.g. combine those channels (Edit → Combine Down). Only that can be filtered.

[MarkMLl]

Aha! That explains it: the program that generated it was translating timing data into individual wires and state into parallel data.

I'll have a tinker with the UI as you've suggested or an alternative data file.

MarkMLl

[MarkMLl]

OK, That works. The interesting thing from my POV is looking at what GTKWave actually sends: if I do a "combine down" for
the four signals together and then set up a filter it sends individual hex digits each terminated by (on Linux) \n with no channel identifiers etc., while if I repeat that for each individual signal (four total) it sends groups of 4x lines.

I can confirm that the trivial Perl filter I posted earlier works without locking anything up.

So I think it's not too difficult to e.g. have a group of lines representing a data bus and another representing an address bus strobed (on the capturing hardware) by appropriate control line state, but the risk of things getting out of sync is substantial.

MarkMLl

[golden_labels]

GtkWave doesn’t document, if the translate filter program can be stateful, the corresponding static version of the filter is stateless, and the name itself also suggests statelessness. Currently the observed behavior is that GtkWave simply sends all data ordered by signal and then by time, so it certainly may be used for ad-hoc scripts to provide limited stateful decoding. But I wouldn’t depend on that as a long-term solution.

You may consider looking at the third filtering option: the transaction filter process. It receives a simplified VCD, which is certainly stateful. Or, alternatively, preprocessing your VCD file. Western Digital offers pyvcd — a VCD read/write library for Python — so there is no need to write that part on your own.