EE290 Lab 2: Building and Simulating Gemmini

[MrJbriggs]

To build a simulation for my verilog mesh I tried this command from the lab:

$ cd sims/verilator $ make CONFIG=GemminiEE290Lab2RocketConfig

It was an epic bomb :) A lot of messages about deprecations and then the thing just tanked. See messages below and the last line where the make gets killed. @hngenc What to do?

**_[warn] class PreElaboration extends Phase with PreservesAll[Phase] with HasRocketChipStageUtils { [warn] ^ [warn] /home/mainasara/chipyard/generators/rocket-chip/src/main/scala/stage/phases/TransformAnnotations.scala:13:47: trait PreservesAll in package options is deprecated (since FIRRTL 1.4): Use an explicit override def invalidates returning false. This will be removed in FIRRTL 1.5. [warn] class TransformAnnotations extends Phase with PreservesAll[Phase] with HasRocketChipStageUtils { [warn] ^ [warn] /home/mainasara/chipyard/generators/rocket-chip/src/main/scala/system/RocketChipStageGenerator.scala:28:42: trait PreservesAll in package options is deprecated (since FIRRTL 1.4): Use an explicit override def invalidates returning false. This will be removed in FIRRTL 1.5. [warn] class RocketChipStage extends Stage with PreservesAll[Phase] { [warn] ^ [warn] /home/mainasara/chipyard/generators/rocket-chip/src/main/scala/tilelink/Monitor.scala:856:11: method legalizeADSourceOld in class TLMonitor is deprecated: Use legalizeADSource instead if possible [warn] legalizeADSourceOld(bundle, edge) [warn] ^ [warn] /home/mainasara/chipyard/generators/rocket-chip/src/main/scala/util/GeneratorUtils.scala:16:36: method newInstance in class Class is deprecated: see corresponding Javadoc for more information. [warn] Class.forName(currentName).newInstance.asInstanceOf[Config] [warn] ^ [warn] there were 2555 feature warnings; re-run with -feature for details [warn] 21 warnings found [info] compiling 53 Scala sources to /home/mainasara/chipyard/generators/hwacha/target/scala-2.12/classes ... [info] compiling 43 Scala sources to /home/mainasara/chipyard/generators/riscv-sodor/target/scala-2.12/classes .. [info] compiling 4 Scala sources to /home/mainasara/chipyard/generators/nvdla/target/scala-2.12/classes ... [warn] there were 62 feature warnings; re-run with -feature for details [warn] one warning found [info] compiling 23 Scala sources to /home/mainasara/chipyard/generators/sifive-cache/target/scala-2.12/classes ... make: * [/home/mainasara/chipyard/common.mk:106: generatortemp] Killed

[hngenc]

Can you try building GemminiRocketConfig? That should be equivalent to the EE290 Lab 2 config (which we never published except to our students)

[hngenc]

Closing this issue for now, but let me know if you can't build the config I suggested

[MrJbriggs]

Thanks for your reply @hngenc

I did the make like this: make CONFIG=GemminiRocketConfig

It bombed in a similar fashion. A bunch of messages about deprecated things. And an interesting final message about heap size before it tanked. I am running on a VM with 4GB of RAM.

**warn] /home/mainasara/chipyard/tools/rocket-dsp-utils/src/main/scala/freechips/rocketchip/jtag2mm/JtagToMaster.scala:133:38: method apply in object TLClientParameters is deprecated: Use TLMasterParameters.v1 instead of TLClientParameters [warn] Seq(TLClientPortParameters(Seq(TLClientParameters(name = "JTAGToMasterOut", sourceId = IdRange(0, 4))))) [warn] ^ [warn] /home/mainasara/chipyard/tools/rocket-dsp-utils/src/main/scala/freechips/rocketchip/jtag2mm/JtagToMaster.scala:468:23: method apply in object TLManagerParameters is deprecated: Use TLSlaveParameters.v1 instead of TLManagerParameters [warn] val managerParams = TLManagerParameters( [warn] ^ [warn] /home/mainasara/chipyard/tools/rocket-dsp-utils/src/main/scala/freechips/rocketchip/jtag2mm/TestMultiplexer.scala:62:24: method apply in object TLClientParameters is deprecated: Use TLMasterParameters.v1 instead of TLClientParameters [warn] val clientParams = TLClientParameters( [warn] ^ [warn] /home/mainasara/chipyard/tools/rocket-dsp-utils/src/main/scala/freechips/rocketchip/jtag2mm/TestMultiplexer.scala:80:31: method apply in object TLClientPortParameters is deprecated: Use TLMasterPortParameters.v1 instead of TLClientPortParameters [warn] m := BundleBridgeToTL(TLClientPortParameters(Seq(clientParams))) := ioMemNode [warn] ^ [warn] /home/mainasara/chipyard/tools/rocket-dsp-utils/src/main/scala/freechips/rocketchip/tilelink/Node.scala:20:30: method apply in object TLManagerPortParameters is deprecated: Use TLSlavePortParameters.v1 instead of TLManagerPortParameters [warn] new TLToBundleBridgeNode(TLManagerPortParameters(Seq(managerParams), beatBytes)) [warn] ^ [warn] /home/mainasara/chipyard/tools/rocket-dsp-utils/src/main/scala/freechips/rocketchip/tilelink/Node.scala:38:11: method apply in object TLManagerPortParameters is deprecated: Use TLSlavePortParameters.v1 instead of TLManagerPortParameters [warn] apply(TLManagerPortParameters(Seq(managerParams), beatBytes)) [warn] ^ [warn] /home/mainasara/chipyard/tools/rocket-dsp-utils/src/main/scala/freechips/rocketchip/tilelink/Node.scala:52:26: method apply in object TLClientPortParameters is deprecated: Use TLMasterPortParameters.v1 instead of TLClientPortParameters [warn] BundleBridgeToTLNode(TLClientPortParameters(Seq(clientParams), beatBytes)) [warn] ^ [warn] /home/mainasara/chipyard/tools/rocket-dsp-utils/src/main/scala/freechips/rocketchip/tilelink/Node.scala:71:11: method apply in object TLClientPortParameters is deprecated: Use TLMasterPortParameters.v1 instead of TLClientPortParameters [warn] apply(TLClientPortParameters(Seq(clientParams), beatBytes)) [warn] ^ [warn] In the last 93 seconds, 6.7 (7.2%) were spent in GC. [Heap: 2.36GB free of 3.46GB, max 8.00GB] Consider increasing the JVM heap using -Xmx or try a different collector, e.g. -XX:+UseG1GC, for better performance. make: * [/home/mainasara/chipyard/common.mk:106: generator_temp] Killed

[hngenc]

Can you try saving the full output in a Gist? There's probably an error message in there somewhere, but it seems to have showed up before the part that you posted.

As for the memory, I think Chipyard tries to take up to 8GB of RAM. So that may be a problem.

[MrJbriggs]

Ok, I'll rerun. I'll share that tomorrow at the latest. Thank you

[MrJbriggs]

@hngenc I have the gist here:

https://gist.github.com/MrJbriggs/2847f0a519163d2f6d0d7c6bfe1651f9

Thank you

[hngenc]

OK, I think the clue to what went wrong is actually in the very last line:

make: *** [/home/mainasara/chipyard/common.mk:106: generator_temp] Killed

I've only seen the Killed message when I ran out of memory. Can you try running on a computer with more RAM?

[MrJbriggs]

Yes, I'll get more RAM in my laptop today and then rerun. Thanks

[MrJbriggs]

@hngenc Finally updated my RAM and reran. The output is cleaner than before but still tripping. Lastest gist can be found here:

https://gist.github.com/MrJbriggs/e28675f391b0a1dc6d6dc78b8c91bb2a

Thank you

[hngenc]

How much RAM do you have now? It looks to me like it still might not be enough.

It failed on this step:

barstools.tapeout.transforms.GenerateTopAndHarness```

Which is a "FIRRTL transform". FIRRTL transforms tend to be very memory-hungry, unfortunately.

[MrJbriggs]

My virtual machine has 8GB available now. Still more? Perhaps I should move this to the cloud?

[hngenc]

Chipyard/Gemmini shouldn't take more than 8 GB, but I think it's possible that some of your RAM is being taken up by your OS or other programs.

I typically run this on a Xeon server which is owned/maintained by the lab where I work.

[MrJbriggs]

The virtual box has Ubuntu and I am running nothing else while doing the build. I just checked the Memory usage dashboard inside the virtual box and there is 6.84GB free. I will rerun again and watch the dashboard to see if it hits the ceiling

[MrJbriggs]

[MrJbriggs]

The build is eating up all 6.84GB of RAM! I'll give it more and try again

[MrJbriggs]

I hope Lab2 works after all this fuss :) :)

[MrJbriggs]

It got over that hump after allocating more RAM! Yay :) It came quite close to using all 8GB of free RAM. I'll post my output log as a gist when it is finishes

[MrJbriggs]

@hngenc Now it seems to be stuck in some kind of loop, and printing out the same message (at least it seems that way)

The latest gist is here: https://gist.github.com/MrJbriggs/2b8c4c97c2d25ceb684433722bee3b83

Thank you

[hngenc]

That seems to be working fine.

Verilator can take a while to compile, so you might have to wait quite a bit for it to finish. But it'll finish eventually.

[MrJbriggs]

Indeed, it has now finished. Thanks for your great support on this issue @hngenc

[hngenc]

No problem!