a module has two or more interface A, how to distinguish the related function?

[Ming]

Hi all,

We have a interface A, which defined virtual method put().

Now we want to implement a module B, which has two exports A1,A2 with interface A, and the two exports are realized in module B itself.

How can we register for A1,A2 with different method put()? Or some other solutions?

 

I just searched and found that in TLM 2.0 we can use register_b_transport for socket. How about SystemC and TLM1.0?

Looking forward to your reply. Regards,

Ming

[David Black]

First, there are no "register" methods for basic SystemC nor is this needed.

This is really just a basic C++ question; however, you can use sc_export as part of the solution. You could redirect the call to a submodule that implements the method and bind the appropriate sc_export there. That is what the convenience sockets of TLM-2 do to implement their registration mechanism.

 

[Ming]

Hi David，

Thanks.

So did sc_export solution seem like this?

"add two sub-module B1,B2 to implement interface A, then use sc_port or sc_export in B to connect sc_export in B1,B2."

 

I'm not sure if you know about UVM in system verilog. There UVM defined some macros such as `uvm_analysis_imp_decl to support more than one instantiation of one imp type. UVM defined some related classes to support these macros.

So SystemC have no similar mechanism?

 

Regards,

Ming

[Eyck]

Maybe I got your question wrong. Your module B implements the interface A (by inheriting from A). Now B has two sc_exports A1 and A2. You can bind the implmented interface to both sc_exports:

class A: public sc_core::sc_interface {
  virtual void put() = 0;
};

class B: public sc_core::sc_module, public A {
  sc_core::sc_export<A> A1{"A1"};
  sc_core::sc_export<A> A1{"A1"};
  
  B(sc_core::sc_module_name nm): sc_core::sc_module(nm) {
    A1.bind(*this);
    A2.bind(*this);
  }
  
  void put() override {
    ...
  }
};

If this does not fir to your issue maybe it is a good idea to provide some code snippets to understand what you are trying to achieve.

[Ming]

Hi Eyck,

I guess the two ports which connected to A1/A2 will invoke the same put function? Just like several masters access to  a slave？

If so, that's not what I want.

Sorry that I haven't described clearly.

Let's use an example. Use SystemC to model, a module acts as two axi write slaves. Although same axi interface, but the functionality should be different.

I wonder if these are some macro to support this to avoid more submodules, but it seems no. So we can only use sc_export and submodule, right?

 

Regards,

Ming

[David Black]

See https://www.edaplayground.com/x/S5J3 for an example of my suggestion.

W.r.t. the question, no we don't have macros such as UVM's uvm_analysis_imp_decl. Most C++ programmers consider macros to be evil and dirty. The C++ standards are evolving C++ to remove the need for macros altogether. Macros create bugs that are messy to debug and avoid proper type checking etc. For example, consider:

#include <iostream>

#define MAX(x,y) (((x)>(y))?(x):(y))

int main() {
  int    i=1;
  double j=1.1;
  std::cout << MAX(++i,j) << '\n'; //< what gets printed?
  return 0;
}

Those macros were required in uvm because SystemVerilog has a number of syntactic issues due to the time at which it was invented. They lacked proper multiple inheritance was the primary issue.

To be sure, there are still some good uses for macros, but we need to be thinking of eliminating them when possible.

 

[Ming]

Hi David,

Thank you very much. 

The example on edaplayground works for my issue.

 

I have some guess about macros for information.

As you said, macros may introduce bugs. But maybe UVM introduce macro uvm_analysis_imp_decl to not introduce one another hierarchical level of uvm_component.

 

Thanks. Regards,

Ming

[David Black]

Yes, your reasoning on why they did a macro is correct. They had to work around the existing syntax of SystemVerilog. In uvm-systemc, they may still provide these as a way of providing familiarity for those coming from a SystemVerilog approach. Nevertheless, I would avoid macros in my implementations.

A refactored variation of the solution can move those class definitions inside the channel class. See solution 2 here: https://www.edaplayground.com/x/gzXP. Although less code and fewer files, this approach suffers in case you wish to refine or provide alternatives later.

[Ming]

Hi David,

Thanks very much. These illustrations help me know more about sc_export.

 

Regards,

Ming