Stats

  • Locked Locked
  • Replies 7
  • Subscribers 66
  • Views 21312
  • 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

Double back-tick in parametrized macro in SV

sevent

Hello,

The following code does not compile in ncverilog v9.2, I think because of the double back-tick, yet it is an example directly out of the SystemVerilog 1800-2005 spec:

 `define msg(name) name``_suffix

module macro_test;

  initial
  begin
    $display(`msg(foo));
  end
endmodule

$ncverilog macro_test.v

ncverilog: 09.20-p007: (c) Copyright 1995-2009 Cadence Design Systems, Inc.
file: macro_test.v
    $display(`msg(foo));
                     |
ncvlog: *E,EXPCPD (macro_test.v,7|21): expecting a valid compiler directive [16(IEEE)].
(`define macro: msg [macro_test.v line 1], file: macro_test.v line 7)
    $display(`msg(foo));
                     |
ncvlog: *E,NOTDIR (macro_test.v,7|21): `_suffix: not a recognized directive or macro [2.7.3][16.3.1][16(IEEE)].

The `` is supposed to delimits lexical tokens without introducing white space, allowing identifiers to be constructed from arguments.

Is this a bug with ncverilog?

Parents

  •  

    sevent said:
    Using -sv at this point is not an option due to legacy code causing syntax errors in other areas. Using the .sv extension on a more complete example still does not work:

    I'd recommend the keywords approach suggested by StephenH.

    ...but if it's at all possible, I would edit the source-files to make them compatible with Systemverilog syntax. 

    A while ago, I tried to simulate a group of design-files that contained a mixture of legacy Verilog (*.v) and Systemverilog (*.sv) files. That was bad idea -- in the (SV) toplevel file, I implemented a monitor/snooper that read an 2D unpacked reg-array from the Verilog RTL by a hierarchical reference.  This caused all kinds of weird problems until I bit the bullet and hand-edited all the *.v files to be SV compatible, and read all of the files as Systemverilog.

     (For the record, I think I tried to pass the unpacked-array as an input argument to a function.  IUS62 didn't like it.)

Reply

  •  

    sevent said:
    Using -sv at this point is not an option due to legacy code causing syntax errors in other areas. Using the .sv extension on a more complete example still does not work:

    I'd recommend the keywords approach suggested by StephenH.

    ...but if it's at all possible, I would edit the source-files to make them compatible with Systemverilog syntax. 

    A while ago, I tried to simulate a group of design-files that contained a mixture of legacy Verilog (*.v) and Systemverilog (*.sv) files. That was bad idea -- in the (SV) toplevel file, I implemented a monitor/snooper that read an 2D unpacked reg-array from the Verilog RTL by a hierarchical reference.  This caused all kinds of weird problems until I bit the bullet and hand-edited all the *.v files to be SV compatible, and read all of the files as Systemverilog.

     (For the record, I think I tried to pass the unpacked-array as an input argument to a function.  IUS62 didn't like it.)

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.