Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2011-06-21T15:38:40Z

There are several DPI fixes in the git version, is this against that or the release?

Original Redmine Comment
Author Name: Chandan Egbert
Original Date: 2011-06-21T16:46:33Z

It is against the very latest I pulled from git last night.

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2011-06-21T19:00:24Z

Hints on debugging:

You can see the internals.txt file in the distribution directory.

Modify test_regress/t_dpi_export.v to show the problem.

Then run test_regress/t/t_dpi_export.pl --debug.
and/or --debugi-V3Task 9

You'll see the test_regress/obj_dir/t_dpi_export/.tree files and probably see the relevant additions of DPI wrapper code occurs in the _task.tree step. So, the code is probably
broken in V3Task.cpp.

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2011-06-22T00:45:48Z

I noted the t_dpi_export.v test already had a 96 bit task, and checks that the value gets passed. You might want to compare that with your failing case to see what's different.

Original Redmine Comment
Author Name: Chandan Egbert
Original Date: 2011-06-22T18:28:36Z

Actually, t_dpi_export.v has a 95 bit task (input bit [94:0] i ...). If I change it to 96 bits or 128 bits, I see the problem. It seems like there is an issue with integer multiples of 32 bits.

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2011-06-22T18:32:40Z

Ahh, a big hint. Do you want to stab more at repairing this?

Original Redmine Comment
Author Name: Chandan Egbert
Original Date: 2011-06-22T19:25:35Z

I spent a few hours trying to nail down the cause of the problem, but no luck. I will look at it more on the weekend and if I need help, I'll yell.

Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2011-06-29T00:47:32Z

Had a few minutes to took a look, it's an emitter problem. Fixed in git.