为什么凿UInt（32.W）不能采取一个无符号的数字位[32]碰巧是1？

它被定义为UInt是无符号整数的类型。但在这种情况下，MSB似乎仍然是一个标志。例如，最相关的质量保证是Chisel UInt negative value error，其中找出了解决方法，但没有解决问题。你能否让我了解'为什么'？为什么凿UInt（32.W）不能采取一个无符号的数字位[32]碰巧是1？

的UInt似乎chisel3/chiselFrontend/src目录/主/斯卡拉/ chisel3 /核心/ Bits.scala，但我不明白的细节进行定义。 UInt是从Bits衍生而来，Bits是从scala的Int派生而来的？

来源

2017-06-29 Lin Frank

简单的答案是，这是由于Scala如何评估事物。考虑像

val x = 0xFFFFFFFF.U

此语句会导致错误的例子。 UInt文字由BigInts内部表示，但0xFFFFFFFF是一个指定的Int值。 0xFFFFFFFF等价于Int值-1。 -1 Int值被转换为BigInt -1并且-1.U是非法的，因为.U文字创建方法不会接受负值。添加L修复此问题，因为0xFFFFFFFL是一个正值Long值。

来源

2017-06-29 18:01:21

问题是Scala 只有已经有符号整数，它没有无符号整数类型。来自REPL

scala> 0x9456789a 
res1: Int = -1806272358

因此，凿子只能看到负数。 UIs显然不能是负面的，所以凿子报告错误。

如果您想将解码为UInt的负数的原始2的补码表示解释为UInt，则您总是可以从SInt投射到UInt。例如。

val a = -1.S(32.W).asUInt 
assert(a === "xffffffff".U)

来源

2017-06-29 18:03:44 jkoenig

为什么凿UInt（32.W）不能采取一个无符号的数字位[32]碰巧是1？

回答

相关问题