Gurmeet Singh Taank

Hi Eyck, I will be using this workaround(at the cost of one extra hierarchy). Regards, Gurmeet

Eyck, Earlier bpad_10634.err error was due to the mismatching port widths, I corrected that issue. As per a document, Xcelium implements the IEEE1666-2011 standard for System-C which includes the sc_vector as well. I might be doing something wrong here on specific version usage or improper use of macros/command line options. I have raised a support ticket with Cadence on the sc_vector support in Xcelium. 1. Independently module is compiling with xrun –sysc –sv adder.cpp adder.v (please find the “module_standalone” file attached) xrun -sysc -sv -clean -disable_sem2009 adder.cpp adder.v >> module_standalone 2. When instantiating in the top level adder_tb module elab step is failing (please find the “with_verilog_tb” file attached) xrun -sysc -sv -clean -disable_sem2009 adder.cpp adder.v adder_tb.v >> with_verilog_tb adder.cpp adder.v adder_tb.v module_standalone with_verilog_tb

Thanks Eyck, With the use of vectors, adder.v and adder.cpp are compiling successfully. However if I instantiate the adder.v into my TB its still throwing elaboration error. Please have a look at the attachments.

Hi Experts, How to achieve the port binding for array of vectors in system-C constructors? I want to remove verilog modules and plug-in system-c modules into a big SV test-bench(basically to check the logic equivalence of SC model with RTL using RTL verification testcases). I cannot change the hierarchy of ports here(otherwise lots of RTL verification test cases may fail on the TB). I have already done this work for some modules and its working fine with Cadence Xcelium simulator. However some modules are using the array of bit vectors as their ports which I am not sure how to bind using the verilog shell around them while the port hierarchy is still maintained. Here is a simple dummy example to ease the discussion on this topic: SYSTEM-C MODEL #include <systemc.h> SC_MODULE(adder) { sc_in<sc_uint<4> > a[3]; sc_in<sc_uint<4> > b[3]; sc_out<sc_uint<5> > c[3]; void m_add() { uint8_t i; for(i=0;i<3;i++) { c.write(a.read() + b.read()); } } SC_CTOR(adder):a("a"), b("b"), c("c"){ SC_METHOD(m_add); int i =0; for(i=0;i<=2;i++) { sensitive << a << b; } } ~adder() { } }; XMSC_MODULE_EXPORT(adder); VERILOG SHELL AROUND SYSTEM-C MODEL module adder(input [2:0][3:0] a, input [2:0][3:0] b, output [2:0][4:0] c) (* integer foreign = "SystemC"; *); /* genvar i; generate for(i=0;i<=2;i++) begin assign c = a + b; end endgenerate */ endmodule VERILOG TESTBENCH module adder_tb(); reg [2:0][3:0] a; //Array of vectors reg [2:0][3:0] b;//Array of vectors wire [2:0][3:0] c; //Array of vectors adder adder0( .a(a[2:0]), .b(b[2:0]), .c(c[2:0]) ); initial begin a = #1 2; b = #1 3; a = #10 2; b = #10 3; a = #15 15; b = #15 15; a = #20 9; b = #21 15; end endmodule

As long it is storing the right data in the memory you want to model; this behavior should be fine. If this would have been a purely asynchronous ram hardware this must have happened in the actaul hardware as well since it is imposible to align the edges of two indepedent buses(data and address here) below some practical limits of few pico seconds(however the first write may not settle properly in actual hardware). System-C is not for low level modeling, you should use it for modeling above the RTL level.If you still want to avoid this, one way would be to combine two different buses into single bus(say common_bus) and make the SC_METHOD sensitive to it. common_bus = {data,address} Regards, Gurmeet