How to connect a wide output port from one module to several modules' narrow input

[enchanter]

I have a module's output is for example 20 bits. And it should be connected to other two modules' input which is 10 bits. Can I do it in sc_main or I have to create another module to do it?

 

I expect something like assign in Verilog:

 

din_a[9:0] = w_dout[19:10];

din_b[9:0] = w_dout[9:0];

 

 

 

[dakupoto]

I have a module's output is for example 20 bits. And it should be connected to other two modules' input which is 10 bits. Can I do it in sc_main or I have to create another module to do it?

 

I expect something like assign in Verilog:

 

din_a[9:0] = w_dout[19:10];

din_b[9:0] = w_dout[9:0];

Hello Sir,

Please DO NOT fall into the trap of trying to directly translate

from Verilog to C++, because it will NEVER work. Verilog and

C++(SystemC is basically a C++ library) are different languages

with different syntax and semantics.

However, accurate solutions can be created in SystemC once

the underlying algorithm is understood. If I am not incorrect,

you are attempting to divide a bit vector into two, and send

one sub bit-vector to one module, and the other sub bit-vector

to another. Please look up the SystemC built-in method range(x, y)

and the operator. (x,y)

Please go over some reference material on SystemC,  otherwise

you would be stuck at each new step. Hope that helps.

[enchanter]

Hello Sir,

Please DO NOT fall into the trap of trying to directly translate

from Verilog to C++, because it will NEVER work. Verilog and

C++(SystemC is basically a C++ library) are different languages

with different syntax and semantics.

However, accurate solutions can be created in SystemC once

the underlying algorithm is understood. If I am not incorrect,

you are attempting to divide a bit vector into two, and send

one sub bit-vector to one module, and the other sub bit-vector

to another. Please look up the SystemC built-in method range(x, y)

and the operator. (x,y)

Please go over some reference material on SystemC,  otherwise

you would be stuck at each new step. Hope that helps.

Thanks for your reply. I used verilog before and I think systemc is make for modeling hardware behaviour otherwise you can use c/c++. And also the SystemC module could possible connected with verilog module during the mix-language verification. So it is hard for me to not compare it with verilog.

 

I know the range operator and it should work with bit vector. But I think I can't do it in sc_main because it will not be a thread and will not be updated on events like clock pos and signal toggling, right?

[apfitch]

In the past people recommended adding extra processes to split or combine the vectors. As you say, you'd have to have some SC_THREAD or SC_METHOD, and for convenience you'd probably need arrays of pointers to signals.

 

However in SystemC 1666-2011 there's a whole new set of features to assemble and dis-assemble vectors of SystemC objects - sc_vector etc.  See section 8.5 on page 400,

 

regards

Alan

[David Black]

While you can model RTL using SystemC, SystemC is really not intended for this low level of abstraction. SystemC works best at higher levels of abstraction such as TLM and untimed algorithms. RTL capabilities allow SystemC to interface with and co-simulate with Verilog and VHDL simulators. In the extreme, you can create RTL models; however, the simulation performance is abysmal compared to those simulators. Verilog (and SystemVerilog) and VHDL simulators have compilers that are RTL aware and can use that knowledge to improve simulation performance over what a simple C++ compiler can. They have RTL domain specific knowledge to allow this; whereas, SystemC is just a C++ library. For example, knowing RTL one can combine all the RTL blocks sensitive to a clock into a single call across all modules, which reduces context switching considerably.

 

Yes, you can model bus splitters/mergers in SystemC by implementing sc_signal channel adapters, and the syntax will be rough. You will need to implement processes to handle event merging/splitting, which adds to overhead.

 

Simplest solution is to hand large bus around and let endpoint processes deal with the subscripting as dakupoto indicates.