Chisel v3.6.0-RC2 has been released!

[Jack Koenig]

Howdy Chiselers,

I am very delighted to announce that we have released v3.6.0-RC2 of the various Chisel-related projects:

Chisel v3.6.0-RC2 - https://github.com/chipsalliance/chisel3/releases/tag/v3.6.0-RC2

ChiselTest v0.6.0-RC2 - https://github.com/ucb-bar/chiseltest/releases/tag/v0.6.0-RC2

Treadle and FIRRTL also have 1.6.0-RC2 releases but with relatively minor changes.

The 3.6 release is a big step for the future of Chisel as it is the transitional release from the original Scala FIRRTL Compiler to the new LLVM MLIR-based FIRRTL Compiler. Please see the Chisel release notes linked above.

Please try out Chisel v3.6.0-RC2 to help us squash any bugs before the final v3.6.0 release!

~Jack on behalf of the Chisel development team

P.S. My usual Scastie template now using 3.6.0-RC2: https://scastie.scala-lang.org/9pywNJBbQ4e1Dp5bo4rpNg

[Øyvind Harboe]

Notes from upgrading.

Got some nice new warnings about bit widths and shifts. 

Some things I had to change to get BoringUtils.bore() to work:

-  val snoopAsUInt = snoop.asUInt
+  val snoopAsUInt = WireInit(snoop.asUInt)

Another example:

-  val foo = VecInit(xxx.map(_.yyy)).count(a => a)
-  val bar = VecInit(xxx.map(_.yyy)).reduce(_ +& _)
+ val foo = WireInit(VecInit(xxx.map(_.yyy)).count(a => a))
+ val bar = WireInit(VecInit(xxx.map(_.yyy)).reduce(_ +& _))

Need to complete this change before I can try out P&R: https://github.com/chipsalliance/chisel/issues/3031#issuecomment-1439326320

[Øyvind Harboe]

One more problem. Why is the below required? What is the difference between WireInit() and Wire() + assign value?

This doesn't work with BoringUtils.bore():

-  val foo = VecInit(xxx.map(_.yyy)).count(a => a)

+ val foo = WireInit(VecInit(xxx.map(_.yyy)).count(a => a))

This does:

-  val foo = VecInit(xxx.map(_.yyy)).count(a => a)

+ val tmp = VecInit(xxx.map(_.yyy)).count(a => a)

+ val foo = Wire(chiselTypeOf(tmp))

+ foo := tmp

[Øyvind Harboe]

Here is another problem with the LLVM CIRCT generated code, Verilator tells me the generated code has inferred latches and I have warnings as errors enabled in Verilator linting and hence the build fails:

https://discourse.llvm.org/t/problems-with-verilator-linting-warning-in-chisel-generated-code/69223

[Schuyler Eldridge]

I would turn off automatic logic emission with the disallowLocalVariables lowering option to get around this. Automatic logic is the only way that I am aware of to get a locally scoped temporary in Verilog. However, tool support is extremely spotty.

On Mar 14, 2023, at 08:26, Øyvind Harboe <oyvind...@gmail.com> wrote:

Here is another problem with the LLVM CIRCT generated code, Verilator tells me the generated code has inferred latches and I have warnings as errors enabled in Verilator linting and hence the build fails:

--
You received this message because you are subscribed to the Google Groups "chisel-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chisel-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/chisel-users/2cd49e88-78b9-4210-a10f-4378e6896492n%40googlegroups.com.

[Øyvind Harboe]

It is supported, but it would seem that Verilator authors are of the opinion that this syntax infers latches.

Thanks!

You received this message because you are subscribed to a topic in the Google Groups "chisel-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/chisel-users/sRhux9vWINA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to chisel-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/chisel-users/A6A93D79-6F27-4854-BB45-FB7F327C98E8%40gmail.com.

--

Øyvind Harboe
+4791786146

[Øyvind Harboe]

Ah, another snag...

A series of unfortunate events: LLVM CIRCT generates .sv code that causes Verilator to generate a .cpp file where g++ crashes.

g++: internal compiler error: Segmentation fault signal terminated program cc1plus

$ g++ --version
g++ (Ubuntu 12.2.0-3ubuntu1) 12.2.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Jack Koenig]

Which version of CIRCT are you using? 3.6.0-RC2 was released with 1.31.0, there are minor issues in 1.32.0 and 1.33.0, but please also try 1.34.0 and 1.35.0.

--
You received this message because you are subscribed to the Google Groups "chisel-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chisel-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/chisel-users/9a874d9e-5e78-4fd5-be13-f1f5014a972en%40googlegroups.com.

[Jack Koenig]

It's also worth trying other versions of Verilator. Certainly a segfault in g++ is a bug in g++, but hopefully a different version of Verilator can avoid it. It might also be worth following up with the Verilator devs if it's possible to create a test case.

[Øyvind Harboe]

1.35.0

You received this message because you are subscribed to a topic in the Google Groups "chisel-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/chisel-users/sRhux9vWINA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to chisel-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/chisel-users/CAFooY_SUOMEi_92OGX1eFc%3DBJwb%2BYqVcJVtc2YpQPTDsiSr2YA%40mail.gmail.com.

[Øyvind Harboe]

Yes: a g++ segfault is a g++ bug.

However, verilator can generate C++ code that is atypical and pushes any compiler off the cliff. clang doesn't even finish in hours on this file, so who knows if it will crash in the end? 

I suspect the problem is that verilator is generating C++ code that, in my case, has ca. 40000 local C++ objects. I've in a previous life seen that g++ will run pathologically slow if you have tens of thousands of local C++ objects. It is something about exception handling or C++ destructors that make g++ take forever to run on these sort of .cpp files.

So the question becomes: what sort of Chisel code generates Verilog code where verilator has thousands of local C++ objects so that g++ crashes :-)

This is a Lemony Snicket bug: a series of unfortunate events...