Cannot use transaction filters in Windows #416

rburkey2005 · 2025-02-21T13:40:34Z

(Environment: Windows 11, GTKWave 3.3.100 as installed by the iverilog+gtkwave installer found here.)

I have two transaction filters which I'm using fine with GTKWave in Linux and Mac OS, and am now trying to do so in Windows. However, the method for applying the filter that's described in the GTKWave documentation does not work in Windows. For reference, here's what the documentation says to do:

To turn on the filter:

1. Highlight the signals you want filtered [and in my case, Combine Down]
2. Edit->Data Format->Transaction Filter Process->Enable and Select
3. Add Transaction Filter to List
4. Click on filter filename
5. Select filter filename from list
6. OK

In Windows this fails at steps 4/5, because the transaction filter (a Python file) selected at step 4 does not appear at step 5; i.e., the "Transaction Process Filter Select" pane of the "Select Transaction Filter Process" pop-up window remains empty after step 4, so there's nothing to select at step 5.

As an alternative to applying the transaction filters by using GTKWave's GUI interface, I have "Save Files" (i.e., *.gtkw files) that I use successfully in Linux and Mac OS that apply the transaction filters to my data. When I use the Save Files in Windows, my signals are appropriately combined, but the expected effect on the displayed traces is absent. In other words, it is simply as if the transaction filters specified by the Save File have been ignored completely. Even if I run gtkwave from the Windows command line, there are no error or warning messages indicating that anything out of the ordinary has happened.

Below is a screenshot that compares the effect of the Save File in Windows 11 (top) and Linux (bottom). The traces labeled Inst/Instruction and U are where the transaction filters are applied. In the Linux portion of the screenshot, the transaction filters have reinterpreted the associated signals as assembly language instructions (in the Instruction trace) and addresses (in the U trace). In the Windows portion, the Inst and U traces simply show the normal Combine-Down representation of the signals as hexadecimal numbers.

tbybell · 2025-02-22T19:49:01Z

See if trivial transaction filters work on windows and if there are path issues. The transaction filter code on Windows was written very long ago and not touched, so it should probably still work.

I'm wondering if your python is not being found or if you need a wrapper over your .py file that calls python and the script or whatever.

rburkey2005 · 2025-02-23T00:53:12Z

Good call! I wrote Windows batch files of the form

python MyTransactionFilterName.py

for both of my transaction filters, and with those, the process works perfectly.

As far as I'm concerned, that solves the problem. But I'll leave this issue for you to close rather than doing it myself, since it seems to me that it would be a good idea to note in the documentation that this gimick might be needed in Windows. (If the documentation says that already, it must have gone right over my head.)

Thanks!

awschult002 · 2025-02-27T16:28:40Z

I am also having some issues with transaction filters and processing via AWK.

I have done a lot of investigation and I believe that the transaction filtering is broken.

I say broken, because there is a lot of indication that any script can be used for processing. But that is simply not the case. Or at least, not without a work around. And certainly not through the filter widget.

After looking at the source code, I believe the issue is how the program is creating the child process and passing around arguments (amount other issues).

Gtkwave directly handles the creation of pipes, forking, and processe image replacement with execl(). Which should be fine except that gtkwave doesn't pass the arguments into that function correctly. Not only does it not pass correctly. It also doesn't do it at the correct time. As the process appears to open and run at the insertion into the filter list as opposed to on the OK selection.

Using execl() directly in this manner prevents scripts from running and only allows the direct execution of absolute Path executables. So we have to do a work around where we call python or awk, then pass our script in as an arg. But as I said. Arch are not handled correctly, nor at the right time. So it just fails.

I recommend a cleaner solution where you replace the pipeio_create() function with popen(). Thus allowing all scripts and executables to run without having to worry about executable paths or stream handling.

tbybell · 2025-02-27T19:06:00Z

The "args" aren't what they appear. They're broadcast down into the executable through a $comment args directive on stdin. The forked/executed process does not take command line args.

The translation filter feature was implemented back in 2010 (version 3.3.6). People using it now are the first to use scripts since then, workarounds were figured out, or they just gave up. For now, I would say use a form of wrapper executable.

I didn't use popen() for a reason. It's not bidirectional: we need to get data both into and out of the process. IIRC, passing file descriptors is possible Unix Domain Sockets or STREAM-based pipes, but I opted simply to do handwaving with dup2() and double fork()ing to get to the child's stdin/stdout.

awschult002 · 2025-02-28T12:17:52Z

Do you accept pull requests?

rfuest · 2025-02-28T15:47:19Z

8000

Do you accept pull requests?

Just a heads up regarding external filter programs in GTKWave 4. I've already refactored the code to use the methods provided by Glib/Gio to run the filters, which should abstract (almost) all differences between the OSes away. This code hasn't been merged yet, because it depends on other not yet merged changes.

Because of this if wouldn't make a lot of sense to work on filters in the development branch at the moment, but I cannot speak for GTKWave 3.3.

awschult002 · 2025-02-28T16:16:28Z

Thank you for the heads up

tbybell · 2025-02-28T16:58:14Z

I can look at any push requests vs LTS, but I can't guarantee I'll integrate them. Fixing broken behavior is one thing, and changing behavior is another. That said, I'm open to push requests. Getting scripts working seems to be reasonable.

My main concern right now is I don't know who is doing what with existing code, so I don't want to make any drastic changes. That's one of the good things with the development branch (really, now main branch) Ralf has cooking: he can make interfaces much cleaner and toss all the legacy cruft.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Cannot use transaction filters in Windows #416

Cannot use transaction filters in Windows #416

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Cannot use transaction filters in Windows #416

Cannot use transaction filters in Windows #416

Comments

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!