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/_Signal.py", 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):
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
There is a file tb_run.py 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
To reproduce the problem you must set trace to True in more than one test case.
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,
Josy
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.
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 "tb_simtest.py", line 39, in <module>
testx(tb_barrel_shifter.tb_barrel_shift_pipelined(),trace=False,directory="./waveforms")
File "tb_simtest.py", line 23, in testx
sim.run()
File "/usr/local/lib/python2.7/dist-packages/myhdl/_Simulation.py", line 148, in run
_extend(s._update())
File "/usr/local/lib/python2.7/dist-packages/myhdl/_Signal.py", line 213, in _update
self._printVcd()
File "/usr/local/lib/python2.7/dist-packages/myhdl/_Signal.py", 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.