Project

General

Profile

[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
  SVN::S4
  Voneline
  WFH
General Info
  Papers

Issue #1488

A strange code generated from a parametric module.

Added by Slava B 14 days ago. Updated 13 days ago.

Status:
NoFixNeeded
Priority:
Normal
Assignee:
-
Category:
-
% Done:

0%


Description

I've seen a strange code generated from a parametric module. I minimized this scenario to a few lines:
module arbiter #(
    parameter VCD_PORT_NUMBER = 3
)
(
    input clk,
    output reg [VCD_PORT_NUMBER-1:0] in_ip2bus_ack,
    output reg [(VCD_PORT_NUMBER*32)-1:0] in_ip2bus_data
);
    always @ (posedge clk)
        begin
            in_ip2bus_ack = 3'b0;
            in_ip2bus_data = 96'b0;
        end
endmodule
The resulting translation is:
SC_MODULE(Varbiter) {
  public:

    sc_in<bool> clk;
    sc_out<uint32_t> in_ip2bus_ack;
    sc_out<sc_bv<96> > in_ip2bus_data;
...
}   
Why Verilator converted Verilog's 3-bit port (in_ip2bus_ack) into 32-bit port in SystemC. The conversion of 96-bit port (in_ip2bus_data) was correct. This is very misleading. Did I miss something?

Thanks, Slava

History

#1 Updated by Wilson Snyder 14 days ago

  • Status changed from New to NoFixNeeded

uints are much faster so are the default. See the Connecting to SystemC part of the manual and the --pins-sc-uint/--sc-pins-biguint flags.

#2 Updated by Slava B 13 days ago

Thank you very much, Wilson! I was not aware about --pins-sc-uint switch!

Also available in: Atom