pourquoi le ciseau UInt (32.W) ne peut pas prendre un nombre non signé dont le bit [32] arrive à être 1?

Question

Il est défini que UInt est le type d'entier non signé. Mais dans ce cas, il semble que le MSB est toujours un signe. par exemple, le QA le plus relatif est Chisel UInt negative value error, ce qui donne une solution de contournement mais pas pourquoi. Pourrais-tu m'éclairer sur le 'pourquoi'?

Le UInt semble être défini dans chisel3/chiselFrontend/src/main/scala/chisel3/core/Bits.scala mais je ne peux pas comprendre les détails. Est le UInt est dérivé de Bits et Bits est dérivé de Int de scala?

Answer 1

La réponse simple est que cela est dû à la façon dont Scala évalue les choses. Prenons un exemple comme

val x = 0xFFFFFFFF.U 

Cette déclaration provoque une erreur. UInt littéral sont représentés en interne par BigInts, mais le 0xFFFFFFFF est une valeur Int spécifiant. 0xFFFFFFFF est équivalent à la valeur Int -1. La valeur -1 Int est convertie en BigInt -1 et -1.U est illégale car la méthode de création littérale .U n'accepte pas les valeurs négatives. Ajout du L corrige cela parce que 0xFFFFFFFL est une valeur longue positive.

Answer 2

Le problème est que Scala seulement a des entiers signés, il n'a pas un type entier non signé. De la REPL

scala> 0x9456789a 
res1: Int = -1806272358 

Ainsi, Chisel ne voit que le nombre négatif. UInts ne peut évidemment pas être négatif, donc Chisel signale une erreur.

Vous pouvez toujours transtyper d'un SInt à un UInt si vous voulez que la représentation du complément 2 brut d'un nombre négatif soit interprétée comme un UInt. par exemple.

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