-
Notifications
You must be signed in to change notification settings - Fork 141
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
Introduce IEEE Std 1497-2001 Standard Delay Format (SDF) parsing #1083
base: master
Are you sure you want to change the base?
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #1083 +/- ##
==========================================
- Coverage 94.72% 94.33% -0.39%
==========================================
Files 191 191
Lines 47712 48638 +926
==========================================
+ Hits 45193 45882 +689
- Misses 2519 2756 +237
... and 3 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
|
Standard Delay Format (SDF) parsing
Thanks for the PR. I'm curious about the approach of fully reusing the Lexer, Preprocessor, Parser, and SyntaxTree classes from Verilog to also parse SDF files. It results in a lot of additional branching along the way since syntax differs significantly between the two languages. It also leads to some weird side effects that I don't think you'd want, like for example it seems you could probably use SystemVerilog defines and macro expansion in SDF files? Or at the lexical level, the Lexer will accept a bunch of token kinds that aren't actually allowed in SDF files. I think it would make more sense to create separate copies of these classes, that target just parsing SDF. If there is useful overlap between the two you can factor them into a common base; the ParseBase class kind of does that already for the parser, for example. SDF files are much simpler than SystemVerilog so the resulting classes would be much more compact. |
Good day everyone! In order to be able to support restrictions from 32 LRM section and annotate the
SystemVerilog
code using SDF (the last and only standard isIEEE Std 1497-2001
) constructs I implemented theLL(2)
parser using theslang
infrastructure.I encourage testing on individual
SDF
files for feedback, as the current implementation has been tested on various open-sourceSDF
files.The new
--sdf
option in the slang infrastructure allows for feeding slang one or moreSDF
files and also directory withSDF
files. The implementation supports the fullSDF
grammar (including the syntax of conditional and timing checkSDF
expressions which is significantly differs fromSystemVerilog
expressions), handling all possible syntax errors efficiently. Example of usage:What has not been done at the moment:
SystemVerilog
nodes of theslang
AST - but it questionable)SDF DELAY
s constructs - is it necessary to directly put values from SDF toSystemVerilog specify
AST? or it should be done in simulation (possibly using some pseudoSDF
annotator - which defined at LRM 32.3 section), and nothing should be changed in AST? LRM specifies no possible restrictions withSDF DELAY
sSDF TIMINGCHECK
s constructs -slang
timing check system tasks currently are not annotated - it is future workSDF LABEL
s constructs - same questions asSDF DELAY
section - is it need to propagate it's values directly in AST?$sdf_annotate
processing - is required or not?I suppose
SDF TIMINGENV
constructs should be ignored byslang
as it said at LRM 32.3 section:An opened question pertains to annotating unique delays between source/load pairs using the
INTERCONNECT
construct. How this warning should be processed, either by slang or theSDF
annotator, remains unclear: