Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use of // verilator public with inout causes error #58

Closed
veripoolbot opened this issue Jan 25, 2009 · 7 comments
Closed

Use of // verilator public with inout causes error #58

veripoolbot opened this issue Jan 25, 2009 · 7 comments

Comments

@veripoolbot
Copy link

@veripoolbot veripoolbot commented Jan 25, 2009


Author Name: Jeremy Bennett (@jeremybennett)
Original Redmine Issue: 58 from https://www.veripool.org
Original Date: 2009-01-25
Original Assignee: Lane Brooks


I have a model (of the OpenRISC 1000 SoC) which compiles with Verilator 3.700, albeit with a bucketload of warnings.

I've tried extending it to allow external access to a variable by using a @verilator public@ function:

    // Function to access wb_freeze
    function get_wb_freeze;
       // verilator public
       get_wb_freeze = wb_freeze;
    endfunction // get_wb_freeze

This is in a Verilog file a few levels down the hierarchy. @wb_freeze@ is an input to the module. However when I now build the model, I get a completely unrelated error in the top module:

verilator -Wno-lint -Wno-COMBDLY -Wno-MULTIDRIVEN -Wno-UNOPTFLAT -trace -f v_processed.scr \
                 -language 1364-2001 -sc
%Error: rtl/verilog/orpsoc.v:139: Internal Error: ../V3Inst.cpp:94: Width mismatch, should have been handled in pinReconnectSimple
%Error: Command Failed /home/jeremy/tools/verilator/verilator-3.700/verilator_bin -Wno-lint -Wno-COMBDLY -Wno-MULTIDRIVEN -Wno-UNOPTFLAT -trace -f v_processed.scr -language 1364-2001 -sc
make: *** [obj_dir/Vorpsoc.mk] Error 10

The problem seems to be use of @// verilator public@. If I remove this the problem goes away (but then I can't access the function, which was the whole point).

I've attached the script file I used for the build (v_processed.scr), the file with the modified function (or1200_ctrl.v) and the top level file (orpsoc.v).

I realize this may be a consequence of the ignored warnings, but I've flagged the issue early in case it is already known. In the meantime I'll address the warnings and try to reproduce the problems in a clean build.

Running under Fedora 9, with GCC 4.3.0 and SystemC 2.2.

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Jan 25, 2009


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2009-01-25T23:37:02Z


Might be a tristate bug, try changing

assign eth_mdio = 1'bZ;

to = 1'b0;

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Jan 26, 2009


Original Redmine Comment
Author Name: Jeremy Bennett (@jeremybennett)
Original Date: 2009-01-26T08:00:45Z


Thanks for the quick response. I tried changing that tristate with no effect. However there are other tri-state's in the code, which I'll check. I'll also fix the warnings to see if that helps.

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Jan 26, 2009


Original Redmine Comment
Author Name: Jeremy Bennett (@jeremybennett)
Original Date: 2009-01-26T11:49:46Z


I got rid of all the warnings, but the error persisted. I noticed that the signal concerned (@eth_mdio@) is an @inout@ of the underlying module. I temporarily removed it as an argument, together with two other @inout@ signals and the problem went away.

I'll work on putting together a small demonstrator.

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Jan 26, 2009


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2009-01-26T12:56:17Z


Given it's an inout issue and you have a workaround, it's probably Lane's inout code.

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Jan 26, 2009


Original Redmine Comment
Author Name: Lane Brooks
Original Date: 2009-01-26T16:59:49Z


Jeremy,
I recently added very limited support for tristates to verilator, and it is currently very fragile. The only tristate construct that currently works is:

assign Y = (OE) ? 1'bz : A;

It is very fragile in that it must meet the additional rules:

  • A must be a signal (cannot be a const like 1'b1 or 1'b0).
  • The width of 1'bz must be defined (i.e., no 'bZ)

Check out the other issues we have found with tristate as well.

I am in the process of improving the robustness and expanding tristate support. I am not expecting to have an update ready for several weeks.

Lane

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Jan 26, 2009


Original Redmine Comment
Author Name: Jeremy Bennett (@jeremybennett)
Original Date: 2009-01-26T18:22:19Z


Thanks for your hard work on this. I'll try to get some test cases together to help you. My work is all with OpenRISC, so no problem sharing it publicly.

Jeremy

@veripoolbot

This comment has been minimized.

Copy link
Author

@veripoolbot veripoolbot commented Apr 27, 2012


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2012-04-27T02:33:09Z


We'll address this with dpi functions if it comes up again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.