[logo] 
 
Home
News
Activity
About/Contact
Major Tools
  Dinotrace
  Verilator
  Verilog-mode
  Verilog-Perl
Other Tools
  BugVise
  CovVise
  Force-Gate-Sim
  Gspice
  IPC::Locker
  Rsvn
  Schedule::Load
  SVN::S4
  Synopsys-modes
  SystemPerl
  Verilog-Pli
  Voneline
  Vregs
General Info
  Papers

Issue #58

Use of // verilator public with inout causes error

Added by Jeremy Bennett over 3 years ago. Updated 25 days ago.

Status:NotEnoughInfo Start date:01/25/2009
Priority:Normal Due date:
Assignee:Lane Brooks % Done:

0%
Category:Unsupported
Target version:-

Description

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.

orpsoc.v - Top level file (5.6 kB) Jeremy Bennett, 01/25/2009 08:05 pm

or1200_ctrl.v - File with // verilator public function (26.4 kB) Jeremy Bennett, 01/25/2009 08:05 pm

v_processed.scr - Verilator script file (10.2 kB) Jeremy Bennett, 01/25/2009 08:05 pm

History

#1
Updated by Wilson Snyder over 3 years ago

Might be a tristate bug, try changing

assign eth_mdio      = 1'bZ;

to = 1'b0;

#2
Updated by Jeremy Bennett over 3 years ago

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.

#3
Updated by Jeremy Bennett over 3 years ago

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.

#4
Updated by Wilson Snyder over 3 years ago

  • Subject changed from Use of // verilator public with function causes error to Use of // verilator public with inout causes error
  • Category set to Unsupported
  • Status changed from New to Assigned
  • Assignee set to Lane Brooks

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

#5
Updated by Lane Brooks over 3 years ago

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

#6
Updated by Jeremy Bennett over 3 years ago

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

#7
Updated by Wilson Snyder 25 days ago

  • Status changed from Assigned to NotEnoughInfo

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

Also available in: Atom