Hi,
I recently ran the SpyGlass linter on the ref.sv designs within the Verilog Gen/ dataset. During the analysis, I noticed several RTL coding issues that could potentially lead to simulation-synthesis mismatches, timing problems, or unexpected hardware behavior.
Here is a summary of the findings:
- cpu_ip
- 007
- Mixed <= and = assignment in a same always block (line 35-53)
- dividend is assigned in consecutive lines (50-51)
- 008
- use non-blocking assignment (<=) in always @(*) block
- new_pc will infer a latch in synthesis stage
- 009
- use non-blocking assignment (<=) in always @(*) block
- data_o will infer a latch in synthesis stage
- self_contain
- 015
- Combloop occured when nstate = nstate (line 26-45)
- states S2_5 and S3 are missing in line 26-45 cases.
- 023
- Mixed <= and = assignment in a same always block (line 12-22)
Please note that this might not be an exhaustive list. Maybe there are more error not found yet.
I was wondering if these reference designs (ref.sv) have been verified through RTL simulation with basic testbenches (solely checking the standalone correctness of ref.sv, rather than comparing it against TopModule), or run through a standard linting and synthesis flow?
Thank you!
Hi,
I recently ran the SpyGlass linter on the ref.sv designs within the Verilog Gen/ dataset. During the analysis, I noticed several RTL coding issues that could potentially lead to simulation-synthesis mismatches, timing problems, or unexpected hardware behavior.
Here is a summary of the findings:
Please note that this might not be an exhaustive list. Maybe there are more error not found yet.
I was wondering if these reference designs (ref.sv) have been verified through RTL simulation with basic testbenches (solely checking the standalone correctness of ref.sv, rather than comparing it against TopModule), or run through a standard linting and synthesis flow?
Thank you!