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,

    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


    Originally posted in cdnusers.org by nitin_sharma
Reply

  • 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


    Originally posted in cdnusers.org by nitin_sharma
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.