chipyard icon indicating copy to clipboard operation
chipyard copied to clipboard

SBT thin client disconnects from server on macOS

Open tymcauley opened this issue 3 years ago • 0 comments

Background Work

Chipyard Version and Hash

Branch: main Hash: 684a02a10f093860511c23bc8da52c198cd5e879

OS Setup

macOS 12.5

Other Setup

Java version:

$ java -version
openjdk version "17.0.2" 2022-01-18
OpenJDK Runtime Environment (build 17.0.2+8-86)
OpenJDK 64-Bit Server VM (build 17.0.2+8-86, mixed mode, sharing)

Chipyard setup:

git clone https://github.com/ucb-bar/chipyard.git
cd chipyard
./scripts/init-submodules-no-riscv-tools.sh

Current Behavior

When running the build with the SBT thin client, the client disconnects from the server. This is seemingly correlated with periods of high terminal output.

It's possible this is related to https://github.com/sbt/sbt/issues/6527, but the suggestions from that thread have not resolved this issue for me.

Test on macOS

Here is what the build output looks like on a fresh clone of the chipyard repo:

make -C sims/vcs ENABLE_SBT_THIN_CLIENT=1 SBT_BIN=sbt firrtl
...
[info] entering *experimental* thin client - BEEP WHIRR
[info] server was not detected. starting an instance
...
[info] welcome to sbt 1.5.5 (Oracle Corporation Java 17.0.2)
...
[warn] /path/to/chipyard/generators/rocket-chip/src/main/scala/tilelink/Fuzzer.scala:219:17: method fire in class AddMethodsToReadyValid is deprecated (since Chisel 3.5): Calling this function with an empty argument list is invalid in Scala 3. Use the form without parentheses instead
[warn]       when (out.d.fire() && d_last) {
[warn]                 ^

sbt server connection closed. compileIncremental 59s
make: *** [generator_temp] Error 1

That Chisel warning in particular isn't the cause of the problem, there just happen to be a large number of warnings being emitted at the same time, which causes a lot of terminal output.

If you've already gotten through the firrtl build stage (by running that build stage without the thin client), then another reliable way of reproducing this issue for me is to set the FIRRTL_LOGLEVEL variable to debug or trace during the make verilog stage.

make -C sims/vcs ENABLE_SBT_THIN_CLIENT=1 SBT_BIN=sbt FIRRTL_LOGLEVEL=debug verilog
...
[info] running (fork) barstools.tapeout.transforms.GenerateTopAndHarness ...
...
[info] ======== Starting firrtl.passes.CheckTypes$ ========
[info] --------------------------------------------------------------
[info] Time: 140.1 ms
[info] ======== Finished firrtl.passes.CheckTypes$ ========
[info] ======== Starting firrtl.transforms.DedupModules ========

sbt server connection closed.
make: *** [firrtl_temp] Error 1

Test on Linux

I ran this same test on a Linux machine (over ssh), and there were no errors. Here's the setup for that machine:

$ uname -a
Linux my-hostname 5.4.0-122-generic #138-Ubuntu SMP Wed Jun 22 15:00:31 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.4 LTS
Release:        20.04
Codename:       focal
$ java -version
openjdk version "17.0.2" 2022-01-18
OpenJDK Runtime Environment (build 17.0.2+8-86)
OpenJDK 64-Bit Server VM (build 17.0.2+8-86, mixed mode, sharing)

Expected Behavior

The build should work with the SBT thin client, no matter how much output is going to the terminal.

Other Information

No response

tymcauley avatar Aug 03 '22 19:08 tymcauley