Stats

  • Locked Locked
  • Replies 7
  • Subscribers 64
  • Views 16064
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Poor SystemVerilog Support in NC?

archive

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.


Originally posted in cdnusers.org by chm
Parents

  • 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?


    Originally posted in cdnusers.org by chm
Reply

  • 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?


    Originally posted in cdnusers.org by chm
Children
No Data

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.