Poor SystemVerilog Support in NC? 

I have tried to use SystemVerilog in NC and I have noticed that several basic features of SV are not (yet) supported. I am not speaking of exotic stuff, but things that have been supported by the two big competitors for quite some time now.

For example, the string datatype (although I have been told that strings will be supported in the next release).

But what's much worse is that the DPI implementation is seriously limited, it seems that time consuming tasks cannot be exported to C. Unless I'm missing something - which is entireliy possible - this renders the DPI interface completely useless for creating transactors.

module dpitest (input CLK);
  export "DPI-C" task sv_idle;
  task sv_idle(input int cycles);
     repeat (cycles) @(posedge CLK);
  endtask
endmodule

ncelab: 05.81-p002: (c) Copyright 1995-2006 Cadence Design Systems, Inc.
ncelab: *E,TSKTIM: Exported task sv_idle cannot consume time during simulation.

How are other readers of this forum implementing transactors that are driven from the C side? How could one use SystemC for verification if there is no way to get transactions through the DPI interface?

chm.

Hi,

A way to get around this problem would be to use the DPI method from C to write into a systemverilog list. This list in systemverilog maintains the list of transactions to be driven by the systemverilog transactors. The transactors in system verilog can than look at the list and drive the transactions listed in the list.

This keeps the DPI method not to be time consuming and also allows you a flexibility later when you might want to add some query DPI methods to query the state of system verilog transactors. You can also later on add the method to add, insert, delete transactions queued to the system verilog transactor.

If you are using SystemC, why not implement the transactor in systemc itself. The method control_foreign_signal provides a good way to drive signals in RTL from systemC. That way you do not have to go across the language boundary if you do not have to.

Nitin

Hi Nitin,
thanks for the quick response.

I am not using SystemC myself an I thought SystemC would be typically connected through DPI. Apparently it's not, thanks for poiting that out.

As for your idea. The problem is that the transactor has been implemented is working fine under Modelsim at the moment. I was just trying to use NC (to balance out the license usage), so I don't really want to re-write the thing from scratch.

But even if I would, I have trouble understanding your approach, perhaps I need to explain a little better what I'm doing.

I am running system level verification and HW/SW co-simulation. I run the actual target code, compiled under Linux. All register accesses are wrapped and talk through the DPI to the hardware. In the DPI transactor, I import a function ("c_main()") from C, and this one I call from an initial statement. At this point all the control is passed to the C side, and the drivers and code is executed over there. Whenever the SW writes to a register, it calls (through a couple of layers) a task that is exported from the dpitransactor. So the imported function is calling exported (time consuming) tasks, this is - to my knowledge - valid.

Now, and this is where I cannot follow you anymore, if I were to communicate the transactions in zero time, and send them over to the RTL side, at what point could I, from the C side, make simulation time pass, so that the transactions are actually executed?

Thinking about it, I don't think it's possible. I would need to have the c_main() return for time to proceed, right?

Hi chm.

Strings are already being supported in IUS5.82, which has been available since August.
If you're really into SystemVerilog, it's worth tracking the latest IUS versions, as new features are coming along in each release.

For specific features that you need, please do file a support ticket, or better still talk to your local Cadence AE, who can help not only with language specifics, but also with SV methodology.

Steve.

Hi Steve,
I do have a support call open with my AE and I am waiting for his response. (It was also his advise to wait for 5.83 to get support for strings)
In the meantime what I was interested in was feedback from other users on how they are using the DPI for transactors.
cheers,
chm.

Hi chm,

I read you post with interest, I am a Cadence PE working on our Hardware/Software verification solution, and I noticed that you are facing some hardware software challenges. Whilst I don't have a solution to your immediate SystemVerilog problem, we do have a capability that would allow you to interface directly from a coverage driven verification environment to your embedded software for stimulus, checking and coverage purposes. It would be compatible with you host code modeling methodology as well as when you insert an ISS or HDL CPU model into the design. If you want to discuss this more drop me a mail at giles@cadence.com 

Giles 

Hi Chm,

Sorry, I was not able to reply to your mail earlier.

Thinking a bit more about your problem, I was wondering if the C portion of your testbench is simulation clock aware at all? If not, how hard would it be for you to create a time aware layer in your C code?

The solution, I had in mind was to run your C application as an SC_THREAD in systemC. You can make the SC_THREAD sensitive to the clock in verilog design. SC_THREAD in systemC can consume time by waiting on event. You can therefore modify your read and write methods to be something like this:

while (read_not_done_in_verilog)
{
wait until next clock edge;
if (read_done_in_verilog)
{

}
}

Hi Chm,

Sorry i clicked the Submit button prematurly.

Thinking a bit more about your problem, I was wondering if the C portion of your testbench is simulation clock aware at all? If not, how hard would it be for you to create a time aware layer in your C code?

The solution, I had in mind was to run your C application as an SC_THREAD in systemC. You can make the SC_THREAD sensitive to the clock in verilog design. SC_THREAD in systemC can consume time by waiting on event. You can therefore modify your read and write methods to be something like this:

while (read_not_done_in_verilog)
{
wait until next clock edge;
if (read_done_in_verilog)
{
read_not_done_in_verilog = false;
read_date = read_data_from_verilog;
}
}