Using Chisel types in peek

[ucb-bar]

Using Chisel types in peek

[ducky64]

Yes, this is currently the case, literals are Chisel objects (hardware nodes) so you need to extract the Scala-land value before doing a compare.

In theory we can do more constant propagation in Chisel (eg, 1.U + 2.U could evaluate to 3.U instead of just generating the add node) and might clean up the literals syntax used in testers2, but it would also have significant limitations and result in duplication of code with FIRRTL. Duplication is highly undesirable, as there have been subtle differences in behavior which are hard to fix because the fix changes behavior, even if it's bad and unituitive.

Using Chisel literals as the testers2 API allows us to re-use the same literal constructors (like the string-based binary/hex constructor and the literals constructor; in the future also Vec constructors), though it does make the syntax for getting values back into Scala more verbose.

Suggestions about how we can make working with literal values easier are appreciated, though within the constraints above.

[schoeberl]

I can accept this, but it is a little bit counterintuitive that peek returns a Chisel type that is not directly usable. E.g., compare the Chisel peek returned UInt against a Chisel UInt constant does not work. Why returning this type that I need to convert to Scala world with litValue()? What is the value of returning UInt then? Maybe the former peek return of (BigInt ?) is more practical. Cheers, Martin

…

On 4 Sep, 2019, at 20:15, Richard Lin ***@***.***> wrote: Yes, this is currently the case, literals are Chisel objects (hardware nodes) so you need to extract the Scala-land value before doing a compare. In theory we can do more constant propagation in Chisel (eg, 1.U + 2.U could evaluate to 3.U instead of just generating the add node) and might clean up the literals syntax used in testers2, but it would also have significant limitations and result in duplication of code with FIRRTL. Duplication is highly undesirable, as there have been subtle differences in behavior which are hard to fix because the fix changes behavior, even if it's bad and unituitive. Using Chisel literals as the testers2 API allows us to re-use the same literal constructors (like the string-based binary/hex constructor and the literals constructor; in the future also Vec constructors), though it does make the syntax for getting values back into Scala more verbose. Suggestions about how we can make working with literal values easier are appreciated, though within the constraints above. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#61>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAE63GDA2USZYH4P77B3AMDQH73LFANCNFSM4ITPWQOQ>.

[ducky64]

So the main practical problem with the former is that it doesn't handle Bundle types or Vector types - what should be returned in those cases? While Vector might return an Array or Seq, for Bundles we generally have tried to avoid indexing with untyped strings, which would be difficult without returning the Chisel type.

I am definitely interested into finding ways to make the returned object more usable, so clever solutions are welcome...

[ducky64]

Resolution from today's meeting:
We considered doing literal evaluation with chisel types, eg

3.U === 3.U => (some FIRRTL node essentially equal to true.B)
3.U == 3.U => true
3.U == 4.U => false
io.peek() == 3.U => true  // for io.peek() returning 3.U
io.peek() == 3 => assert out  // don't allow implicit promotion of Scala numbers to Chisel lits
3.U + 3.U == 6.U => assert out  // don't allow evaluation on non-literal types, you probably meant to do ===

but decided against it.
(separately, we might make == on Chisel nodes assert out, since it almost always doesn't do what you think it should do - and you should use the referential equality eq for advanced metaprogramming)

In a separate discussion, there was talk about implicitly promoting Scala numbers to literals, which while not completely offensive for Int -> UInt, causes problems (with the above antifeature) for Boolean -> Bool. So that's a no-go.

We thought it would be reasonable to have a simpler literal extract operator, eg io.peek().asInt, instead of the somewhat cumbersome and maybe not at all intuitive .litToValue()

[schoeberl]

Another (similar) consequence: you cannot really compute anything with Chisel types, I get a " Not in a UserModule." error when I do following:

val data = (i << 16).U + dut.io.cycCnt.peek

I need to first convert to Scala land and then back into Chisel land:

val data = ((i << 16) + dut.io.cycCnt.peek.litValue().toInt).U

This is quite a long expression just to add a value. Maybe using BigInt for UInt and SInt would make live easier?

+1 for the above io.peek.asInt and io.peek.asBigInt

Cheers,
Martin, the tester2 tester ;-)

[oharboe]

My main concern about this is that it is brittle.

There's no compilation error, or runtime error, there's just a failure in operation.

This can be quite tricky to track down and it makes the process of porting to tester2 brittle.

Example:

while (dut.io.someBool.peek() == false)

Compiles but doesn't work.

Instead I had to do:

while (dut.io.someBool.peek().litValue == 0)

To me the best fix is not something convenient, but something that gives a compilation error message if it is not done correctly. I'll settle for a run-time error, but compilation error would be fantastic.

[carlosedp]

I think this has been addressed in #480.