Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Syntax error with `define function using unneccesary double-ticks #1065

Closed
veripoolbot opened this issue May 29, 2016 · 3 comments
Closed

Syntax error with `define function using unneccesary double-ticks #1065

veripoolbot opened this issue May 29, 2016 · 3 comments
Labels

Comments

@veripoolbot
Copy link
Collaborator

@veripoolbot veripoolbot commented May 29, 2016


Author Name: Dave Storrar
Original Redmine Issue: 1065 from https://www.veripool.org
Original Date: 2016-05-29


The following `define function results in a syntax error when used in a declaration assignment.

`define convertToDB(x)   (20.0 * $log10 (``x``))
module test;
  real a;
  initial
     a = convertToDB(7056.0/8192.0);

  real b = `convertToDB (7056.0/8192.0);
endmodule

%Error: testcase.sv:7: syntax error, unexpected OPERATOR, expecting CLASS-IDENTIFIER or COVERGROUP-IDENTIFIER or TYPE-IDENTIFIER

I've worked around the issue by regsubbing any unnecessary double-ticks in the define function of Preproc before passing it to the super-function.

@veripoolbot

This comment has been minimized.

Copy link
Collaborator Author

@veripoolbot veripoolbot commented Jun 1, 2016


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2016-06-01T01:44:19Z


The standard in this area only says that double ticks form a single lexical token, so this is an example that is either illegal, or at best in unspecified language territory. Since the preprocessor is very sensitive to small changes (because IEEE didn't well specify it), I would prefer not to change to support this illegal syntax at this time as there's a fairly large risk it will break some other area of the preprocessor (again it's unstable because it's relying on a pile of non-IEEE specified behaviors to be close to compatible with other simulators). So, the input code must be fixed to be legal. Sorry.

@veripoolbot veripoolbot closed this Jun 1, 2016
@veripoolbot

This comment has been minimized.

Copy link
Collaborator Author

@veripoolbot veripoolbot commented Jun 3, 2016


Original Redmine Comment
Author Name: Dave Storrar
Original Date: 2016-06-03T13:36:34Z


Thanks for looking at this. I couldn't work out whether this was illegal or not - happy enough to either fix the input code or (maybe) continue with my workaround.

-Incidentally, have you any idea why the assignment to 'a' is OK, while the one to 'b' throws the error? (Not important - just curious).-
(update - just noticed the missing tick for the assignment to 'a' :-$ )

@veripoolbot

This comment has been minimized.

Copy link
Collaborator Author

@veripoolbot veripoolbot commented Jun 5, 2016


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2016-06-05T20:34:19Z


'a' isn't using a macro at all, so that is why it works.

@veripoolbot veripoolbot added the wontfix label Mar 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.