Floating point formatting test failures on aarch64

[jleightcap]

On both the 11.0 and 12.0 release, two tests fail on aarch64 due to floating point formatting:

                    br1029a: ==> Failed - output does not match gold file.
                    br1029b: ==> Failed - output does not match gold file.

• https://github.com/steveicarus/ivtest/blob/master/ivltests/br1029a.v
• https://github.com/steveicarus/ivtest/blob/master/ivltests/br1029b.v

Using the current 11.0 macos release installed through brew,

$ iverilog -v
Icarus Verilog version 11.0 (stable) ()
# ...
$ which iverilog
/opt/homebrew/bin/iverilog
$ iverilog source/ivtest/ivltests/br1029a.v
$ ./a.out
a: 0.4  0  0  0
b: 0.5  1  1  1
c: 0.6  1  1  1
d: 2.4  2  2  10
e: 2.5  3  3  11
f: 2.6  3  3  11
a: -0.4  -0  0  0
b: -0.5  -1  0  0
c: -0.6  -1  0  0
d: -2.4  -2  0  0
e: -2.5  -3  0  0
f: -2.6  -3  0  0

And using a fresh build of the 12.0 release through nix,

$ ./result/bin/iverilog source/ivtest/ivltests/br1029a.v
$ ./a.out
a: 0.4  0  0  0
b: 0.5  1  1  1
c: 0.6  1  1  1
d: 2.4  2  2  10
e: 2.5  3  3  11
f: 2.6  3  3  11
a: -0.4  -0  0  0
b: -0.5  -1  0  0
c: -0.6  -1  0  0
d: -2.4  -2  0  0
e: -2.5  -3  0  0
f: -2.6  -3  0  0

In both cases the formatting of %0x and %0b differs from the spec file.

See our nixpkgs discussion.

Thanks, let me know if I'm missing something and I'm happy to provide more details as needed 🙂

[martinwhitaker]

This looks to be a architecture-dependent bug in the vpi_get_value() implementation when called with a vpiBinStrVal or vpiHexStrVal format. But I don't have an aarch64 machine, so can't investigate further.

[larsclausen]

The code looks like this snprintf(rbuf, RBUF_SIZE, "%" PRIx64, (uint64_t)vlg_round(rval));

vlg_round() returns a double. I suppose what happens is that on those failing platforms if you cast a negative float to an unsigned integer it will be rounded to 0.

@jleightcap Can you give the following a try?

diff --git a/vvp/vpi_callback.cc b/vvp/vpi_callback.cc
index 80a640186..978f2f62d 100644
--- a/vvp/vpi_callback.cc
+++ b/vvp/vpi_callback.cc
@@ -890,12 +890,12 @@ static void real_signal_value(struct t_vpi_value*vp, double rval)
 	    break;
 
 	  case vpiHexStrVal:
-	    snprintf(rbuf, RBUF_SIZE, "%" PRIx64, (uint64_t)vlg_round(rval));
+	    snprintf(rbuf, RBUF_SIZE, "%" PRIx64, (uint64_t)(int64_t)vlg_round(rval));
 	    vp->value.str = rbuf;
 	    break;
 
 	  case vpiBinStrVal: {
-		uint64_t val = (uint64_t)vlg_round(rval);
+		uint64_t val = (uint64_t)(int64_t)vlg_round(rval);
 		unsigned len = 0;
 
 		while (val > 0) {
@@ -903,7 +903,7 @@ static void real_signal_value(struct t_vpi_value*vp, double rval)
 		      val /= 2;
 		}
 
-		val = (uint64_t)vlg_round(rval);
+		val = (uint64_t)(int64_t)vlg_round(rval);
 		for (unsigned idx = 0 ;  idx < len ;  idx += 1) {
 		      rbuf[len-idx-1] = (val & 1)? '1' : '0';
 		      val /= 2;

[larsclausen]

Quick search brings up this

Never cast a negative float to an unsigned int. The result of the cast differs depending on whether the cast is executed on a device with Intel or ARM architecture. The C++ Standard decrees that the result of such a cast is undefined.