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

"q <= #1 'hx;" compile fail #712

Closed
veripoolbot opened this issue Feb 9, 2014 · 7 comments
Closed

"q <= #1 'hx;" compile fail #712

veripoolbot opened this issue Feb 9, 2014 · 7 comments
Labels
duplicate This issue or pull request already exists

Comments

@veripoolbot
Copy link
Collaborator


Author Name: Aaron Zheng
Original Redmine Issue: 712 from https://www.veripool.org
Original Date: 2014-02-09


In version 3.402, "q <= #1 'hx;" compiles as:
q
<=

1 'hx
;
"1 'hx" should be two numbers as a space seperate them.

@veripoolbot
Copy link
Collaborator Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2014-02-09T11:59:37Z


See #�.

It is not related to spaces, as "q <= 1 'hx" is a number.

@veripoolbot
Copy link
Collaborator Author


Original Redmine Comment
Author Name: Aaron Zheng
Original Date: 2014-02-10T08:21:12Z


Hi redmine,
Does this issue resolved in issue 256?
we always recognize "q <= #1 'hx;" as "q <= (#1) 'hx", not "q <= #(1 'hx)".
Because these statements are in a lib file, I really don't like to update it.

@veripoolbot
Copy link
Collaborator Author


Original Redmine Comment
Author Name: Aaron Zheng
Original Date: 2014-02-10T08:58:55Z


I checked in page 20 of "IEEE Std 1364-2001.pdf", it is illegal to have a space between "1" and "'hx" to express a hex number "1'hx". Am I right?

@veripoolbot
Copy link
Collaborator Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2014-02-10T18:30:57Z


Spaces are definitely legal. Page 20 of my 2001 spec isn't even about this topic, so I'm not sure which version you are referring to. Anyhow they are separate tokens per Appendix A:

hex_number ::= [ size ] hex_base hex_value

The problem is as Verilog-Perl was originally written the number parsing is done at lex stage, and fixing that is a big change that will break other's parsers vs. this one bug.

@veripoolbot
Copy link
Collaborator Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2014-02-10T18:32:57Z


BTW if you would like to attack fixing it, I can provide pointers of how to start. Alternatively you could write a custom Verilog::Preproc that searches-and-replaces as the code is read in.

@veripoolbot
Copy link
Collaborator Author


Original Redmine Comment
Author Name: Wilson Snyder (@wsnyder)
Original Date: 2014-02-10T18:33:39Z


Please post followups to #�.

@veripoolbot
Copy link
Collaborator Author


Original Redmine Comment
Author Name: Aaron Zheng
Original Date: 2014-02-11T01:38:46Z


Sorry, you are right, it is in page 7(I used the page number showed by pdf reader). Maybe I made some misunderstandings of the description.

size ::= non_zero_unsigned_number
non_zero_unsigned_number* ::= non_zero_decimal_digit{_|decimal_digit}

(* means Embedded spaces are illegal)

No space is allowed in "size" or between "[size]" and "hex_base"

Thank you for your reminding of the perl script change.
It is better you can show me how to change it in flex script. But I only learn something basic on flex and bison last weekend.

@veripoolbot veripoolbot added the duplicate This issue or pull request already exists label Mar 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
duplicate This issue or pull request already exists
Projects
None yet
Development

No branches or pull requests

1 participant