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

A few fails while parsing ivtest in the sv-tests environment #28

Open
caryr opened this issue Dec 19, 2020 · 5 comments
Open

A few fails while parsing ivtest in the sv-tests environment #28

caryr opened this issue Dec 19, 2020 · 5 comments
Assignees

Comments

@caryr
Copy link

caryr commented Dec 19, 2020

I noticed sv-parser does an excellent job of parsing most of the code in the sv-tests test bench (https://github.com/SymbiFlow/sv-tests). While working to get ivtest clean I noticed there are a few of our test that sv-parser is failing. One actually looks like a crash. If you were not aware of this TB I wanted to let you know. As one of the developers on Icarus Verilog I am interested in getting it and our regressions as clean as possible. This includes finding things we may have done incorrectly in our regressions so when I see a tool that is parsing most thing I want to know if it is something at our end our a miss on your end. Unfortunately the output they are showing does not indicate why the parse is failing so it's hard for me to know what the issue is.

@dalance dalance self-assigned this Dec 20, 2020
dalance added a commit that referenced this issue Dec 21, 2020
@dalance
Copy link
Owner

dalance commented Dec 21, 2020

Thank you for your information!
I checked the failed cases.

  • br_gh330.v
    This is caused by huge nested expression.
    I'll consider the way to fix it.

  • escaped_macro_name.v, pr1758122.v
    They are bugs of parser, and have been fixed.

  • sv_queue_real.v, sv_queue_string.v, sv_queue_vec.v
    This is caused by '{}.
    In my understanding, empty '{} is not allowed according to LRM:

pattern ::=
. variable_identifier
| .*
| constant_expression
| tagged member_identifier [ pattern ]
| '{ pattern { , pattern } }
| '{ member_identifier : pattern { , member_identifier : pattern } }
assignment_pattern ::=
'{ expression { , expression } }
| '{ structure_pattern_key : expression { , structure_pattern_key : expression } }
| '{ array_pattern_key : expression { , array_pattern_key : expression } }
| '{ constant_expression { expression { , expression } } }
assignment_pattern_net_lvalue ::=
'{ net_lvalue {, net_lvalue } }
assignment_pattern_variable_lvalue ::=
'{ variable_lvalue {, variable_lvalue } }
  • wiresl2.v
    This is caused by non-ASCII comment ( it is seems to be iso-8859-1? ):
out=01Àëÿ¿a^[[?1;2c$

sv-parser can parse UTF-8 only. I think this is a reasonable restriction because comment should be ASCII in LRM:

comment_text ::= { Any_ASCII_character }

@caryr
Copy link
Author

caryr commented Dec 21, 2020

Thank you for looking into this.

We have recently become aware of '{} being invalid and are trying to understand how to rewrite tests etc. to remove it along with fixes to the Icarus parser. I can add those to the sv-tests exclusion list for now.

Yes, I assumed it was the non-ASCII text. Thanks for verifying. Not sure what to do about that. I think many of our users appreciate this functionality. I will exclude this for now as well.

@caryr
Copy link
Author

caryr commented Dec 21, 2020

FYI '{} is supported by commercial tools (e.g. VCS). I opened an item to discuss how to handle these de facto standard items in sv-tests the other day.

@caryr
Copy link
Author

caryr commented Dec 30, 2020

Adding br_gh435.v as another unexpected fail which we recently added to ivtest. It has an embedded single line comment in a macro. I think there is some ambiguity in the standard around this though it is supported by commercial tools.

Cary

@dalance
Copy link
Owner

dalance commented Jan 6, 2021

I fixed the embedded single line comment issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants