Instances are renamed every time in MyHDL 0.10

I just upgraded to MyHDL 0.10 and the new API. This fixed a couple of issues I had, but also caused a new one: I get “ToVHDLWarning: Previously used name being reused” warnings every time I rerun conversion. In simulation, blocks are renamed on every run, so that it is necessary to manually add all signals in GTKWave on every iteration. With the code in thread Instance-specific constants in VHDL conversion, the first run gives me biquad0_0, biquad1_0, and biquad2_0. After five reruns, the blocks are named biquad0_0_1_2_3_4_5, biquad1_0_1_2_3_4_5, and biquad2_0_1_2_3_4_5.

EDIT: Apparently this has something to do with IPython.

Doesn’t anyone else use IPython? The workaround is to run the MyHDL code in a fresh kernel every time, but it would be nice to be able to run it in an existing kernel, which used to work in MyHDL 0.9.

That is an unfortunate side effect (bug). Not sure if there is anyone to tackle the issue. Most of the core dev/users seem to be busy with their day jobs. I use IPython and jupyter notebooks often and haven’t run into the issue (not that I noticed).

@hgomersall wants to clean up some of the areas where global states/structures are used, that might help with this issue.

You get much the same problem if you try to do multiple conversions in the same python instance with the scope not changing. You can restrict the scope which I think solves the problem (doing each conversion in a fresh scope).

This is annoying and needs fixing, but I’m yet to find a significant problem in the way we use it (a project with 32000 lines of Python). E.g. tests are fine because the set up a new scope each test.

There is actually a question around naming stuff when you create new objects in the same scope. I suggest the bigger problem is the definition of the python->v* syntax, which at some points needs to trade off safety for the sort of bugs you’re seeing.