• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Community Forums
  2. Functional Verification
  3. Poor SystemVerilog Support in NC?

Stats

  • Locked Locked
  • Replies 7
  • Subscribers 64
  • Views 16070
  • 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
archive over 18 years ago

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
  • Cancel
Parents
  • archive
    archive over 18 years ago

    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)
    {

    }
    }


    Originally posted in cdnusers.org by nitin_sharma
    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Reply
  • archive
    archive over 18 years ago

    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)
    {

    }
    }


    Originally posted in cdnusers.org by nitin_sharma
    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
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.

© 2025 Cadence Design Systems, Inc. All Rights Reserved.

  • Terms of Use
  • Privacy
  • Cookie Policy
  • US Trademarks
  • Do Not Sell or Share My Personal Information