Skip to content
New issue

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

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

Already on GitHub? # to your account

Verilog feature #35

Open
erihsu opened this issue May 2, 2021 · 3 comments
Open

Verilog feature #35

erihsu opened this issue May 2, 2021 · 3 comments

Comments

@erihsu
Copy link
Contributor

erihsu commented May 2, 2021

sv-parser aims to be fully compliant with IEEE1800-2017 standard. But if someone wants to use this parser to parse Verilog 2001 file, which is subset of SystemVerilog, there is no need to collect all SystemVerilog nodes in this parser. Is this reasonable to add features into this parser to exactly down-compatible with older IEEE standard ?

ie

sv-parser = { version = "x.x.x", features = ["verilog-2001"] }
@DaveMcEwan
Copy link

This isn't an "easy" feature. Despite the language being backwards compatible, the formal specifications in Annex A are not fully compatible.
To see what I mean, have a look at the BNFs of 1800-2005 and 1800-2017 here: https://github.com/DaveMcEwan/dmpvl/tree/master/misc/bnf
If you diff those files, you can see subtle things like the syntax of localparam.
The structure of sv-parser follows the BNF very closely, so with different and slightly incompatible BNFs it's not clear how to keep sv-parser so nicely structured and usable.

The nicest approach I can think of would be to have multiple versions of sv-parser (e.g. sv-parser-1800-2017, sv-parser-1364-2001) which adhere to their different BNFs. Naturally, any application above (which processes an AST) must have support added for each type of AST.

It's quite a lot of work just to support older versions of the standard and I think that support for specific versions isn't really necessary for most users. However, I think it would be quite fun so if you want to start a branch for this, then I will happily contribute :)

@evbo
Copy link

evbo commented Sep 17, 2024

So if I wanted to parse just plain verilog and not systemverilog, would I not use this repo?

Is verilog so simple that maybe writing a custom parser for it is no big deal?

@erihsu
Copy link
Contributor Author

erihsu commented Sep 18, 2024

nodes

Yes, simple verilog is easy to handle, but if you want to fully support parse verilog 2001, it's big deal anyhow

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

No branches or pull requests

3 participants