2

It is defined that UInt is the type of unsigned integer. But in such case it seems like the MSB is still a sign. e.g., the most relative QA is Chisel UInt negative value error which works out a workaround but no why. Could you enlight me about the 'why'?

The UInt seems to be defined in chisel3/chiselFrontend/src/main/scala/chisel3/core/Bits.scala but I cannot understand the details. Is the UInt is derived from Bits and Bits is derived from Int of scala?

Abdul
  • 2,002
  • 7
  • 31
  • 65
Lin Frank
  • 113
  • 11

2 Answers2

4

The simple answer is that this is due to how Scala evaluates things. Consider an example like

val x = 0xFFFFFFFF.U

This statement causes an error. UInt literal are represented internally by BigInts, but the 0xFFFFFFFF is an specifying an Int value. 0xFFFFFFFF is equivalent to the Int value -1. The -1 Int value is converted to BigInt -1 and -1.U is illegal because the .U literal creation method will not accept negative values. Adding the L fixes this because 0xFFFFFFFL is a positive Long value.

Chick Markley
  • 4,023
  • 16
  • 17
2

The issue is that Scala only has signed integers, it does not have an unsigned integer type. From the REPL

scala> 0x9456789a
res1: Int = -1806272358

Thus, Chisel only sees the negative number. UInts obviously cannot be negative so Chisel reports an error.

You can always cast from an SInt to a UInt if you want the raw 2's complement representation of a negative number interpreted as a UInt. eg.

val a = -1.S(32.W).asUInt
assert(a === "xffffffff".U)
Jack Koenig
  • 5,840
  • 15
  • 21
  • The real issue is that **Java** only has signed integers. And because Scala is built on top of Java, it has to keep these fundamental settings. – iBug Jul 29 '20 at 08:54