Embedding SystemC-AMS into Verilog(-AMS)

[sebs]

Hi there,

 

I am currently trying to simulate SystemC-AMS models with Incisive and Verilog-on-top. For this purpose I have written a Verilog-AMS wrapper and at first tried to simulate a simple SystemC model with the following ports:

#include <systemc>

SC_MODULE(my_mod)
{
  sc_in<double> sig_in;
  sc_out<double> sig_out;
  ...
};

The VAMS wrapper basically looks as follows:

`include "disciplines.vams"
`timescale 1ns/1ns

module my_mod_wrapper (in_if, out_if);
     input in_if;
     wreal in_if;
     output out_if;
     wreal out_if;

     real out_ext_temp;
     reg[63:0] in_ext;
     wire[63:0] out_ext;

     assign out_if = out_ext_temp;

     initial begin
          in_ext = $realtobits(in_if);
     end

     always @(in_if) in_ext = $realtobits(in_if);
     always @(out_ext) out_ext_temp = $bitstoreal(out_ext);

     my_mod my_mod_inst(.sig_in(in_ext), .sig_out(out_ext));
endmodule

module my_mod(sig_in, sig_out)
     (* integer foreign      = "SystemC";   *);

     input[63:0] sig_in;
     logic[63:0] sig_in;
     output[63:0] sig_out;
     logic[63:0]  sig_out;
endmodule

However, when changing the port types of my_mod from ...

sc_in<double> sig_in;
sc_out<double> sig_out;

... to ...

#include <systemc-ams.h>
...
sca_tdf::sca_in<double> sig_in;
sca_tdf::sca_out<double> sig_out;

... in order to have SystemC-AMS ports, the simulator gives the following error message:

ncelab: *E,SCK923: No valid SystemC port found in exported SystemC module that matches with HDL port in corresponding shell HDL module: 
Module name is 'my_mod'
Instance name is 'top.my_mod_wrapper_inst.my_mod_dut'
Port name is 'sig_in'
In file: sc_cosim.cpp:4969.
ncelab: *E,SCK954: Error connecting port of SystemC module instantiated in HDL: 
Module name is 'my_mod' 
Port name is 'sig_in'
In file: sc_cosim.cpp:1446.
ncelab: *F,SCIPCF: Could not connect port 'sig_in' for instance 'top.soc_wrapper_inst.my_mod_dut'.
irun: *E,ELBERR: Error during elaboration (status 2), exiting.
make: *** [run] Error 1

So it seems I cannot simply use this way of connecting double ports to reg/wire types, although sig_in and sig_out are from type double in both cases.

 

What is the best way to connect SystemC-AMS modules to Verilog(-AMS) in my case?

 

Cheers,

Seb

[maehne]

Based on the error message, Incisive seems to be only able to connect Verilog signals to Discrete Event ports of a wrapped SystemC module, i.e., of type sc_core::sc_in<T> or sc_core::sc_out<T>. You will have to wrap your SystemC-AMS TDF model accordingly. It may already suffice to use TDF converter ports of type sca_tdf::sca_de::sca_in<T> or sca_tdf::sca_de::sca_out<T> instead of pure TDF ports of type sca_tdf::sca_in<T> or sca_tdf::sca_out<T>. They ensure the sampling of DE signals to TDF samples and vice versa.

 

If that doesn't fix the error, you will have to further wrap the TDF model into a SC_MODULE having only SystemC ports of type sc_core::sc_in<T> or sc_core::sc_out<T>.

[Martin Barnasconi]

I propose to take one step back, and before diving into the technical challenges of your request, just briefly explain to us why would you like to embed SystemC-AMS in Verilog-AMS?

 

For me this sounds a bit strange, as I expect you might need to embed a more refined or detailed models (e.g. in Verilog-AMS) into a System-level model (e.g. SystemC-AMS) and not the other way round. Furthermore, as SystemC AMS supports conservative and signal flow modeling, I could argue there is no need at all to use Verilog-AMS. So why not stick to SystemC and SystemC-AMS?

 

When you use Incisive, you can do a SystemC-on-top design. SystemC on top gives you much more flexibility and power than Verilog on top, for example you can easily include C/C++ functions, use the concept of interfaces, transaction-level modeling, and all these essential features you need to create a good system-level testbench or virtual prototype for/of your system.

I would recommed reading the manual how to use ncsc_run or irun to do SystemC on top.

 

If you then want to include SystemC-AMS, just compile this library together with the build-in SystemC library of Incisive. This is feasible as the SystemC-AMS PoC fully relies on the SystemC standard API, which is supported and implemented by most EDA vendors. For example, you put  all SystemC-AMS source files in a fileset (.f) and pass it in one go to irun. 

 

After this preparation you can make your design, and make the connections as suggested by Torsten, by using the TDF converter ports of type sca_tdf::sca_de::sca_in<T> or sca_tdf::sca_de::sca_out<T> to connect to a SystemC sc_in<T> or sc_out<T>.

 

Such approach saves you from the big hassle to deal with multiple languages, and above all from the ugly and inefficient $bitstoreal and $realtobits.

 

Just my 2 ct ;-)

[Kevin.Cameron]

The fundamental problem with doing this kind of thing is that SystemC doesn't have any real concept of drivers and receivers and how to mix driver/receiver types on a wire.

 

Having said that you can usually bridge stuff with PLI/VPI/DPI code - which is more portable anyway. You just hook-up/create your SystemC during initialization rather than doing the "foreign" module thing at elaboration, e.g. paraphrasing Sebs solution:

 

module my_mod(sig_in, sig_out)
     input[63:0] sig_in;logic[63:0] sig_in;
     output[63:0] sig_out; logic[63:0]  sig_out;

     initial begin

         $hook_up_sysc(sig_in,sig_out,<extra args>);

     end
endmodule

 

From my perspective simulation is flat and considering one thing or another as being "on top" isn't really helpful other than it defines the namespace, you should be able to add, subtract and rewire stuff as you go (particularly when it's C++). Verilog has hooks for doing that since the simulators usually have to talk to other applications and things like emulators.

[sebs]

Thanks a lot for your comprehensive explanations! 

 

@Torsten: I tried out your second proposal and it indeed worked! So what I did: I created a SystemC SC_MODULE wrapper with sc_in<double> and sc_out<double> ports and mapped them to sca_tdf::sca_signal<double> via dedicated bridges that have the following ports:

SCA_TDF_MODULE(out_bridge)
{
  sca_tdf::sca_in<double> in;
  sca_tdf::sc_out<double> out;
...
}

and

SCA_TDF_MODULE(in_bridge)
{
  sca_tdf::sc_in<double> in;
  sca_tdf::sca_out<double> out;
...
}

@Martin: The main intention is to use a SystemVerilog/UVM test bench on top. So, that's why I wanted to use a Verilog-AMS wrapper. However, I found out that using a simple SystemVerilog wrapper is sufficient in this case, because the interface is purely discrete when connecting it to the aforementioned SystemC wrapper.

 

@Kevin: So, when I get you right $hook_up_sysc is a user-defined function that hooks up the SystemC module via e.g. DPI-C? If so, how would such a hooking look like?

 

Kind regards,

Seb

[Kevin.Cameron]

"So, when I get you right $hook_up_sysc is a user-defined function that hooks up the SystemC module via e.g. DPI-C? If so, how would such a hooking look like?"

 

You also need a process sensitive to the inputs that will invoke the SystemC, or you'll need to use the value-change callback. For the outputs of the SystemC you can use the PLI signal update function -  vpi_put_value.

 

There are plenty of VPI/PLI code examples on the web. DPI is newer, but only works with SystemVerilog.

 

If you try doing it with Icarus Verilog you can post questions into their user forum/reflector and the simulator code willl be debuggable.If I remember right the VPI handles in Icarus are just C++ pointers to the relevent class objects, so it's fairly efficient.

 

Kev.

[sm2345110]

Sorry , No idea about i would like to say concern with the experienced person. who have at least 5 to 10-year experience  Embedded system. 

 

Sharon maxwell

CETPA Infotech Pvt Ltd