-
Notifications
You must be signed in to change notification settings - Fork 642
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
[BUG] Spike version checks in regression scripts are unreliable #2110
Labels
Type:Bug
For bugs in the RTL, Documentation, Verification environment or Tool and Build system
Comments
zchamski
added
the
Type:Bug
For bugs in the RTL, Documentation, Verification environment or Tool and Build system
label
May 14, 2024
The solution will require a coordinated modification of both repos: |
zchamski
added a commit
to ThalesSiliconSecurity/cva6
that referenced
this issue
May 21, 2024
… version checks.
Fixed in commit e6c3bac by aligning the behavior of Git hash extraction in Spike build inside |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Type:Bug
For bugs in the RTL, Documentation, Verification environment or Tool and Build system
Is there an existing CVA6 bug for this?
Bug Description
Verification script
verif/sim/cva6.py
performs version consistency checks on several tools including Spike. For Spike it compares the built-in version string based on the short Git hash (SHA1 checksum) against the short hash of the Spike source. There are three cases of false negatives in the current implementation of these checks:fprintf
-ing an unsigned integer (32 bits, 8 hex digits) thus causing the most significant digit to be truncated.fprintf
" approach is not robust against leading zeroes in hash value...
) ingit log
invocations used to obtain the hash of the enclosing directory triggers a buggy behavior in Git: even when the..
is separated from commit-related information using a double dash (--
), it gets interpreted as a commit-relative expression, yielding highly unexpected results.Examples using 807ed7825 and openhwgroup/core-v-verif@8e8a63730, openhwgroup/core-v-verif@c98a21182:
8
in the actual version string, even though the CFLAGS contain the correct value-DSPIKE_HASH_VERSION=0x8e8a63730
:core-v-verif
commit being used is a merge point (e.g., core-v-verif@c98a21182):The text was updated successfully, but these errors were encountered: