Mutiple traces/simulations in one run

I want to run several simulations (e.g for different instances or the same instance with different parameters) from one main script.

So I have a function:

def test(inst,**kwagrs):

Than I can call test with a block instance like this:


It works, but only when the last test call has Trace=True set and all others are false.
If want to trace several simulation runs the following errors haben:

When there is a run with trace=False after a run with trace=True I get

 File "/usr/local/lib/python2.7/dist-packages/myhdl/", line 333, in _printVcdBit
    print("%d%s" % (self._val, self._code), file=sim._tf)

When I have more than one run with Trace=True, all but the first vcd file are corrupted.
I have not analyzed the vcd in detail (I’m not really familiar with the format), but what I noticed is that tokens are not uniqure anymore in corrupted traces (see reset and shift_right below):

$scope module tb_barrel_shift_pipelined $end
$var reg 1 ! reset $end
$var reg 1 " fill_i $end
$var reg 1 # clock $end
$var reg 1 ! shift_right $end
$var reg 5 $ shift_in $end
$var reg 1 % ready_o $end
$var reg 32 & d_o $end
$var reg 1 ' en_i $end
$var reg 32 ( d_in $end
$scope module ClkDriver0_0 $end

I assume that something is not reinitialized correctly with sim.quit().
I have also taken a look into the code of traceSignals and Simulation, but I could not see any easy to identify problem

Hi Thomas,

Can you share more of the design (or complete)? It is not clear to me how you schedule things.


Hi Josy,
the whole project can be found here:

There is a file in the project root. The idea is to run one test other each other. The subdirectory tb contains the test benches. The final idea will be to use some unit testing lib (like pyunit), but for the moment I’m trying to limit the amount of things to learn in the same time :slight_smile:

To reproduce the problem you must set trace to True in more than one test case.


Hi Thomas,

I cloned your repository (once more).
After editing it to make it compatible with Python 3.7.2 and PyDev / Eclipse I could run the simulations.
Learned that it is better to specify a name for every simulation, else you get the previous name (and the file generated before with that name gets a numerical suffix). (I always specify a name both for conversion and simulation).
I prefixed the names with a sequence number, and then found that 2, 3, 5, 6 and 10 throw a parse error in Impulse / Eclipse; the other five seem OK
If I simulate those suspect benches separately, they all turn out fine.

So there is a weird interaction …

Best regards,

PS: I be travelling this week and probably will only surface on the net by the end of the week …

Don’t worry I also have only limited time for my MyHDL project currently.

My project is WIP and unfortunately not in state to be easily adopted by somebody else, so sorry for any inconvenience.
I expected that the observed behavior is a known limitation of MyHDL and was just expected confirmation of it on my question.

That you started investigation, shows me that it is not expected.

I have simplified test bench:

which just uses the Barrelshifter module as dut.

The functions test() and testx() in this testbench are lead to the same result.
When running the testbench it creates the following stackdump:

Traceback (most recent call last):
  File "", line 39, in <module>
  File "", line 23, in testx
  File "/usr/local/lib/python2.7/dist-packages/myhdl/", line 148, in run
  File "/usr/local/lib/python2.7/dist-packages/myhdl/", line 213, in _update
  File "/usr/local/lib/python2.7/dist-packages/myhdl/", line 333, in _printVcdBit
    print("%d%s" % (self._val, self._code), file=sim._tf)
ValueError: I/O operation on closed file

I think that the global state of the trace system is not reinitialized correctly or the simulation has some reference to outdated objects. That the file is closed seems correct, because the second simulation run is started with trace=False. But some part of the system still thinks that it should write a trace…

The inconsistencies in the vcd files when two simulations with trace=true are run after each other most likely have the same root cause.