I have a problem with the current build where my top level module passes a value into a child module and that child passes the value into a further child. In the bottom level module the input is just Z. This seems to be caused by the port on the middle module being declared inout rather than input. This design functions properly in version 0.9.6 but not in the latest build.
To run the test just run "iverilog idemo.v" and then "vvp a.out". The simulation will print the value "z" but the correct value is "2".
You need to attach your idemo.v file (SourceForge was having troubles earlier, which may be why it's missing). The simple test case I wrote based on your description works as expected.
Like Martin, I also just checked this with the same results. It worked as I expected. Please attach your example so we can investigate this further.
I have had this problem before with posting attachments. If I attach the file when I open the ticket source forge loses the attachment. I have attached it to this update. I forgot to mention that it only happens with bussed ports on the lowest module.In my example I have single signal inout ports which are concatenated when being passed into the lowest child.
Yes, that's an irritating limitation of SourceForge.
I've reproduced your problem. As a temporary workaround, removing the line
from the /usr/local/lib/ivl/vvp.conf file (assuming you've installed to the default location) seems to fix the problem. I'll look into this tomorrow unless someone else gets to it before then.
Thanks. I can confirm I get the same results as you do. This is likely complicated by the tran and pull devices so it could be that V0.9 was in error and development is correct. We will likely have to look at the standard and/or check the code using a standard simulator to know for sure. This code does produce X with both gplcver and cvc. I will leave this for Martin since I have other things I am currently working on.
This is a result of debugging a set of simulations which work properly with ModelSim. I will verify that ModelSim produces the desired result. I also modified the test to eliminate the pullup/pulldown and tran statements. So that should allay any suspicion you have about those.
Thanks for looking into this. In my real design the middle module is a shim module that is auto generated. And I have multiple of them in the tests. I am looking forward to things not failing spectacularly once this is fixed.
I've pushed a fix for this to the master branch on github.
Thanks for the fix. Most of my simulations are working now.