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.

Sign up for GitHub

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

Jump to bottom

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
Labels
resolution: abandoned Closed; not enough information or otherwise never finished type: feature-IEEE Request to add new feature, described in IEEE 1800

Comments

@veripoolbot
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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.

@veripoolbot veripoolbot added resolution: abandoned Closed; not enough information or otherwise never finished type: feature-IEEE Request to add new feature, described in IEEE 1800 labels Dec 22, 2019
@veripoolbot veripoolbot mentioned this issue Dec 22, 2019
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
resolution: abandoned Closed; not enough information or otherwise never finished type: feature-IEEE Request to add new feature, described in IEEE 1800
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@veripoolbot