wu-arch/chipyard
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'origin/dev' into hammer-sim-integration

Browse Source
This commit is contained in:
Colin Schmidt
2020-05-23 21:35:37 -07:00
parent 106165e278 c2c9bc83de
commit 400b4e0c58
176 changed files with 11803 additions and 2803 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
.circleci/README.md
View File

@@ -16,9 +16,8 @@ For example:
- prepare-rocketchip:
requires:
- install-riscv-toolchain
- install-verilator
This specifies that the `prepare-rocketchip` job needs the `install-riscv-toolchain` and `install-verilator` steps to run before it can run.
This specifies that the `prepare-rocketchip` job needs the `install-riscv-toolchain` steps to run before it can run.
All jobs in the CI workflow are specified at the top of `config.yml`
They specify a docker image to use (in this case a riscv-boom image since that is already available and works nicely) and an environment.
@@ -36,7 +35,6 @@ This directory contains all the collateral for the Chipyard CI to work.
The following is included:
`build-toolchains.sh` # build either riscv-tools or esp-tools
`build-verilator.sh` # build verilator (remotely)
`create-hash.sh` # create hashes of riscv-tools/esp-tools so circleci caching can work
`do-rtl-build.sh` # use verilator to build a sim executable (remotely)
`config.yml` # main circleci config script to enumerate jobs/workflows
@@ -48,11 +46,10 @@ How things are setup for Chipyard
The steps for CI to run are as follows.
1st, build the toolchains in parallel (note: `esp-tools` is currently not used in the run).
The docker image sets up the `PATH` and `RISCV` variable so that `riscv-tools` is the default (currently the `env.sh` script that is created at tool build is unused).
2nd, install verilator using the `*.mk` to cache unique versions of verilator (mainly for if verilator is bumped).
3rd, create the simulator binary.
2nd, create the simulator binary.
This requires the `riscv-tools` for `fesvr` and `verilator` to be able to build the binary.
This stores all collateral for the tests (srcs, generated-srcs, sim binary, etc) to run "out of the gate" in the next job (make needs everything or else it will run again).
4th, finally run the tests that were wanted.
3rd, finally run the desired tests.
Other CI Setup
--------------

35
.circleci/build-verilator.sh
View File

@@ -1,35 +0,0 @@
#!/bin/bash
# build verilator
# turn echo on and error on earliest command
set -ex
# get shared variables
SCRIPT_DIR="$( cd "$( dirname "$0" )" && pwd )"
source $SCRIPT_DIR/defaults.sh
# call clean on exit
trap clean EXIT
run_script $LOCAL_CHIPYARD_DIR/.circleci/clean-old-files.sh $CI_DIR
if [ ! -d "$LOCAL_VERILATOR_DIR" ]; then
# set stricthostkeychecking to no (must happen before rsync)
run "echo \"Ping $SERVER\""
clean
run "mkdir -p $REMOTE_CHIPYARD_DIR"
copy $LOCAL_CHIPYARD_DIR/ $SERVER:$REMOTE_CHIPYARD_DIR
run "make -j$NPROC -C $REMOTE_SIM_DIR VERILATOR_INSTALL_DIR=$REMOTE_VERILATOR_DIR verilator_install"
# copy so that circleci can cache
mkdir -p $LOCAL_CHIPYARD_DIR
mkdir -p $LOCAL_VERILATOR_DIR
copy $SERVER:$REMOTE_CHIPYARD_DIR/ $LOCAL_CHIPYARD_DIR
copy $SERVER:$REMOTE_VERILATOR_DIR/ $LOCAL_VERILATOR_DIR
cp -r $LOCAL_VERILATOR_DIR/install/bin/* $LOCAL_VERILATOR_DIR/install/share/verilator/bin/.
fi

300
.circleci/config.yml
View File

@@ -4,18 +4,15 @@
version: 2.1
parameters:
verilator-cache-version:
type: string
default: "v3"
tools-cache-version:
type: string
default: "v4"
default: "v5"
# default execution env.s
executors:
main-env:
docker:
- image: riscvboom/riscvboom-images:0.0.12
- image: ucbbar/chipyard-image:1.0.1
environment:
JVM_OPTS: -Xmx3200m # Customize the JVM maximum heap limit
@@ -54,8 +51,8 @@ commands:
- "3e:c3:02:5b:ed:64:8c:b7:b0:04:43:bc:83:43:73:1e"
- checkout
setup-tools-verilator:
description: "Get toolchain and verilator"
setup-tools:
description: "Get toolchain"
parameters:
tools-version:
type: string
@@ -69,9 +66,6 @@ commands:
- restore_cache:
keys:
- << parameters.tools-version >>-installed-<< pipeline.parameters.tools-cache-version >>-{{ checksum "../<< parameters.tools-version >>.hash" }}
- restore_cache:
keys:
- verilator-installed-<< pipeline.parameters.verilator-cache-version >>-{{ checksum "sims/verilator/verilator.mk" }}
prepare-rtl:
description: "Run the prepare step of RTL"
@@ -88,7 +82,7 @@ commands:
type: string
default: "do-rtl-build.sh"
steps:
- setup-tools-verilator:
- setup-tools:
tools-version: "<< parameters.tools-version >>"
- run:
name: Building << parameters.project-key >> subproject using Verilator
@@ -117,7 +111,7 @@ commands:
type: string
default: "10m"
steps:
- setup-tools-verilator:
- setup-tools:
tools-version: "<< parameters.tools-version >>"
- restore_cache:
keys:
@@ -143,6 +137,26 @@ jobs:
name: Check commits of each submodule
command: |
.circleci/check-commit.sh
tutorial-setup-check:
executor: main-env
steps:
- checkout
- run:
name: Check that the tutorial-setup patches apply
command: |
scripts/tutorial-setup.sh
documentation-check:
executor: main-env
steps:
- checkout
- run:
name: Check that documentation builds with no warnings/errors
command: |
sudo apt-get update -y
sudo apt-get install -y python3-pip
sudo pip3 install -r docs/requirements.txt
make -C docs html
install-riscv-toolchain:
executor: main-env
steps:
@@ -157,18 +171,10 @@ jobs:
executor: main-env
steps:
- ssh-checkout
- restore_cache:
keys:
- verilator-installed-<< pipeline.parameters.verilator-cache-version >>-{{ checksum "sims/verilator/verilator.mk" }}
- run:
name: Build Verilator
name: Install Verilator to remote
command: |
.circleci/build-verilator.sh
no_output_timeout: 120m
- save_cache:
key: verilator-installed-<< pipeline.parameters.verilator-cache-version >>-{{ checksum "sims/verilator/verilator.mk" }}
paths:
- "/home/riscvuser/verilator"
.circleci/install-verilator.sh
build-extra-tests:
executor: main-env
steps:
@@ -188,44 +194,49 @@ jobs:
key: extra-tests-{{ .Branch }}-{{ .Revision }}
paths:
- "/home/riscvuser/project/tests"
prepare-example:
prepare-chipyard-rocket:
executor: main-env
steps:
- prepare-rtl:
project-key: "example"
prepare-boomrocketexample:
project-key: "chipyard-rocket"
prepare-chipyard-sha3:
executor: main-env
steps:
- prepare-rtl:
project-key: "boomrocketexample"
project-key: "chipyard-sha3"
prepare-chipyard-hetero:
executor: main-env
steps:
- prepare-rtl:
project-key: "chipyard-hetero"
timeout: "240m"
prepare-boom:
prepare-chipyard-boom:
executor: main-env
steps:
- prepare-rtl:
project-key: "boom"
project-key: "chipyard-boom"
prepare-rocketchip:
executor: main-env
steps:
- prepare-rtl:
project-key: "rocketchip"
prepare-blockdevrocketchip:
prepare-chipyard-blkdev:
executor: main-env
steps:
- prepare-rtl:
project-key: "blockdevrocketchip"
prepare-hwacha:
project-key: "chipyard-blkdev"
prepare-chipyard-hwacha:
executor: main-env
steps:
- prepare-rtl:
tools-version: "esp-tools"
project-key: "hwacha"
prepare-gemmini:
project-key: "chipyard-hwacha"
prepare-chipyard-gemmini:
executor: main-env
steps:
- prepare-rtl:
tools-version: "esp-tools"
project-key: "gemmini"
project-key: "chipyard-gemmini"
prepare-tracegen:
executor: main-env
steps:
@@ -236,57 +247,84 @@ jobs:
steps:
- prepare-rtl:
project-key: "tracegen-boom"
prepare-firesim:
prepare-chipyard-ariane:
executor: main-env
steps:
- prepare-rtl:
project-key: "firesim"
build-script: "do-firesim-build.sh"
prepare-fireboom:
project-key: "chipyard-ariane"
prepare-icenet:
executor: main-env
steps:
- prepare-rtl:
project-key: "fireboom"
build-script: "do-firesim-build.sh"
midasexamples-run-tests:
project-key: "icenet"
prepare-testchipip:
executor: main-env
steps:
- setup-tools-verilator
- run:
name: Run midasexamples tests
command: .circleci/run-midasexamples-tests.sh
example-run-tests:
- prepare-rtl:
project-key: "testchipip"
prepare-chipyard-nvdla:
executor: main-env
steps:
- prepare-rtl:
project-key: "chipyard-nvdla"
prepare-chipyard-spiflashwrite:
executor: main-env
steps:
- prepare-rtl:
project-key: "chipyard-spiflashwrite"
prepare-chipyard-spiflashread:
executor: main-env
steps:
- prepare-rtl:
project-key: "chipyard-spiflashread"
chipyard-rocket-run-tests:
executor: main-env
steps:
- run-tests:
project-key: "example"
boomrocketexample-run-tests:
project-key: "chipyard-rocket"
chipyard-sha3-run-tests:
executor: main-env
steps:
- run-tests:
project-key: "boomrocketexample"
boom-run-tests:
project-key: "chipyard-sha3"
chipyard-hetero-run-tests:
executor: main-env
steps:
- run-tests:
project-key: "boom"
project-key: "chipyard-hetero"
timeout: "15m"
chipyard-boom-run-tests:
executor: main-env
steps:
- run-tests:
project-key: "chipyard-boom"
rocketchip-run-tests:
executor: main-env
steps:
- run-tests:
project-key: "rocketchip"
hwacha-run-tests:
chipyard-hwacha-run-tests:
executor: main-env
steps:
- run-tests:
tools-version: "esp-tools"
project-key: "hwacha"
gemmini-run-tests:
project-key: "chipyard-hwacha"
chipyard-gemmini-run-tests:
executor: main-env
steps:
- run-tests:
tools-version: "esp-tools"
project-key: "gemmini"
project-key: "chipyard-gemmini"
chipyard-spiflashwrite-run-tests:
executor: main-env
steps:
- run-tests:
project-key: "chipyard-spiflashwrite"
chipyard-spiflashread-run-tests:
executor: main-env
steps:
- run-tests:
project-key: "chipyard-spiflashread"
tracegen-run-tests:
executor: main-env
steps:
@@ -303,15 +341,55 @@ jobs:
- run-tests:
extra-cache-restore: "extra-tests"
project-key: "firesim"
run-script: "run-firesim-tests.sh"
run-script: "run-firesim-scala-tests.sh"
timeout: "20m"
fireboom-run-tests:
executor: main-env
steps:
- run-tests:
extra-cache-restore: "extra-tests"
project-key: "fireboom"
run-script: "run-firesim-tests.sh"
run-script: "run-firesim-scala-tests.sh"
timeout: "45m"
firesim-multiclock-run-tests:
executor: main-env
steps:
- run-tests:
extra-cache-restore: "extra-tests"
project-key: "firesim-multiclock"
run-script: "run-firesim-scala-tests.sh"
timeout: "20m"
midasexamples-run-tests:
executor: main-env
steps:
- setup-tools
- run:
name: Run midasexamples tests
command: .circleci/run-midasexamples-tests.sh
no_output_timeout: 20m
chipyard-ariane-run-tests:
executor: main-env
steps:
- run-tests:
project-key: "chipyard-ariane"
timeout: "30m"
chipyard-nvdla-run-tests:
executor: main-env
steps:
- run-tests:
project-key: "chipyard-nvdla"
icenet-run-tests:
executor: main-env
steps:
- run-tests:
project-key: "icenet"
timeout: "30m"
testchipip-run-tests:
executor: main-env
steps:
- run-tests:
project-key: "testchipip"
timeout: "30m"
# Order and dependencies of jobs to run
workflows:
@@ -335,28 +413,38 @@ workflows:
- install-esp-toolchain
# Build verilator
- install-verilator
- commit-on-master-check
# Attempt to apply the tutorial patches
- tutorial-setup-check
# Check that documentation builds
- documentation-check
# Build extra tests
- build-extra-tests:
requires:
- install-riscv-toolchain
# Prepare the verilator builds
- prepare-example:
- prepare-chipyard-rocket:
requires:
- install-riscv-toolchain
- install-verilator
- prepare-boomrocketexample:
- prepare-chipyard-sha3:
requires:
- install-riscv-toolchain
- install-verilator
- prepare-boom:
- prepare-chipyard-hetero:
requires:
- install-riscv-toolchain
- install-verilator
- prepare-chipyard-boom:
requires:
- install-riscv-toolchain
- install-verilator
@@ -366,17 +454,17 @@ workflows:
- install-riscv-toolchain
- install-verilator
- prepare-blockdevrocketchip:
- prepare-chipyard-blkdev:
requires:
- install-riscv-toolchain
- install-verilator
- prepare-hwacha:
- prepare-chipyard-hwacha:
requires:
- install-esp-toolchain
- install-verilator
- prepare-gemmini:
- prepare-chipyard-gemmini:
requires:
- install-esp-toolchain
- install-verilator
@@ -391,12 +479,32 @@ workflows:
- install-riscv-toolchain
- install-verilator
- prepare-firesim:
- prepare-chipyard-ariane:
requires:
- install-riscv-toolchain
- install-verilator
- prepare-fireboom:
- prepare-icenet:
requires:
- install-riscv-toolchain
- install-verilator
- prepare-testchipip:
requires:
- install-riscv-toolchain
- install-verilator
- prepare-chipyard-nvdla:
requires:
- install-riscv-toolchain
- install-verilator
- prepare-chipyard-spiflashwrite:
requires:
- install-riscv-toolchain
- install-verilator
- prepare-chipyard-spiflashread:
requires:
- install-riscv-toolchain
- install-verilator
@@ -407,32 +515,35 @@ workflows:
- midasexamples-run-tests:
requires:
- install-riscv-toolchain
- install-verilator
# Run the example tests
- example-run-tests:
- chipyard-rocket-run-tests:
requires:
- prepare-example
- prepare-chipyard-rocket
- boomrocketexample-run-tests:
- chipyard-sha3-run-tests:
requires:
- prepare-boomrocketexample
- prepare-chipyard-sha3
- boom-run-tests:
- chipyard-hetero-run-tests:
requires:
- prepare-boom
- prepare-chipyard-hetero
- chipyard-boom-run-tests:
requires:
- prepare-chipyard-boom
- rocketchip-run-tests:
requires:
- prepare-rocketchip
- hwacha-run-tests:
- chipyard-hwacha-run-tests:
requires:
- prepare-hwacha
- prepare-chipyard-hwacha
- gemmini-run-tests:
- chipyard-gemmini-run-tests:
requires:
- prepare-gemmini
- prepare-chipyard-gemmini
- tracegen-run-tests:
requires:
@@ -442,13 +553,42 @@ workflows:
requires:
- prepare-tracegen-boom
- chipyard-spiflashwrite-run-tests:
requires:
- prepare-chipyard-spiflashwrite
- chipyard-spiflashread-run-tests:
requires:
- prepare-chipyard-spiflashread
# Run the firesim tests
- firesim-run-tests:
requires:
- prepare-firesim
- install-riscv-toolchain
- install-verilator
- build-extra-tests
- firesim-multiclock-run-tests:
requires:
- install-riscv-toolchain
- install-verilator
- build-extra-tests
- fireboom-run-tests:
requires:
- prepare-fireboom
- install-riscv-toolchain
- install-verilator
- build-extra-tests
- chipyard-ariane-run-tests:
requires:
- prepare-chipyard-ariane
- chipyard-nvdla-run-tests:
requires:
- prepare-chipyard-nvdla
- icenet-run-tests:
requires:
- prepare-icenet
- testchipip-run-tests:
requires:
- prepare-testchipip

38
.circleci/defaults.sh
View File

@@ -20,35 +20,45 @@ clean () {
# make parallelism
NPROC=8
# verilator version
VERILATOR_VERSION=v4.034
# remote variables
REMOTE_WORK_DIR=$CI_DIR/$CIRCLE_PROJECT_REPONAME-$CIRCLE_BRANCH-$CIRCLE_SHA1-$CIRCLE_JOB
REMOTE_RISCV_DIR=$REMOTE_WORK_DIR/riscv-tools-install
REMOTE_ESP_DIR=$REMOTE_WORK_DIR/esp-tools-install
REMOTE_CHIPYARD_DIR=$REMOTE_WORK_DIR/chipyard
REMOTE_VERILATOR_DIR=$REMOTE_WORK_DIR/verilator
REMOTE_SIM_DIR=$REMOTE_CHIPYARD_DIR/sims/verilator
REMOTE_FIRESIM_DIR=$REMOTE_CHIPYARD_DIR/sims/firesim/sim
REMOTE_JAVA_ARGS="-Xmx8G -Xss8M -Dsbt.ivy.home=$REMOTE_WORK_DIR/.ivy2 -Dsbt.global.base=$REMOTE_WORK_DIR/.sbt -Dsbt.boot.directory=$REMOTE_WORK_DIR/.sbt/boot"
# Disable the supershell to greatly improve the readability of SBT output when captured by Circle CI
REMOTE_JAVA_ARGS="-Xmx9G -Xss8M -Dsbt.ivy.home=$REMOTE_WORK_DIR/.ivy2 -Dsbt.supershell=false -Dsbt.global.base=$REMOTE_WORK_DIR/.sbt -Dsbt.boot.directory=$REMOTE_WORK_DIR/.sbt/boot"
REMOTE_VERILATOR_DIR=$CI_DIR/$CIRCLE_PROJECT_REPONAME-$CIRCLE_BRANCH-$CIRCLE_SHA1-verilator-install
# local variables (aka within the docker container)
LOCAL_CHECKOUT_DIR=$HOME/project
LOCAL_RISCV_DIR=$HOME/riscv-tools-install
LOCAL_ESP_DIR=$HOME/esp-tools-install
LOCAL_CHIPYARD_DIR=$LOCAL_CHECKOUT_DIR
LOCAL_VERILATOR_DIR=$HOME/verilator
LOCAL_SIM_DIR=$LOCAL_CHIPYARD_DIR/sims/verilator
LOCAL_FIRESIM_DIR=$LOCAL_CHIPYARD_DIR/sims/firesim/sim
# key value store to get the build strings
declare -A mapping
mapping["example"]="SUB_PROJECT=example"
mapping["boomrocketexample"]="SUB_PROJECT=example CONFIG=LargeBoomAndRocketConfig"
mapping["boom"]="SUB_PROJECT=example CONFIG=SmallBoomConfig"
mapping["rocketchip"]="SUB_PROJECT=rocketchip"
mapping["blockdevrocketchip"]="SUB_PROJECT=example CONFIG=SimBlockDeviceRocketConfig"
mapping["hwacha"]="SUB_PROJECT=example CONFIG=HwachaRocketConfig"
mapping["gemmini"]="SUB_PROJECT=example CONFIG=GemminiRocketConfig"
mapping["tracegen"]="SUB_PROJECT=tracegen CONFIG=NonBlockingTraceGenL2Config"
mapping["tracegen-boom"]="SUB_PROJECT=tracegen CONFIG=BoomTraceGenConfig"
mapping["firesim"]="DESIGN=FireSim TARGET_CONFIG=DDR3FRFCFSLLC4MB_FireSimRocketChipConfig PLATFORM_CONFIG=BaseF1Config"
mapping["fireboom"]="DESIGN=FireSim TARGET_CONFIG=DDR3FRFCFSLLC4MB_FireSimBoomConfig PLATFORM_CONFIG=BaseF1Config"
mapping["chipyard-rocket"]="SUB_PROJECT=chipyard"
mapping["chipyard-sha3"]="SUB_PROJECT=chipyard CONFIG=Sha3RocketConfig"
mapping["chipyard-hetero"]="SUB_PROJECT=chipyard CONFIG=LargeBoomAndRocketConfig"
mapping["chipyard-boom"]="SUB_PROJECT=chipyard CONFIG=SmallBoomConfig"
mapping["chipyard-blkdev"]="SUB_PROJECT=chipyard CONFIG=SimBlockDeviceRocketConfig"
mapping["chipyard-hwacha"]="SUB_PROJECT=chipyard CONFIG=HwachaRocketConfig"
mapping["chipyard-gemmini"]="SUB_PROJECT=chipyard CONFIG=GemminiRocketConfig"
mapping["chipyard-ariane"]="SUB_PROJECT=chipyard CONFIG=ArianeConfig"
mapping["chipyard-spiflashread"]="SUB_PROJECT=chipyard CONFIG=LargeSPIFlashROMRocketConfig"
mapping["chipyard-spiflashwrite"]="SUB_PROJECT=chipyard CONFIG=SmallSPIFlashRocketConfig"
mapping["tracegen"]="SUB_PROJECT=chipyard CONFIG=NonBlockingTraceGenL2Config TOP=TraceGenSystem"
mapping["tracegen-boom"]="SUB_PROJECT=chipyard CONFIG=BoomTraceGenConfig TOP=TraceGenSystem"
mapping["chipyard-nvdla"]="SUB_PROJECT=chipyard CONFIG=SmallNVDLARocketConfig"
mapping["firesim"]="SCALA_TEST=firesim.firesim.RocketNICF1Tests"
mapping["firesim-multiclock"]="SCALA_TEST=firesim.firesim.RocketMulticlockF1Tests"
mapping["fireboom"]="SCALA_TEST=firesim.firesim.BoomF1Tests"
mapping["icenet"]="SUB_PROJECT=icenet"
mapping["testchipip"]="SUB_PROJECT=testchipip"

62
.circleci/do-firesim-build.sh
View File

@@ -1,62 +0,0 @@
#!/bin/bash
# create the different verilator builds
# argument is the make command string
# turn echo on and error on earliest command
set -ex
# get shared variables
SCRIPT_DIR="$( cd "$( dirname "$0" )" && pwd )"
source $SCRIPT_DIR/defaults.sh
# call clean on exit
trap clean EXIT
cd $LOCAL_CHIPYARD_DIR
./scripts/init-submodules-no-riscv-tools.sh
# set stricthostkeychecking to no (must happen before rsync)
run "echo \"Ping $SERVER\""
clean
# copy over riscv/esp-tools, verilator, and chipyard to remote
run "mkdir -p $REMOTE_CHIPYARD_DIR"
run "mkdir -p $REMOTE_VERILATOR_DIR"
copy $LOCAL_CHIPYARD_DIR/ $SERVER:$REMOTE_CHIPYARD_DIR
copy $LOCAL_VERILATOR_DIR/ $SERVER:$REMOTE_VERILATOR_DIR
run "cp -r ~/.ivy2 $REMOTE_WORK_DIR"
run "cp -r ~/.sbt $REMOTE_WORK_DIR"
TOOLS_DIR=$REMOTE_RISCV_DIR
LD_LIB_DIR=$REMOTE_RISCV_DIR/lib
VERILATOR_BIN_DIR=$REMOTE_VERILATOR_DIR/install/bin
if [ $1 = "hwacha" ] || [ $1 = "gemmini" ]; then
TOOLS_DIR=$REMOTE_ESP_DIR
LD_LIB_DIR=$REMOTE_ESP_DIR/lib
run "mkdir -p $REMOTE_ESP_DIR"
copy $LOCAL_ESP_DIR/ $SERVER:$REMOTE_ESP_DIR
else
run "mkdir -p $REMOTE_RISCV_DIR"
copy $LOCAL_RISCV_DIR/ $SERVER:$REMOTE_RISCV_DIR
fi
# Build MIDAS-level verilator sim
FIRESIM_VARS="${mapping[$1]}"
run "export FIRESIM_ENV_SOURCED=1; make -C $REMOTE_FIRESIM_DIR clean"
run "export RISCV=\"$TOOLS_DIR\"; export LD_LIBRARY_PATH=\"$LD_LIB_DIR\"; \
export PATH=\"$VERILATOR_BIN_DIR:\$PATH\"; export FIRESIM_ENV_SOURCED=1; \
export VERILATOR_ROOT=$REMOTE_VERILATOR_DIR/install/share/verilator; \
make -C $REMOTE_FIRESIM_DIR JAVA_ARGS=\"$REMOTE_JAVA_ARGS\" $FIRESIM_VARS verilator"
run "rm -rf $REMOTE_CHIPYARD_DIR/project"
# copy back the final build
mkdir -p $LOCAL_CHIPYARD_DIR
copy $SERVER:$REMOTE_CHIPYARD_DIR/ $LOCAL_CHIPYARD_DIR
# Fix dramsim2_ini symlink
export $FIRESIM_VARS
ln -sf $LOCAL_FIRESIM_DIR/midas/src/main/resources/dramsim2_ini $LOCAL_FIRESIM_DIR/generated-src/f1/${DESIGN}-${TARGET_CONFIG}-${PLATFORM_CONFIG}/dramsim2_ini

26
.circleci/do-rtl-build.sh
View File

@@ -21,18 +21,28 @@ run "echo \"Ping $SERVER\""
clean
# copy over riscv/esp-tools, verilator, and chipyard to remote
# copy over riscv/esp-tools, and chipyard to remote
run "mkdir -p $REMOTE_CHIPYARD_DIR"
run "mkdir -p $REMOTE_VERILATOR_DIR"
copy $LOCAL_CHIPYARD_DIR/ $SERVER:$REMOTE_CHIPYARD_DIR
copy $LOCAL_VERILATOR_DIR/ $SERVER:$REMOTE_VERILATOR_DIR
run "cp -r ~/.ivy2 $REMOTE_WORK_DIR"
run "cp -r ~/.sbt $REMOTE_WORK_DIR"
TOOLS_DIR=$REMOTE_RISCV_DIR
LD_LIB_DIR=$REMOTE_RISCV_DIR/lib
if [ $1 = "hwacha" ] || [ $1 = "gemmini" ]; then
if [ $1 = "chipyard-gemmini" ]; then
export RISCV=$LOCAL_ESP_DIR
export LD_LIBRARY_PATH=$LOCAL_ESP_DIR/lib
export PATH=$RISCV/bin:$PATH
GEMMINI_SOFTWARE_DIR=$LOCAL_SIM_DIR/../../generators/gemmini/software/gemmini-rocc-tests
cd $LOCAL_SIM_DIR/../../generators/gemmini/software
git submodule update --init --recursive gemmini-rocc-tests
cd gemmini-rocc-tests
./build.sh
fi
if [ $1 = "chipyard-hwacha" ] || [ $1 = "chipyard-gemmini" ]; then
TOOLS_DIR=$REMOTE_ESP_DIR
LD_LIB_DIR=$REMOTE_ESP_DIR/lib
run "mkdir -p $REMOTE_ESP_DIR"
@@ -44,9 +54,11 @@ fi
# enter the verilator directory and build the specific config on remote server
run "make -C $REMOTE_SIM_DIR clean"
run "export RISCV=\"$TOOLS_DIR\"; export LD_LIBRARY_PATH=\"$LD_LIB_DIR\"; \
export VERILATOR_ROOT=$REMOTE_VERILATOR_DIR/install/share/verilator; \
make -j$NPROC -C $REMOTE_SIM_DIR VERILATOR_INSTALL_DIR=$REMOTE_VERILATOR_DIR JAVA_ARGS=\"$REMOTE_JAVA_ARGS\" ${mapping[$1]}"
run "export RISCV=\"$TOOLS_DIR\"; \
export LD_LIBRARY_PATH=\"$LD_LIB_DIR\"; \
export PATH=\"$REMOTE_VERILATOR_DIR/bin:\$PATH\"; \
export VERILATOR_ROOT=\"$REMOTE_VERILATOR_DIR\"; \
make -j$NPROC -C $REMOTE_SIM_DIR JAVA_ARGS=\"$REMOTE_JAVA_ARGS\" ${mapping[$1]}"
run "rm -rf $REMOTE_CHIPYARD_DIR/project"
# copy back the final build

216
.circleci/images/Dockerfile Normal file
View File

@@ -0,0 +1,216 @@
### Note: This DockerFile is adapted from https://github.com/CircleCI-Public/example-images/openjdk
FROM openjdk:11.0.1-jdk-sid
# man directory is missing in some base images
# https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863199
RUN apt-get update \
&& mkdir -p /usr/share/man/man1 \
&& apt-get install -y \
bzip2 \
ca-certificates \
curl \
git \
gnupg \
gzip \
libfl2 \
libfl-dev \
locales \
mercurial \
netcat \
net-tools \
openssh-client \
parallel \
sudo \
tar \
unzip \
wget \
xvfb \
xxd \
zip \
ccache \
libgoogle-perftools-dev \
numactl \
zlib1g
# Set timezone to UTC by default
RUN ln -sf /usr/share/zoneinfo/Etc/UTC /etc/localtime
# Use unicode
RUN locale-gen C.UTF-8 || true
ENV LANG=C.UTF-8
# install jq
RUN JQ_URL="https://circle-downloads.s3.amazonaws.com/circleci-images/cache/linux-amd64/jq-latest" \
&& curl --silent --show-error --location --fail --retry 3 --output /usr/bin/jq $JQ_URL \
&& chmod +x /usr/bin/jq \
&& jq --version
# Install Docker
# Docker.com returns the URL of the latest binary when you hit a directory listing
# We curl this URL and `grep` the version out.
# The output looks like this:
#> # To install, run the following commands as root:
#> curl -fsSLO https://download.docker.com/linux/static/stable/x86_64/docker-17.05.0-ce.tgz && tar --strip-components=1 -xvzf docker-17.05.0-ce.tgz -C /usr/local/bin
#>
#> # Then start docker in daemon mode:
#> /usr/local/bin/dockerd
RUN set -ex \
&& export DOCKER_VERSION=$(curl --silent --fail --retry 3 https://download.docker.com/linux/static/stable/x86_64/ | grep -o -e 'docker-[.0-9]*-ce\.tgz' | sort -r | head -n 1) \
&& DOCKER_URL="https://download.docker.com/linux/static/stable/x86_64/${DOCKER_VERSION}" \
&& echo Docker URL: $DOCKER_URL \
&& curl --silent --show-error --location --fail --retry 3 --output /tmp/docker.tgz "${DOCKER_URL}" \
&& ls -lha /tmp/docker.tgz \
&& tar -xz -C /tmp -f /tmp/docker.tgz \
&& mv /tmp/docker/* /usr/bin \
&& rm -rf /tmp/docker /tmp/docker.tgz \
&& which docker \
&& (docker version || true)
# docker compose
RUN COMPOSE_URL="https://circle-downloads.s3.amazonaws.com/circleci-images/cache/linux-amd64/docker-compose-latest" \
&& curl --silent --show-error --location --fail --retry 3 --output /usr/bin/docker-compose $COMPOSE_URL \
&& chmod +x /usr/bin/docker-compose \
&& docker-compose version
# install dockerize
RUN DOCKERIZE_URL="https://circle-downloads.s3.amazonaws.com/circleci-images/cache/linux-amd64/dockerize-latest.tar.gz" \
&& curl --silent --show-error --location --fail --retry 3 --output /tmp/dockerize-linux-amd64.tar.gz $DOCKERIZE_URL \
&& tar -C /usr/local/bin -xzvf /tmp/dockerize-linux-amd64.tar.gz \
&& rm -rf /tmp/dockerize-linux-amd64.tar.gz \
&& dockerize --version
RUN groupadd --gid 3434 riscvuser \
&& useradd --uid 3434 --gid riscvuser --shell /bin/bash --create-home riscvuser \
&& echo 'riscvuser ALL=NOPASSWD: ALL' >> /etc/sudoers.d/50-riscvuser \
&& echo 'Defaults env_keep += "DEBIAN_FRONTEND"' >> /etc/sudoers.d/env_keep
# BEGIN IMAGE CUSTOMIZATIONS
# cacerts from OpenJDK 9-slim to workaround http://bugs.java.com/view_bug.do?bug_id=8189357
# AND https://github.com/docker-library/openjdk/issues/145
#
# Created by running:
# docker run --rm openjdk:9-slim cat /etc/ssl/certs/java/cacerts | # aws s3 cp - s3://circle-downloads/circleci-images/cache/linux-amd64/openjdk-9-slim-cacerts --acl public-read
RUN if java -fullversion 2>&1 | grep -q '"9.'; then curl --silent --show-error --location --fail --retry 3 --output /etc/ssl/certs/java/cacerts https://circle-downloads.s3.amazonaws.com/circleci-images/cache/linux-amd64/openjdk-9-slim-cacerts; fi
# Install Maven Version: 3.6.3
RUN curl --silent --show-error --location --fail --retry 3 --output /tmp/apache-maven.tar.gz https://www.apache.org/dist/maven/maven-3/3.6.3/binaries/apache-maven-3.6.3-bin.tar.gz \
&& tar xf /tmp/apache-maven.tar.gz -C /opt/ \
&& rm /tmp/apache-maven.tar.gz \
&& ln -s /opt/apache-maven-* /opt/apache-maven \
&& /opt/apache-maven/bin/mvn -version
# Install Ant Version: 1.10.5
RUN curl --silent --show-error --location --fail --retry 3 --output /tmp/apache-ant.tar.gz https://archive.apache.org/dist/ant/binaries/apache-ant-1.10.5-bin.tar.gz \
&& tar xf /tmp/apache-ant.tar.gz -C /opt/ \
&& ln -s /opt/apache-ant-* /opt/apache-ant \
&& rm -rf /tmp/apache-ant.tar.gz \
&& /opt/apache-ant/bin/ant -version
ENV ANT_HOME=/opt/apache-ant
# Install Gradle Version: 5.0
RUN curl --silent --show-error --location --fail --retry 3 --output /tmp/gradle.zip https://services.gradle.org/distributions/gradle-5.0-bin.zip \
&& unzip -d /opt /tmp/gradle.zip \
&& rm /tmp/gradle.zip \
&& ln -s /opt/gradle-* /opt/gradle \
&& /opt/gradle/bin/gradle -version
# Install sbt from https://circle-downloads.s3.amazonaws.com/circleci-images/cache/linux-amd64/sbt-latest.tgz
RUN curl --silent --show-error --location --fail --retry 3 --output /tmp/sbt.tgz https://circle-downloads.s3.amazonaws.com/circleci-images/cache/linux-amd64/sbt-latest.tgz \
&& tar -xzf /tmp/sbt.tgz -C /opt/ \
&& rm /tmp/sbt.tgz \
&& /opt/sbt/bin/sbt sbtVersion
# Install openjfx
RUN apt-get update
RUN apt-get install -y --no-install-recommends openjfx
# Add build-essential
RUN apt-get install -y build-essential
# Add RISCV toolchain necessary dependencies
RUN apt-get update
RUN apt-get install -y \
autoconf \
automake \
autotools-dev \
babeltrace \
bc \
curl \
device-tree-compiler \
expat \
flex \
gawk \
gperf \
g++ \
libexpat-dev \
libgmp-dev \
libmpc-dev \
libmpfr-dev \
libtool \
libusb-1.0-0-dev \
make \
patchutils \
pkg-config \
python \
python-pexpect-doc \
python3 \
texinfo \
zlib1g-dev \
rsync
# Use specific bison version to bypass Verilator 4.034 issues
# TODO: When Verilator is bumped, use apt to get newest bison
RUN wget https://ftp.gnu.org/gnu/bison/bison-3.5.4.tar.gz \
&& tar -xvf bison-3.5.4.tar.gz \
&& cd bison-3.5.4 \
&& ./configure && make && make install
# Check bison version is 3.5.4
RUN bison --version
# Add minimal QEMU dependencies
RUN apt-get install -y \
libfdt-dev \
libglib2.0-dev \
libpixman-1-dev
# Install verilator
RUN git clone http://git.veripool.org/git/verilator \
&& cd verilator \
&& git pull \
&& git checkout v4.034 \
&& autoconf && ./configure && make && make install
# Update PATH for Java tools
ENV PATH="/opt/sbt/bin:/opt/apache-maven/bin:/opt/apache-ant/bin:/opt/gradle/bin:$PATH"
# Add HOME environment variable
ENV HOME="/home/riscvuser"
# Update PATH for RISCV toolchain (note: hardcoded for CircleCI)
ENV RISCV="$HOME/riscv-tools-install"
ENV LD_LIBRARY_PATH="$RISCV/lib"
ENV PATH="$RISCV/bin:$PATH"
WORKDIR $HOME
USER riscvuser
# smoke test with path
RUN mvn -version \
&& ant -version \
&& gradle -version \
&& sbt sbtVersion \
&& verilator --version
# remove extra folders
RUN rm -rf project/
# END IMAGE CUSTOMIZATIONS
CMD ["/bin/sh"]

18
.circleci/images/README.md Normal file
View File

@@ -0,0 +1,18 @@
General
-------
This DockerFile contains the necessary steps to build a Docker container that can run
projects with riscv-tools, chisel3, firrtl, and verilator. It installs the necessary
apt-get packages and sets the environment variables needed in CircleCI.
Build and Deploy the Container
------------------------------
sudo docker build . # to test build before building it with a tag
sudo docker build -t <PATH_NAME>:tag . # to build with tag (ex. 0.0.3)
sudo docker login # login into the account to push to
sudo docker push <PATH_NAME>:tag # to push to repo with tag
Path Names
----------
Older docker images (when this Dockerfile was in `riscv-boom/riscv-boom`) can be found in the <PATH_NAME> `riscvboom/riscvboom-images`.
Current up-to-date images are located in <PATH_NAME> `ucbbar/chipyard-image`

23
.circleci/install-verilator.sh Executable file
View File

@@ -0,0 +1,23 @@
#!/bin/bash
# move verilator to the remote server
# turn echo on and error on earliest command
set -ex
# get shared variables
SCRIPT_DIR="$( cd "$( dirname "$0" )" && pwd )"
source $SCRIPT_DIR/defaults.sh
run_script $LOCAL_CHIPYARD_DIR/.circleci/clean-old-files.sh $CI_DIR
# set stricthostkeychecking to no (must happen before rsync)
run "echo \"Ping $SERVER\""
run "git clone http://git.veripool.org/git/verilator $REMOTE_VERILATOR_DIR; \
cd $REMOTE_VERILATOR_DIR; \
git checkout $VERILATOR_VERSION; \
autoconf; \
export VERILATOR_ROOT=$REMOTE_VERILATOR_DIR; \
./configure; \
make -j$NPROC;"

51
.circleci/run-firesim-scala-tests.sh Executable file
View File

@@ -0,0 +1,51 @@
#!/bin/bash
# create the different verilator builds
# argument is the make command string
# turn echo on and error on earliest command
set -ex
# get shared variables
SCRIPT_DIR="$( cd "$( dirname "$0" )" && pwd )"
source $SCRIPT_DIR/defaults.sh
# call clean on exit
trap clean EXIT
cd $LOCAL_CHIPYARD_DIR
./scripts/init-submodules-no-riscv-tools.sh
cd $LOCAL_CHIPYARD_DIR/sims/firesim/sim/firesim-lib/src/main/cc/lib
git submodule update --init elfutils libdwarf
cd $LOCAL_CHIPYARD_DIR/sims/firesim
./scripts/build-libelf.sh
./scripts/build-libdwarf.sh
cd $LOCAL_CHIPYARD_DIR
make -C $LOCAL_CHIPYARD_DIR/tools/dromajo/dromajo-src/src
# set stricthostkeychecking to no (must happen before rsync)
run "echo \"Ping $SERVER\""
clean
# copy over riscv/esp-tools, and chipyard to remote
run "mkdir -p $REMOTE_CHIPYARD_DIR"
run "mkdir -p $REMOTE_RISCV_DIR"
copy $LOCAL_CHIPYARD_DIR/ $SERVER:$REMOTE_CHIPYARD_DIR
copy $LOCAL_RISCV_DIR/ $SERVER:$REMOTE_RISCV_DIR
run "cp -r ~/.ivy2 $REMOTE_WORK_DIR"
run "cp -r ~/.sbt $REMOTE_WORK_DIR"
TOOLS_DIR=$REMOTE_RISCV_DIR
LD_LIB_DIR=$REMOTE_RISCV_DIR/lib
# Run Firesim Scala Tests
run "export RISCV=\"$TOOLS_DIR\"; \
export LD_LIBRARY_PATH=\"$LD_LIB_DIR\"; \
export FIRESIM_ENV_SOURCED=1; \
export PATH=\"$REMOTE_VERILATOR_DIR/bin:\$PATH\"; \
export VERILATOR_ROOT=\"$REMOTE_VERILATOR_DIR\"; \
make -C $REMOTE_FIRESIM_DIR JAVA_ARGS=\"$REMOTE_JAVA_ARGS\" testOnly ${mapping[$1]}"

21
.circleci/run-firesim-tests.sh
View File

@@ -1,21 +0,0 @@
#!/bin/bash
# turn echo on and error on earliest command
set -ex
# get remote exec variables
SCRIPT_DIR="$( cd "$( dirname "$0" )" && pwd )"
source $SCRIPT_DIR/defaults.sh
export PATH=$LOCAL_VERILATOR_DIR/install/bin:$PATH
export FIRESIM_ENV_SOURCED=1
SIMULATION_ARGS="${mapping[$1]}"
run_test_suite () {
make -C $LOCAL_FIRESIM_DIR $SIMULATION_ARGS run-${1}-tests-fast
}
run_test_suite bmark
run_test_suite nic
run_test_suite blockdev

17
.circleci/run-midasexamples-tests.sh
View File

@@ -12,6 +12,10 @@ trap clean EXIT
cd $LOCAL_CHIPYARD_DIR
./scripts/init-submodules-no-riscv-tools.sh
# build libdromajo_cosim
make -C $LOCAL_CHIPYARD_DIR/tools/dromajo/dromajo-src/src
cd sims/firesim/sim/midas
# set stricthostkeychecking to no (must happen before rsync)
@@ -19,13 +23,11 @@ run "echo \"Ping $SERVER\""
clean
# copy over riscv-tools, verilator, and chipyard to remote
# copy over riscv-tools, and chipyard to remote
run "mkdir -p $REMOTE_CHIPYARD_DIR"
run "mkdir -p $REMOTE_VERILATOR_DIR"
run "mkdir -p $REMOTE_RISCV_DIR"
copy $LOCAL_CHIPYARD_DIR/ $SERVER:$REMOTE_CHIPYARD_DIR
copy $LOCAL_VERILATOR_DIR/ $SERVER:$REMOTE_VERILATOR_DIR
copy $LOCAL_RISCV_DIR/ $SERVER:$REMOTE_RISCV_DIR
# Copy ivy2 and sbt directories
@@ -35,12 +37,13 @@ run "cp -r ~/.sbt $REMOTE_WORK_DIR"
TOOLS_DIR=$REMOTE_RISCV_DIR
LD_LIB_DIR=$REMOTE_RISCV_DIR/lib
VERILATOR_BIN_DIR=$REMOTE_VERILATOR_DIR/install/bin
# Run midasexamples test
run "export FIRESIM_ENV_SOURCED=1; make -C $REMOTE_FIRESIM_DIR clean"
run "export RISCV=\"$TOOLS_DIR\"; export LD_LIBRARY_PATH=\"$LD_LIB_DIR\"; \
export PATH=\"$VERILATOR_BIN_DIR:\$PATH\"; export FIRESIM_ENV_SOURCED=1; \
export VERILATOR_ROOT=$REMOTE_VERILATOR_DIR/install/share/verilator; \
run "export RISCV=\"$TOOLS_DIR\"; \
export LD_LIBRARY_PATH=\"$LD_LIB_DIR\"; \
export FIRESIM_ENV_SOURCED=1; \
export PATH=\"$REMOTE_VERILATOR_DIR/bin:\$PATH\"; \
export VERILATOR_ROOT=\"$REMOTE_VERILATOR_DIR\"; \
make -C $REMOTE_FIRESIM_DIR JAVA_ARGS=\"$REMOTE_JAVA_ARGS\" TARGET_PROJECT=midasexamples test"

60
.circleci/run-tests.sh
View File

@@ -9,14 +9,12 @@ set -ex
SCRIPT_DIR="$( cd "$( dirname "$0" )" && pwd )"
source $SCRIPT_DIR/defaults.sh
export VERILATOR_ROOT=$LOCAL_VERILATOR_DIR/install/share/verilator
run_bmark () {
make run-bmark-tests-fast -j$NPROC -C $LOCAL_SIM_DIR VERILATOR_INSTALL_DIR=$LOCAL_VERILATOR_DIR $@
make run-bmark-tests-fast -j$NPROC -C $LOCAL_SIM_DIR $@
}
run_asm () {
make run-asm-tests-fast -j$NPROC -C $LOCAL_SIM_DIR VERILATOR_INSTALL_DIR=$LOCAL_VERILATOR_DIR $@
make run-asm-tests-fast -j$NPROC -C $LOCAL_SIM_DIR $@
}
run_both () {
@@ -25,42 +23,53 @@ run_both () {
}
run_tracegen () {
make tracegen -C $LOCAL_SIM_DIR VERILATOR_INSTALL_DIR=$LOCAL_VERILATOR_DIR $@
make tracegen -C $LOCAL_SIM_DIR $@
}
# TODO BUG: the run-binary command forces a rebuild of the simulator in CI
# instead, directly run the simulator binary
case $1 in
example)
chipyard-rocket)
run_bmark ${mapping[$1]}
;;
boomexample)
chipyard-boom)
run_bmark ${mapping[$1]}
;;
boomrocketexample)
run_bmark ${mapping[$1]}
;;
boom)
chipyard-hetero)
run_bmark ${mapping[$1]}
;;
rocketchip)
run_bmark ${mapping[$1]}
;;
hwacha)
chipyard-hwacha)
export RISCV=$LOCAL_ESP_DIR
export LD_LIBRARY_PATH=$LOCAL_ESP_DIR/lib
export PATH=$RISCV/bin:$PATH
make run-rv64uv-p-asm-tests -j$NPROC -C $LOCAL_SIM_DIR VERILATOR_INSTALL_DIR=$LOCAL_VERILATOR_DIR ${mapping[$1]}
make run-rv64uv-p-asm-tests -j$NPROC -C $LOCAL_SIM_DIR ${mapping[$1]}
;;
gemmini)
chipyard-gemmini)
export RISCV=$LOCAL_ESP_DIR
export LD_LIBRARY_PATH=$LOCAL_ESP_DIR/lib
export PATH=$RISCV/bin:$PATH
GEMMINI_SOFTWARE_DIR=$LOCAL_SIM_DIR/../../generators/gemmini/software/gemmini-rocc-tests
cd $GEMMINI_SOFTWARE_DIR
./build.sh
rm -rf $GEMMINI_SOFTWARE_DIR/riscv-tests
cd $LOCAL_SIM_DIR
$LOCAL_SIM_DIR/simulator-example-GemminiRocketConfig $GEMMINI_SOFTWARE_DIR/build/bareMetalC/aligned-baremetal
$LOCAL_SIM_DIR/simulator-example-GemminiRocketConfig $GEMMINI_SOFTWARE_DIR/build/bareMetalC/raw_hazard-baremetal
$LOCAL_SIM_DIR/simulator-example-GemminiRocketConfig $GEMMINI_SOFTWARE_DIR/build/bareMetalC/mvin_mvout-baremetal
$LOCAL_SIM_DIR/simulator-chipyard-GemminiRocketConfig $GEMMINI_SOFTWARE_DIR/build/bareMetalC/aligned-baremetal
$LOCAL_SIM_DIR/simulator-chipyard-GemminiRocketConfig $GEMMINI_SOFTWARE_DIR/build/bareMetalC/raw_hazard-baremetal
$LOCAL_SIM_DIR/simulator-chipyard-GemminiRocketConfig $GEMMINI_SOFTWARE_DIR/build/bareMetalC/mvin_mvout-baremetal
;;
chipyard-sha3)
(cd $LOCAL_CHIPYARD_DIR/generators/sha3/software && ./build.sh)
$LOCAL_SIM_DIR/simulator-chipyard-Sha3RocketConfig $LOCAL_CHIPYARD_DIR/generators/sha3/software/benchmarks/bare/sha3-rocc.riscv
;;
chipyard-spiflashread)
make -C $LOCAL_CHIPYARD_DIR/tests
make -C $LOCAL_SIM_DIR ${mapping[$1]} BINARY=$LOCAL_CHIPYARD_DIR/tests/spiflashread.riscv SIM_FLAGS="+spiflash0=${LOCAL_CHIPYARD_DIR}/tests/spiflash.img" run-binary
;;
chipyard-spiflashwrite)
make -C $LOCAL_CHIPYARD_DIR/tests
make -C $LOCAL_SIM_DIR ${mapping[$1]} BINARY=$LOCAL_CHIPYARD_DIR/tests/spiflashwrite.riscv SIM_FLAGS="+spiflash0=${LOCAL_CHIPYARD_DIR}/tests/spiflash.img" run-binary
[[ "`xxd $LOCAL_CHIPYARD_DIR/tests/spiflash.img | grep 1337\ 00ff\ aa55\ face | wc -l`" == "6" ]] || false
;;
tracegen)
run_tracegen ${mapping[$1]}
@@ -68,6 +77,19 @@ case $1 in
tracegen-boom)
run_tracegen ${mapping[$1]}
;;
chipyard-ariane)
make run-binary-fast -C $LOCAL_SIM_DIR ${mapping[$1]} BINARY=$RISCV/riscv64-unknown-elf/share/riscv-tests/benchmarks/dhrystone.riscv
;;
chipyard-nvdla)
make -C $LOCAL_CHIPYARD_DIR/tests
make -C $LOCAL_SIM_DIR ${mapping[$1]} BINARY=$LOCAL_CHIPYARD_DIR/tests/nvdla.riscv run-binary
;;
icenet)
make run-none-fast -C $LOCAL_SIM_DIR ${mapping[$1]}
;;
testchipip)
make run-none-fast -C $LOCAL_SIM_DIR ${mapping[$1]}
;;
*)
echo "No set of tests for $1. Did you spell it right?"
exit 1

12
.github/ISSUE_TEMPLATE/bug-report.md vendored
View File

@@ -8,16 +8,14 @@ labels: bug
<!-- choose one -->
**Impact**: rtl | software | unknown | other
**Tell us about your environment:**
*Chipyard Version:* <!-- 1.2.0, Hash: 2c0928 -->
*OS:* <!-- `Linux knight 4.4.0-92-generic #115-Ubuntu SMP Thu Aug 10 09:04:33 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux` -->
*Other:* <!-- `prior steps taken/documentation followed/...` -->
**What is the current behavior?**
**What is the expected behavior?**
**Please tell us about your environment:**
<!-- (examples)
- version: `chipyard git commit hash`
- os: `Linux knight 4.4.0-92-generic #115-Ubuntu SMP Thu Aug 10 09:04:33 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux`
- other: `prior steps taken/documentation followed/...`
-->
**Other information**
<!-- include detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, ... -->

5
.github/ISSUE_TEMPLATE/question.md vendored
View File

@@ -5,6 +5,11 @@ labels: question
---
<!--
this type of issue is more for "how-tos", understanding chipyard, etc.
if you find an error or issue with chipyard, please use the "Bug Report Issue".
-->
<!-- have you looked at the Chipyard documentation? -->
<!-- have you looked at the subproject documentation/githubs? -->
<!-- for example: -->

1
.gitignore vendored
View File

@@ -1,4 +1,5 @@
bootrom/*
docs/warnings.txt
/Makefrag.pkgs
target
*.jar

15
.gitmodules vendored
View File

@@ -113,3 +113,18 @@
[submodule "software/firemarshal"]
path = software/firemarshal
url = https://github.com/firesim/FireMarshal.git
[submodule "generators/ariane"]
path = generators/ariane
url = https://github.com/ucb-bar/ariane-wrapper.git
[submodule "tools/DRAMSim2"]
path = tools/DRAMSim2
url = https://github.com/firesim/DRAMSim2.git
[submodule "generators/nvdla"]
path = generators/nvdla
url = https://github.com/ucb-bar/nvdla-wrapper.git
[submodule "software/nvdla-workload"]
path = software/nvdla-workload
url = https://github.com/ucb-bar/nvdla-workload.git
[submodule "tools/dromajo/dromajo-src"]
path = tools/dromajo/dromajo-src
url = https://github.com/riscv-boom/dromajo.git

37
CHANGELOG.md
View File

@@ -2,6 +2,43 @@
This changelog follows the format defined here: https://keepachangelog.com/en/1.0.0/
## [1.2.0] - 2020-03-14
A more detailed account of everything included is included in the dev to master PR for this release: https://github.com/ucb-bar/chipyard/pull/418
### Added
* Ring Topology System Bus NoC (#461)
* Integration of the Ariane core into Chipyard (#448)
* FireMarshal now generates an extra copy of linux kernel with dwarf debugging info for use in FirePerf (#427)
* Add option to use blackboxed SimDRAM instead of SimAXIMem (#449)
* Log `init-submodules` script (#433)
* Moved the Docker image used for CI into Chipyard (prev. in BOOM) (#463)
### Changed
* Bump FireSim to 1.9.0 - Includes FirePerf TracerV Flame Graph features
* IOBinders and BuildTop unification between FireChip and Chipyard (#390)
* Bump BOOM to version 2.2.4 (#463)
* Bump Gemmini to version 0.2 (#469)
* Update to CircleCI 2.1 config. syntax and cleanup CI file (#421)
* FireMarshal moved from FireSim to Chipyard (#415)
* Rename config. mixins to config fragments (#451)
### Fixed
* `git status` should be clean. (Although you will need to manually cleanup the libgloss and qemu directories after first setup). (#411, #414)
* Fix Hetero. BOOM + Rocket + Hwacha config (#413)
* Fix VCS stdout (#417)
* Add a git version check to the init scripts and make them work outside of the repo root (#459)
* Fix generation of env.sh for zsh (#435)
* GCD example bug (#465)
### Deprecated
* N/A
### Removed
* N/A
## [1.1.0] - 2020-01-25
A more detailed account of everything included is included in the dev to master PR for this release: https://github.com/ucb-bar/chipyard/pull/367

7
README.md
View File

@@ -10,14 +10,14 @@ To get started using Chipyard, see the documentation on the Chipyard documentati
Chipyard is an open source framework for agile development of Chisel-based systems-on-chip.
It will allow you to leverage the Chisel HDL, Rocket Chip SoC generator, and other [Berkeley][berkeley] projects to produce a [RISC-V][riscv] SoC with everything from MMIO-mapped peripherals to custom accelerators.
Chipyard contains processor cores ([Rocket][rocket-chip], [BOOM][boom]), accelerators ([Hwacha][hwacha]), memory systems, and additional peripherals and tooling to help create a full featured SoC.
Chipyard contains processor cores ([Rocket][rocket-chip], [BOOM][boom], [Ariane][ariane]), accelerators ([Hwacha][hwacha], [Gemmini][gemmini], [NVDLA][nvdla]), memory systems, and additional peripherals and tooling to help create a full featured SoC.
Chipyard supports multiple concurrent flows of agile hardware development, including software RTL simulation, FPGA-accelerated simulation ([FireSim][firesim]), automated VLSI flows ([Hammer][hammer]), and software workload generation for bare-metal and Linux-based systems ([FireMarshal][firemarshal]).
Chipyard is actively developed in the [Berkeley Architecture Research Group][ucb-bar] in the [Electrical Engineering and Computer Sciences Department][eecs] at the [University of California, Berkeley][berkeley].
## Resources
* Chipyard Documentation: https://chipyard.readthedocs.io/
* Chipyard Basics slides: https://fires.im/micro19-slides-pdf/02_chipyard_basics.pdf
* Chipyard Basics slides: https://fires.im/micro19-slides-pdf/02_chipyard_basics.pdf
* Chipyard Tutorial Exercise slides: https://fires.im/micro19-slides-pdf/03_building_custom_socs.pdf
## Need help?
@@ -63,3 +63,6 @@ These publications cover many of the internal components used in Chipyard. Howev
[rocket-chip]: https://github.com/freechipsproject/rocket-chip
[boom]: https://github.com/ucb-bar/riscv-boom
[firemarshal]: https://github.com/firesim/FireMarshal/
[ariane]: https://github.com/pulp-platform/ariane/
[gemmini]: https://github.com/ucb-bar/gemmini
[nvdla]: http://nvdla.org/

38
build.sbt
View File

@@ -2,7 +2,7 @@ import Tests._
// This gives us a nicer handle to the root project instead of using the
// implicit one
lazy val chipyardRoot = RootProject(file("."))
lazy val chipyardRoot = Project("chipyardRoot", file("."))
lazy val commonSettings = Seq(
organization := "edu.berkeley.cs",
@@ -122,16 +122,21 @@ lazy val testchipip = (project in file("generators/testchipip"))
.dependsOn(rocketchip, sifive_blocks)
.settings(commonSettings)
lazy val example = conditionalDependsOn(project in file("generators/example"))
.dependsOn(boom, hwacha, sifive_blocks, sifive_cache, utilities, sha3, gemmini, icenet)
lazy val iocell = (project in file("./tools/barstools/iocell/"))
.dependsOn(chisel)
.settings(commonSettings)
lazy val chipyard = conditionalDependsOn(project in file("generators/chipyard"))
.dependsOn(boom, hwacha, sifive_blocks, sifive_cache, utilities, iocell,
sha3, // On separate line to allow for cleaner tutorial-setup patches
gemmini, icenet, tracegen, ariane, nvdla)
.settings(commonSettings)
lazy val tracegen = conditionalDependsOn(project in file("generators/tracegen"))
.dependsOn(rocketchip, sifive_cache, boom)
.dependsOn(rocketchip, sifive_cache, boom, utilities)
.settings(commonSettings)
lazy val utilities = conditionalDependsOn(project in file("generators/utilities"))
.dependsOn(rocketchip, boom)
.settings(commonSettings)
lazy val icenet = (project in file("generators/icenet"))
@@ -142,7 +147,11 @@ lazy val hwacha = (project in file("generators/hwacha"))
.dependsOn(rocketchip)
.settings(commonSettings)
lazy val boom = (project in file("generators/boom"))
lazy val boom = conditionalDependsOn(project in file("generators/boom"))
.dependsOn(rocketchip)
.settings(commonSettings)
lazy val ariane = (project in file("generators/ariane"))
.dependsOn(rocketchip)
.settings(commonSettings)
@@ -154,10 +163,15 @@ lazy val gemmini = (project in file("generators/gemmini"))
.dependsOn(rocketchip, chisel_testers, testchipip)
.settings(commonSettings)
lazy val tapeout = conditionalDependsOn(project in file("./tools/barstools/tapeout/"))
.dependsOn(chisel_testers, example)
lazy val nvdla = (project in file("generators/nvdla"))
.dependsOn(rocketchip)
.settings(commonSettings)
lazy val tapeout = conditionalDependsOn(project in file("./tools/barstools/tapeout/"))
.dependsOn(chisel_testers, chipyard)
.settings(commonSettings)
.settings(libraryDependencies ++= Seq("io.github.daviddenton" %% "handlebars-scala-fork" % "2.3.0"))
lazy val mdf = (project in file("./tools/barstools/mdf/scalalib/"))
.settings(commonSettings)
@@ -195,10 +209,10 @@ lazy val sifive_cache = (project in file("generators/sifive-cache")).settings(
lazy val midas = ProjectRef(firesimDir, "midas")
lazy val firesimLib = ProjectRef(firesimDir, "firesimLib")
lazy val firechip = (project in file("generators/firechip"))
.dependsOn(boom, hwacha, example, icenet, testchipip, sifive_blocks, sifive_cache, sha3, utilities, tracegen, midasTargetUtils, midas, firesimLib % "test->test;compile->compile")
lazy val firechip = conditionalDependsOn(project in file("generators/firechip"))
.dependsOn(chipyard, midasTargetUtils, midas, firesimLib % "test->test;compile->compile")
.settings(
commonSettings,
testGrouping in Test := isolateAllTests( (definedTests in Test).value )
testGrouping in Test := isolateAllTests( (definedTests in Test).value ),
testOptions in Test += Tests.Argument("-oF")
)

96
common.mk
View File

@@ -4,12 +4,28 @@
SHELL=/bin/bash
#########################################################################################
# variables to get all *.scala files
# extra make variables/rules from subprojects
#
# EXTRA_GENERATOR_REQS - requirements needed for the main generator
# EXTRA_SIM_FLAGS - runtime simulation flags
# EXTRA_SIM_CC_FLAGS - cc flags for simulators
# EXTRA_SIM_SOURCES - simulation sources needed for simulator
# EXTRA_SIM_REQS - requirements to build the simulator
#########################################################################################
lookup_scala_srcs = $(shell find -L $(1)/ -name target -prune -o -iname "*.scala" -print 2> /dev/null)
include $(base_dir)/generators/ariane/ariane.mk
include $(base_dir)/generators/tracegen/tracegen.mk
include $(base_dir)/generators/nvdla/nvdla.mk
include $(base_dir)/tools/dromajo/dromajo.mk
SOURCE_DIRS=$(addprefix $(base_dir)/,generators sims/firesim/sim)
SCALA_SOURCES=$(call lookup_scala_srcs,$(SOURCE_DIRS))
#########################################################################################
# Prerequisite lists
#########################################################################################
# Returns a list of files in directory $1 with file extension $2.
lookup_srcs = $(shell find -L $(1)/ -name target -prune -o -iname "*.$(2)" -print 2> /dev/null)
SOURCE_DIRS = $(addprefix $(base_dir)/,generators sims/firesim/sim tools/barstools/iocell)
SCALA_SOURCES = $(call lookup_srcs,$(SOURCE_DIRS),scala)
VLOG_SOURCES = $(call lookup_srcs,$(SOURCE_DIRS),sv) $(call lookup_srcs,$(SOURCE_DIRS),v)
#########################################################################################
# rocket and testchipip classes
@@ -22,17 +38,24 @@ TESTCHIPIP_CLASSES ?= "$(TESTCHIP_DIR)/target/scala-$(SCALA_VERSION_MAJOR)/class
# jar creation variables and rules
#########################################################################################
FIRRTL_JAR := $(base_dir)/lib/firrtl.jar
FIRRTL_TEST_JAR := $(base_dir)/test_lib/firrtl-test.jar
$(FIRRTL_JAR): $(call lookup_scala_srcs, $(CHIPYARD_FIRRTL_DIR)/src/main/scala)
$(FIRRTL_JAR): $(call lookup_srcs,$(CHIPYARD_FIRRTL_DIR),scala)
$(MAKE) -C $(CHIPYARD_FIRRTL_DIR) SBT="$(SBT)" root_dir=$(CHIPYARD_FIRRTL_DIR) build-scala
mkdir -p $(@D)
cp -p $(CHIPYARD_FIRRTL_DIR)/utils/bin/firrtl.jar $@
touch $@
$(FIRRTL_TEST_JAR): $(call lookup_srcs,$(CHIPYARD_FIRRTL_DIR),scala)
cd $(CHIPYARD_FIRRTL_DIR) && $(SBT) "test:assembly"
mkdir -p $(@D)
cp -p $(CHIPYARD_FIRRTL_DIR)/utils/bin/firrtl-test.jar $@
touch $@
#########################################################################################
# create list of simulation file inputs
#########################################################################################
$(sim_files): $(call lookup_scala_srcs,$(base_dir)/generators/utilities/src/main/scala) $(FIRRTL_JAR)
$(sim_files): $(call lookup_srcs,$(base_dir)/generators/utilities/src/main/scala,scala) $(FIRRTL_JAR)
cd $(base_dir) && $(SBT) "project utilities" "runMain utilities.GenerateSimFiles -td $(build_dir) -sim $(sim_name)"
#########################################################################################
@@ -42,9 +65,14 @@ $(sim_files): $(call lookup_scala_srcs,$(base_dir)/generators/utilities/src/main
$(FIRRTL_FILE) $(ANNO_FILE): generator_temp
@echo "" > /dev/null
generator_temp: $(SCALA_SOURCES) $(sim_files)
# AG: must re-elaborate if ariane sources have changed... otherwise just run firrtl compile
generator_temp: $(SCALA_SOURCES) $(sim_files) $(EXTRA_GENERATOR_REQS)
mkdir -p $(build_dir)
cd $(base_dir) && $(SBT) "project $(SBT_PROJECT)" "runMain $(GENERATOR_PACKAGE).Generator $(build_dir) $(MODEL_PACKAGE) $(MODEL) $(CONFIG_PACKAGE) $(CONFIG)"
cd $(base_dir) && $(SBT) "project $(SBT_PROJECT)" "runMain $(GENERATOR_PACKAGE).Generator \
--target-dir $(build_dir) \
--name $(long_name) \
--top-module $(MODEL_PACKAGE).$(MODEL) \
--legacy-configs $(CONFIG_PACKAGE).$(CONFIG)"
.PHONY: firrtl
firrtl: $(FIRRTL_FILE)
@@ -64,7 +92,7 @@ HARNESS_TARGETS = $(HARNESS_FILE) $(HARNESS_SMEMS_CONF) $(HARNESS_ANNO) $(HARNES
$(TOP_TARGETS) $(HARNESS_TARGETS): firrtl_temp
@echo "" > /dev/null
firrtl_temp: $(FIRRTL_FILE) $(ANNO_FILE)
firrtl_temp: $(FIRRTL_FILE) $(ANNO_FILE) $(VLOG_SOURCES)
cd $(base_dir) && $(SBT) "project tapeout" "runMain barstools.tapeout.transforms.GenerateTopAndHarness -o $(TOP_FILE) -tho $(HARNESS_FILE) -i $(FIRRTL_FILE) --syn-top $(TOP) --harness-top $(VLOG_MODEL) -faf $(ANNO_FILE) -tsaof $(TOP_ANNO) -tdf $(sim_top_blackboxes) -tsf $(TOP_FIR) -thaof $(HARNESS_ANNO) -hdf $(sim_harness_blackboxes) -thf $(HARNESS_FIR) $(REPL_SEQ_MEM) $(HARNESS_CONF_FLAGS) -td $(build_dir)" && touch $(sim_top_blackboxes) $(sim_harness_blackboxes)
# DOC include end: FirrtlCompiler
@@ -89,7 +117,7 @@ harness_macro_temp: $(HARNESS_SMEMS_CONF) | top_macro_temp
# remove duplicate files and headers in list of simulation file inputs
########################################################################################
$(sim_common_files): $(sim_files) $(sim_top_blackboxes) $(sim_harness_blackboxes)
awk '{print $1;}' $^ | sort -u | grep -v '.*\.h$$' > $@
awk '{print $1;}' $^ | sort -u | grep -v '.*\.\(svh\|h\)$$' > $@
#########################################################################################
# helper rule to just make verilog files
@@ -102,22 +130,28 @@ verilog: $(sim_vsrcs)
#########################################################################################
.PHONY: run-binary run-binary-fast run-binary-debug run-fast
run-binary: $(sim)
(set -o pipefail && $(sim) $(PERMISSIVE_ON) +max-cycles=$(timeout_cycles) $(SIM_FLAGS) $(VERBOSE_FLAGS) $(PERMISSIVE_OFF) $(BINARY) </dev/null 2> >(spike-dasm > $(sim_out_name).out) | tee $(sim_out_name).log)
(set -o pipefail && $(sim) $(PERMISSIVE_ON) $(SIM_FLAGS) $(EXTRA_SIM_FLAGS) $(VERBOSE_FLAGS) $(PERMISSIVE_OFF) $(BINARY) </dev/null 2> >(spike-dasm > $(sim_out_name).out) | tee $(sim_out_name).log)
#########################################################################################
# helper rules to run simulator as fast as possible
#########################################################################################
run-binary-fast: $(sim)
(set -o pipefail && $(sim) $(PERMISSIVE_ON) +max-cycles=$(timeout_cycles) $(SIM_FLAGS) $(PERMISSIVE_OFF) $(BINARY) </dev/null | tee $(sim_out_name).log)
(set -o pipefail && $(sim) $(PERMISSIVE_ON) $(SIM_FLAGS) $(EXTRA_SIM_FLAGS) $(PERMISSIVE_OFF) $(BINARY) </dev/null | tee $(sim_out_name).log)
#########################################################################################
# helper rules to run simulator with as much debug info as possible
#########################################################################################
run-binary-debug: $(sim_debug)
(set -o pipefail && $(sim_debug) $(PERMISSIVE_ON) +max-cycles=$(timeout_cycles) $(SIM_FLAGS) $(VERBOSE_FLAGS) $(WAVEFORM_FLAG) $(PERMISSIVE_OFF) $(BINARY) </dev/null 2> >(spike-dasm > $(sim_out_name).out) | tee $(sim_out_name).log)
(set -o pipefail && $(sim_debug) $(PERMISSIVE_ON) $(SIM_FLAGS) $(EXTRA_SIM_FLAGS) $(VERBOSE_FLAGS) $(WAVEFORM_FLAG) $(PERMISSIVE_OFF) $(BINARY) </dev/null 2> >(spike-dasm > $(sim_out_name).out) | tee $(sim_out_name).log)
run-fast: run-asm-tests-fast run-bmark-tests-fast
run-none: $(output_dir)/none.out
run-none-fast: $(output_dir)/none.run
run-none-debug: $(output_dir)/none.vpd
#########################################################################################
# run assembly/benchmarks rules
#########################################################################################
@@ -126,10 +160,18 @@ $(output_dir)/%: $(RISCV)/riscv64-unknown-elf/share/riscv-tests/isa/%
ln -sf $< $@
$(output_dir)/%.run: $(output_dir)/% $(sim)
(set -o pipefail && $(sim) $(PERMISSIVE_ON) +max-cycles=$(timeout_cycles) $(SIM_FLAGS) $(PERMISSIVE_OFF) $< </dev/null | tee $<.log) && touch $@
(set -o pipefail && $(sim) $(PERMISSIVE_ON) $(SIM_FLAGS) $(EXTRA_SIM_FLAGS) $(PERMISSIVE_OFF) $< </dev/null | tee $<.log) && touch $@
$(output_dir)/%.out: $(output_dir)/% $(sim)
(set -o pipefail && $(sim) $(PERMISSIVE_ON) +max-cycles=$(timeout_cycles) $(VERBOSE_FLAGS) $(PERMISSIVE_OFF) $< </dev/null 2> >(spike-dasm > $@) | tee $<.log)
(set -o pipefail && $(sim) $(PERMISSIVE_ON) $(SIM_FLAGS) $(EXTRA_SIM_FLAGS) $(VERBOSE_FLAGS) $(PERMISSIVE_OFF) $< </dev/null 2> >(spike-dasm > $@) | tee $<.log)
$(output_dir)/none.run: $(sim)
mkdir -p $(output_dir)
(set -o pipefail && $(sim) $(PERMISSIVE_ON) $(SIM_FLAGS) $(EXTRA_SIM_FLAGS) $(PERMISSIVE_OFF) $< </dev/null | tee $<.log) && touch $@
$(output_dir)/none.out: $(sim)
mkdir -p $(output_dir)
(set -o pipefail && $(sim) $(PERMISSIVE_ON) $(SIM_FLAGS) $(EXTRA_SIM_FLAGS) $(VERBOSE_FLAGS) $(PERMISSIVE_OFF) none </dev/null 2> >(spike-dasm > $@) | tee $(output_dir)/none.log)
#########################################################################################
# include build/project specific makefrags made from the generator
@@ -138,22 +180,12 @@ ifneq ($(filter run% %.run %.out %.vpd %.vcd,$(MAKECMDGOALS)),)
-include $(build_dir)/$(long_name).d
endif
#################################################
# Rules for running and checking tracegen tests #
#################################################
#######################################
# Rules for building DRAMSim2 library #
#######################################
AXE_DIR=$(base_dir)/tools/axe/src
AXE=$(AXE_DIR)/axe
dramsim_dir = $(base_dir)/tools/DRAMSim2
dramsim_lib = $(dramsim_dir)/libdramsim.a
$(AXE): $(wildcard $(AXE_DIR)/*.[ch]) $(AXE_DIR)/make.sh
cd $(AXE_DIR) && ./make.sh
$(output_dir)/tracegen.out: $(sim)
mkdir -p $(output_dir) && $(sim) $(PERMISSIVE_ON) +max-cycles=$(timeout_cycles) $(VERBOSE_FLAGS) $(PERMISSIVE_OFF) none </dev/null 2> $@
$(output_dir)/tracegen.result: $(output_dir)/tracegen.out $(AXE)
$(base_dir)/scripts/check-tracegen.sh $< > $@
tracegen: $(output_dir)/tracegen.result
.PHONY: tracegen
$(dramsim_lib):
$(MAKE) -C $(dramsim_dir) $(notdir $@)

8
docs/Advanced-Concepts/CDEs.rst
View File

@@ -28,11 +28,11 @@ Consider the following example using CDEs.
}
When forming a query based on a ``Parameters`` object, like ``p(SomeKeyX)``, the configuration system traverses the "chain" of mixins until it finds a partial function which is defined at the key, and then returns that value.
When forming a query based on a ``Parameters`` object, like ``p(SomeKeyX)``, the configuration system traverses the "chain" of config fragments until it finds a partial function which is defined at the key, and then returns that value.
.. code:: scala
val params = Config(new WithX(true) ++ new WithY(true)) // "chain" together mixins
val params = Config(new WithX(true) ++ new WithY(true)) // "chain" together config fragments
params(SomeKeyX) // evaluates to true
params(SomeKeyY) // evaluates to true
params(SomeKeyZ) // evaluates to false
@@ -68,7 +68,7 @@ In this example, the partial function in ``WithXEqualsYSite`` will look up the v
Here
~~~~
``here`` provides a ``View`` of the locally defined Config, which typically just contains some partial function.
``here`` provides a ``View`` of the locally defined config, which typically just contains some partial function.
.. code:: scala
@@ -103,7 +103,7 @@ Up
params_1(SomeKeyX) // evaluates to true
params_2(SomeKeyX) // evaluates to false
In this example, note how ``up(SomeKeyY, site)`` in ``WithXEqualsYUp`` will refer to *either* the the partial function defining ``SomeKeyY`` in ``WithY(true)`` *or* the default value for ``SomeKeyY`` provided in the original ``case object SomeKeyY`` definition, *depending on the order in which the mixins were used*. Since the order of mixins affects the the order of the ``View`` traversal, ``up`` provides a different ``View`` of the parameterization in ``params_1`` and ``params_2``.
In this example, note how ``up(SomeKeyY, site)`` in ``WithXEqualsYUp`` will refer to *either* the the partial function defining ``SomeKeyY`` in ``WithY(true)`` *or* the default value for ``SomeKeyY`` provided in the original ``case object SomeKeyY`` definition, *depending on the order in which the config fragments were used*. Since the order of config fragments affects the the order of the ``View`` traversal, ``up`` provides a different ``View`` of the parameterization in ``params_1`` and ``params_2``.
Also note that again, ``site`` must be recursively passed through the call to ``up``.

13
docs/Advanced-Concepts/Chip-Communication.rst
View File

@@ -81,7 +81,7 @@ Similar to TSI, the DMI protocol is an implementation of HTIF.
In order to communicate with the DUT with the DMI protocol, the DUT needs to contain a Debug Transfer Module (DTM).
The DTM is given in the `RISC-V Debug Specification <https://riscv.org/specifications/debug-specification/>`__
and is responsible for managing communication between the DUT and whatever lives on the other side of the DMI (in this case FESVR).
This is implemented in the Rocket Chip ``Subsystem`` by having the ``HasPeripheryDebug`` and ``HasPeripheryDebugModuleImp`` mixins.
This is implemented in the Rocket Chip ``Subsystem`` by having the ``HasPeripheryDebug`` and ``HasPeripheryDebugModuleImp`` traits.
During simulation, the host sends DMI commands to a
simulation stub called ``SimDTM`` (C++ class) that resides in a ``SimDTM`` Verilog module
(both are located in the ``generators/rocket-chip`` project). This ``SimDTM`` Verilog module then
@@ -109,16 +109,13 @@ reminder, to run a software RTL simulation, run:
FireSim FPGA-accelerated simulations use TSI by default as well.
If you would like to build and simulate a Chipyard configuration with a DTM configured for DMI communication, then you must create a
top-level system with the DTM (``TopWithDTM``), a test-harness to connect to the DTM (``TestHarnessWithDTM``), as well as a config to use that top-level system.
If you would like to build and simulate a Chipyard configuration with a DTM configured for DMI communication, then you must tie-off the TSI interface, and instantiate the `SimDTM`. Note that we use `WithTiedOffSerial ++ WithSimDebug` instead of `WithTiedOffDebug ++ WithSimSerial`.
.. literalinclude:: ../../generators/example/src/main/scala/RocketConfigs.scala
.. literalinclude:: ../../generators/chipyard/src/main/scala/config/RocketConfigs.scala
:language: scala
:start-after: DOC include start: DmiRocket
:end-before: DOC include end: DmiRocket
In this example, the ``WithDTM`` mixin specifies that the top-level SoC will instantiate a DTM (that by default is setup to use DMI).
The rest of the mixins specify the rest of the system (cores, accelerators, etc).
Then you can run simulations with the new DMI-enabled top-level and test-harness.
.. code-block:: bash
@@ -141,10 +138,10 @@ Creating a DTM+JTAG Config
First, a DTM config must be created for the system that you want to create.
This step is similar to the DMI simulation section within the :ref:`Starting the TSI or DMI Simulation` section.
The configuration is very similar to a DMI-based configuration. The main difference
is the addition of the ``WithJtagDTM`` mixin that configures the instantiated DTM to use the JTAG protocol as the
is the addition of the ``WithJtagDTM`` config fragment that configures the instantiated DTM to use the JTAG protocol as the
bringup method.
.. literalinclude:: ../../generators/example/src/main/scala/RocketConfigs.scala
.. literalinclude:: ../../generators/chipyard/src/main/scala/config/RocketConfigs.scala
:language: scala
:start-after: DOC include start: JtagRocket
:end-before: DOC include end: JtagRocket

30
docs/Advanced-Concepts/Debugging-BOOM.rst Normal file
View File

@@ -0,0 +1,30 @@
Debugging BOOM
======================
In addition to the default debugging techniques specified in :ref:`Debugging RTL`,
single-core BOOM designs can utilize the Dromajo co-simulator (see :ref:`Dromajo`)
to verify functionality.
.. warning:: Dromajo currently only works in single-core BOOM systems without accelerators.
.. warning:: Dromajo currently only works in VCS simulation and FireSim.
Setting up Dromajo Co-simulation
--------------------------------------
Dromajo co-simulation is setup to work when two config fragments are added to a BOOM config.
First, a ``chipyard.config.WithTraceIO`` config fragment must be added so that BOOM's traceport is enabled.
Second, a ``chipyard.iobinders.WithSimDromajoBridge`` config fragment must be added to
connect the Dromajo co-simulator to the traceport.
Once both config fragments are added Dromajo should be enabled.
To build/run Dromajo with a BOOM design, run your configuration the following make commands:
.. code-block:: shell
# build the default Dromajo BOOM config without waveform dumps
# replace "DromajoBoomConfig" with your particular config
make CONFIG=DromajoBoomConfig ENABLE_DROMAJO=1
# run a simulation with Dromajo
make CONFIG=DromajoBoomConfig ENABLE_DROMAJO=1 BINARY=<YOUR-BIN> run-binary

2
docs/Advanced-Concepts/Debugging-RTL.rst
View File

@@ -88,7 +88,7 @@ directory.
Firesim Debugging
---------------------------
Chisel printfs, asserts, and waveform generation are also available in FireSim
Chisel printfs, asserts, Dromajo co-simulation, and waveform generation are also available in FireSim
FPGA-accelerated simulation. See the FireSim
`documentation <https://docs.fires.im/en/latest/>`__ for more detail.

33
docs/Advanced-Concepts/Top-Testharness.rst
View File

@@ -2,17 +2,28 @@ Tops, Test-Harnesses, and the Test-Driver
===========================================
The three highest levels of hierarchy in a Chipyard
SoC are the Top (DUT), ``TestHarness``, and the ``TestDriver``.
The Top and ``TestHarness`` are both emitted by Chisel generators.
SoC are the ``ChipTop`` (DUT), ``TestHarness``, and the ``TestDriver``.
The ``ChipTop`` and ``TestHarness`` are both emitted by Chisel generators.
The ``TestDriver`` serves as our testbench, and is a Verilog
file in Rocket Chip.
Top/DUT
ChipTop/DUT
-------------------------
The top-level module of a Rocket Chip SoC is composed via cake-pattern.
Specifically, "Tops" extend a ``System``, which extends a ``Subsystem``, which extends a ``BaseSubsystem``.
``ChipTop`` is the top-level module that instantiates the ``System`` submodule, usually an instance of the concrete class ``DigitalTop``.
The vast majority of the design resides in the ``System``.
Other components that exist inside the ``ChipTop`` layer are generally IO cells, clock receivers and multiplexers, reset synchronizers, and other analog IP that needs to exist outside of the ``System``.
The ``IOBinders`` are responsible for instantiating the IO cells and defining the test harness collateral that connects to the top-level ports.
Most of these types of devices can be instantiated using custom ``IOBinders``, so the provided ``ChipTop`` and ``ChipTopCaughtReset`` classes are sufficient.
However, if needed, the ``BaseChipTop`` abstract class can be extended for building more custom ``ChipTop`` designs.
System/DigitalTop
-------------------------
The system module of a Rocket Chip SoC is composed via cake-pattern.
Specifically, ``DigitalTop`` extends a ``System``, which extends a ``Subsystem``, which extends a ``BaseSubsystem``.
BaseSubsystem
@@ -27,7 +38,7 @@ We also see this class define several ``ElaborationArtefacts``, files emitted af
Subsystem
^^^^^^^^^^^^^^^^^^^^^^^^^
Looking in `generators/utilities/src/main/scala/Subsystem.scala <https://github.com/ucb-bar/chipyard/blob/master/generators/utilities/src/main/scala/Subsystem.scala>`__, we can see how Chipyard's ``Subsystem``
Looking in `generators/chipyard/src/main/scala/Subsystem.scala <https://github.com/ucb-bar/chipyard/blob/master/generators/chipyard/src/main/scala/Subsystem.scala>`__, we can see how Chipyard's ``Subsystem``
extends the ``BaseSubsystem`` abstract class. ``Subsystem`` mixes in the ``HasBoomAndRocketTiles`` trait that
defines and instantiates BOOM or Rocket tiles, depending on the parameters specified.
We also connect some basic IOs for each tile here, specifically the hartids and the reset vector.
@@ -35,7 +46,7 @@ We also connect some basic IOs for each tile here, specifically the hartids and
System
^^^^^^^^^^^^^^^^^^^^^^^^^
``generators/utilities/src/main/scala/System.scala`` completes the definition of the ``System``.
``generators/chipyard/src/main/scala/System.scala`` completes the definition of the ``System``.
- ``HasHierarchicalBusTopology`` is defined in Rocket Chip, and specifies connections between the top-level buses
- ``HasAsyncExtInterrupts`` and ``HasExtInterruptsModuleImp`` adds IOs for external interrupts and wires them appropriately to tiles
@@ -45,17 +56,17 @@ System
Tops
^^^^^^^^^^^^^^^^^^^^^^^^^
A SoC Top then extends the ``System`` class with any config-specific components.
A SoC Top then extends the ``System`` class with traits for custom components.
In Chipyard, this includes things like adding a NIC, UART, and GPIO as well as setting up the hardware for the bringup method.
Please refer to :ref:`Communicating with the DUT` for more information on these bringup methods.
TestHarness
-------------------------
The wiring between the ``TestHarness`` and the Top are performed in methods defined in mixins added to the Top.
The wiring between the ``TestHarness`` and the Top are performed in methods defined in traits added to the Top.
When these methods are called from the ``TestHarness``, they may instantiate modules within the scope of the harness,
and then connect them to the DUT. For example, the ``connectSimAXIMem`` method defined in the
``CanHaveMasterAXI4MemPortModuleImp`` trait, when called from the ``TestHarness``, will instantiate ``SimAXIMem``s
``CanHaveMasterAXI4MemPortModuleImp`` trait, when called from the ``TestHarness``, will instantiate ``SimAXIMems``
and connect them to the correct IOs of the top.
While this roundabout way of attaching to the IOs of the top may seem to be unnecessarily complex, it allows the designer to compose
@@ -66,4 +77,4 @@ TestDriver
The ``TestDriver`` is defined in ``generators/rocketchip/src/main/resources/vsrc/TestDriver.v``.
This Verilog file executes a simulation by instantiating the ``TestHarness``, driving the clock and reset signals, and interpreting the success output.
This file is compiled with the generated Verilog for the ``TestHarness`` and the Top to produce a simulator.
This file is compiled with the generated Verilog for the ``TestHarness`` and the ``Top`` to produce a simulator.

3
docs/Advanced-Concepts/index.rst
View File

@@ -2,7 +2,7 @@ Advanced Concepts
================================
The following sections are advanced topics about how to Chipyard works, how to use Chipyard, and special features of the framework.
They expect you to know about Chisel, Parameters, Configs, etc.
They expect you to know about Chisel, Parameters, configs, etc.
.. toctree::
:maxdepth: 2
@@ -11,6 +11,7 @@ They expect you to know about Chisel, Parameters, Configs, etc.
Top-Testharness
Chip-Communication
Debugging-RTL
Debugging-BOOM
Resources
CDEs

14
docs/Chipyard-Basics/Chipyard-Components.rst
View File

@@ -20,6 +20,10 @@ Processor Cores
An out-of-order RISC-V core.
See :ref:`Berkeley Out-of-Order Machine (BOOM)` for more information.
**Ariane Core**
An in-order RISC-V core written in System Verilog.
See :ref:`Ariane Core` for more information.
Accelerators
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -29,9 +33,9 @@ Accelerators
Hwacha integrates with a Rocket or BOOM core using the RoCC (Rocket Custom Co-processor) interface.
See :ref:`Hwacha` for more information.
.. Fixed Function Accelerators:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TBD
**Gemmini**
A matrix-multiply accelerator targeting neural-networks
**SHA3**
A fixed-function accelerator for the SHA3 hash function. This simple accelerator is used as a demonstration for some of the
Chipyard integration flows using the RoCC interface.
@@ -75,6 +79,10 @@ Tools
**Dsptools**
A Chisel library for writing custom signal processing hardware, as well as integrating custom signal processing hardware into an SoC (especially a Rocket-based SoC).
**Dromajo**
A RV64GC emulator primarily used for co-simulation and was originally developed by Esperanto Technologies.
See :ref:`Dromajo` for more information.
Toolchains
-------------------------------------------

84
docs/Chipyard-Basics/Configs-Parameters-Mixins.rst
View File

@@ -1,4 +1,4 @@
Configs, Parameters, Mix-ins, and Everything In Between
Configs, Parameters, Mixins, and Everything In Between
========================================================
A significant portion of generators in the Chipyard framework use the Rocket Chip parameter system.
@@ -14,12 +14,12 @@ We are still investigating methods to facilitate parameter exploration and disco
Configs
---------------------
A *Config* is a collection of multiple generator parameters being set to specific values.
Configs are additive, can override each other, and can be composed of other Configs.
The naming convention for an additive Config is ``With<YourConfigName>``, while the naming convention for a non-additive Config will be ``<YourConfig>``.
A *config* is a collection of multiple generator parameters being set to specific values.
Configs are additive, can override each other, and can be composed of other configs (sometimes referred to as config fragments).
The naming convention for an additive config or config fragment is ``With<YourConfigName>``, while the naming convention for a non-additive config will be ``<YourConfig>``.
Configs can take arguments which will in-turn set parameters in the design or reference other parameters in the design (see :ref:`Parameters`).
This example shows a basic additive Config class that takes in zero arguments and instead uses hardcoded values to set the RTL design parameters.
This example shows a basic config fragment class that takes in zero arguments and instead uses hardcoded values to set the RTL design parameters.
In this example, ``MyAcceleratorConfig`` is a Scala case class that defines a set of variables that the generator can use when referencing the ``MyAcceleratorKey`` in the design.
.. _basic-config-example:
@@ -36,7 +36,7 @@ In this example, ``MyAcceleratorConfig`` is a Scala case class that defines a se
someLength = 256)
})
This next example shows a "higher-level" additive Config that uses prior parameters that were set to derive other parameters.
This next example shows a "higher-level" additive config fragment that uses prior parameters that were set to derive other parameters.
.. _complex-config-example:
.. code-block:: scala
@@ -50,8 +50,8 @@ This next example shows a "higher-level" additive Config that uses prior paramet
hartId = up(RocketTilesKey, site).length)
})
The following example shows a non-additive Config that combines the prior two additive Configs using ``++``.
The additive Configs are applied from the right to left in the list (or bottom to top in the example).
The following example shows a non-additive config that combines or "assembles" the prior two config fragments using ``++``.
The additive config fragments are applied from the right to left in the list (or bottom to top in the example).
Thus, the order of the parameters being set will first start with the ``DefaultExampleConfig``, then ``WithMyAcceleratorParams``, then ``WithMyMoreComplexAcceleratorConfig``.
.. _top-level-config:
@@ -68,58 +68,44 @@ The ``site`` map gives you the definitions as seen from the root of the configur
The ``here`` map gives the definitions as seen at the current level of the hierarchy (i.e. in ``WithMyMoreComplexAcceleratorConfig`` itself).
The ``up`` map gives the definitions as seen from the next level up from the current (i.e. from ``WithMyAcceleratorParams``).
Cake Pattern
Cake Pattern / Mixin
-------------------------
A cake pattern is a Scala programming pattern, which enable "mixing" of multiple traits or interface definitions (sometimes referred to as dependency injection).
A cake pattern or mixin is a Scala programming pattern, which enable "mixing" of multiple traits or interface definitions (sometimes referred to as dependency injection).
It is used in the Rocket Chip SoC library and Chipyard framework in merging multiple system components and IO interfaces into a large system component.
This example shows a Rocket Chip based SoC that merges multiple system components (BootROM, UART, etc) into a single top-level design.
This example shows the Chipyard default top that composes multiple traits together into a fully-featured SoC with many optional components.
.. _cake-example:
.. code-block:: scala
class MySoC(implicit p: Parameters) extends RocketSubsystem
with CanHaveMasterAXI4MemPort
with HasPeripheryBootROM
with HasNoDebug
with HasPeripherySerial
with HasPeripheryUART
with HasPeripheryIceNIC
{
lazy val module = new MySoCModuleImp(this)
}
.. literalinclude:: ../../generators/chipyard/src/main/scala/DigitalTop.scala
:language: scala
:start-after: DOC include start: DigitalTop
:end-before: DOC include end: DigitalTop
class MySoCModuleImp(outer: MySoC) extends RocketSubsystemModuleImp(outer)
with CanHaveMasterAXI4MemPortModuleImp
with HasPeripheryBootROMModuleImp
with HasNoDebugModuleImp
with HasPeripherySerialModuleImp
with HasPeripheryUARTModuleImp
with HasPeripheryIceNICModuleImp
There are two "cakes" here. One for the lazy module (ex. ``HasPeripherySerial``) and one for the lazy module
implementation (ex. ``HasPeripherySerialModuleImp`` where ``Imp`` refers to implementation). The lazy module defines
There are two "cakes" or mixins here. One for the lazy module (ex. ``CanHavePeripherySerial``) and one for the lazy module
implementation (ex. ``CanHavePeripherySerialModuleImp`` where ``Imp`` refers to implementation). The lazy module defines
all the logical connections between generators and exchanges configuration information among them, while the
lazy module implementation performs the actual Chisel RTL elaboration.
In the ``MySoC`` example class, the "outer" ``MySoC`` instantiates the "inner"
``MySoCModuleImp`` as a lazy module implementation. This delays immediate elaboration
In the ``DigitalTop`` example class, the "outer" ``DigitalTop`` instantiates the "inner"
``DigitalTopModule`` as a lazy module implementation. This delays immediate elaboration
of the module until all logical connections are determined and all configuration information is exchanged.
The ``RocketSubsystem`` outer base class, as well as the
``HasPeripheryX`` outer traits contain code to perform high-level logical
connections. For example, the ``HasPeripherySerial`` outer trait contains code
to lazily instantiate the ``SerialAdapter``, and connect the ``SerialAdapter``'s
The ``System`` outer base class, as well as the
``CanHavePeriphery<X>`` outer traits contain code to perform high-level logical
connections. For example, the ``CanHavePeripherySerial`` outer trait contains code
to optionally lazily instantiate the ``SerialAdapter``, and connect the ``SerialAdapter``'s
TileLink node to the Front bus.
The ``ModuleImp`` classes and traits perform elaboration of real RTL.
For example, the ``HasPeripherySerialModuleImp`` trait physically connects
For example, the ``CanHavePeripherySerialModuleImp`` trait optionally physically connects
the ``SerialAdapter`` module, and instantiates queues.
In the test harness, the SoC is elaborated with
``val dut = Module(LazyModule(MySoC))``.
After elaboration, the result will be a ``MySoC`` module, which contains a
``SerialAdapter`` module (among others).
``val dut = p(BuildTop)(p)``.
After elaboration, the system submodule of ``ChipTop`` will be a ``DigitalTop`` module, which contains a
``SerialAdapter`` module (among others), if the config specified for that block to be instantiated.
From a high level, classes which extend ``LazyModule`` *must* reference
their module implementation through ``lazy val module``, and they
@@ -129,15 +115,13 @@ contain the implementation for the module, and may instantiate
other normal modules OR lazy modules (for nested Diplomacy
graphs, for example).
Mix-in
---------------------------
A mix-in is a Scala trait, which sets parameters for specific system components, as well as enabling instantiation and wiring of the relevant system components to system buses.
The naming convention for an additive mix-in is ``Has<YourMixin>``.
This is shown in the ``MySoC`` class where things such as ``HasPeripherySerial`` connect a RTL component to a bus and expose signals to the top-level.
The naming convention for an additive mixin or trait is ``CanHave<YourMixin>``.
This is shown in the ``Top`` class where things such as ``CanHavePeripherySerial`` connect a RTL component to a bus and expose signals to the top-level.
Additional References
---------------------------
A brief explanation of some of these topics is given in the following video: https://www.youtube.com/watch?v=Eko86PGEoDY.
Another description of traits/mixins and config fragments is given in :ref:`Keys, Traits, and Configs`.
Additionally, a brief explanation of some of these topics (with slightly different naming) is given in the following video: https://www.youtube.com/watch?v=Eko86PGEoDY.
.. Note:: Chipyard uses the name "config fragments" over "config mixins" to avoid confusion between a mixin applying to a config or to the system ``Top`` (even though both are technically Scala mixins).

2
docs/Chipyard-Basics/Development-Ecosystem.rst
View File

@@ -16,7 +16,7 @@ Chisel is an embedded language within Scala that provides a set of libraries to
FIRRTL on the other hand is a compiler for hardware which allows the user to run FIRRTL passes that can do dead code elimination, circuit analysis, connectivity checks, and much more!
These two tools in combination allow quick design space exploration and development of new RTL.
Generators
RTL Generators
-------------------------------------------
Within this repository, all of the Chisel RTL is written as generators.

70
docs/Chipyard-Basics/Initial-Repo-Setup.rst
View File

@@ -23,10 +23,10 @@ In Ubuntu/Debian-based platforms (Ubuntu), we recommend installing the following
.. Note:: When running on an Amazon Web Services EC2 FPGA-development instance (for FireSim), FireSim includes a machine setup script that will install all of the aforementioned dependencies (and some additional ones).
Checking out the sources
------------------------
Setting up the Chipyard Repo
-------------------------------------------
After cloning this repo, you will need to initialize all of the submodules.
Start by fetching Chipyard's sources. Run:
.. code-block:: shell
@@ -34,6 +34,11 @@ After cloning this repo, you will need to initialize all of the submodules.
cd chipyard
./scripts/init-submodules-no-riscv-tools.sh
This will initialize and checkout all of the necessary git submodules.
When updating Chipyard to a new version, you will also want to rerun this script to update the submodules.
Using git directly will try to initialize all submodules; this is not recommended unless you expressly desire this behavior.
.. _build-toolchains:
Building a Toolchain
@@ -43,15 +48,66 @@ The `toolchains` directory contains toolchains that include a cross-compiler too
Currently there are two toolchains, one for normal RISC-V programs, and another for Hwacha (``esp-tools``).
For custom installations, Each tool within the toolchains contains individual installation procedures within its README file.
To get a basic installation (which is the only thing needed for most Chipyard use-cases), just the following steps are necessary.
This will take about 20-30 minutes. You can expedite the process by setting a ``make`` environment variable to use parallel cores: ``export MAKEFLAGS=-j8``.
.. code-block:: shell
./scripts/build-toolchains.sh riscv-tools # for a normal risc-v toolchain
# OR
./scripts/build-toolchains.sh esp-tools # for a modified risc-v toolchain with Hwacha vector instructions
.. Note:: If you are planning to use the Hwacha vector unit, or other RoCC-based accelerators, you should build the esp-tools toolchain by adding the ``esp-tools`` argument to the script above.
If you are running on an Amazon Web Services EC2 instance, intending to use FireSim, you can also use the ``--ec2fast`` flag for an expedited installation of a pre-compiled toolchain.
Once the script is run, a ``env.sh`` file is emitted that sets the ``PATH``, ``RISCV``, and ``LD_LIBRARY_PATH`` environment variables.
You can put this in your ``.bashrc`` or equivalent environment setup file to get the proper variables.
You can put this in your ``.bashrc`` or equivalent environment setup file to get the proper variables, or directly include it in your current environment:
.. code-block:: shell
source ./env.sh
These variables need to be set for the ``make`` system to work properly.
What's Next?
-------------------------------------------
This depends on what you are planning to do with Chipyard.
* If you intend to run a simulation of one of the vanilla Chipyard examples, go to :ref:`sw-rtl-sim-intro` and follow the instructions.
* If you intend to run a simulation of a custom Chipyard SoC Configuration, go to :ref:`Simulating A Custom Project` and follow the instructions.
* If you intend to run a full-system FireSim simulation, go to :ref:`firesim-sim-intro` and follow the instructions.
* If you intend to add a new accelerator, go to :ref:`customization` and follow the instructions.
* If you want to learn about the structure of Chipyard, go to :ref:`chipyard-components`.
* If you intend to change the generators (BOOM, Rocket, etc) themselves, see :ref:`generator-index`.
* If you intend to run a tutorial VLSI flow using one of the Chipyard examples, go to :ref:`tutorial` and follow the instructions.
* If you intend to build a chip using one of the vanilla Chipyard examples, go to :ref:`build-a-chip` and follow the instructions.
Upgrading Chipyard Release Versions
-------------------------------------------
In order to upgrade between Chipyard versions, we recommend using a fresh clone of the repository (or your fork, with the new release merged into it).
Chipyard is a complex framework that depends on a mix of build systems and scripts. Specifically, it relies on git submodules, on sbt build files, and on custom written bash scripts and generated files.
For this reason, upgrading between Chipyard versions is **not** as trivial as just running ``git submodule update -recursive``. This will result in recursive cloning of large submodules that are not necessarily used within your specific Chipyard environments. Furthermore, it will not resolve the status of stale state generated files which may not be compatible between release versions.
If you are an advanced git user, an alternative approach to a fresh repository clone may be to run ``git clean -dfx``, and then run the standard Chipyard setup sequence. This approach is dangerous, and **not-recommended** for users who are not deeply familiar with git, since it "blows up" the repository state and removes all untracked and modified files without warning. Hence, if you were working on custom un-committed changes, you would lose them.
If you would still like to try to perform an in-place manual version upgrade (**not-recommended**), we recommend at least trying to resolve stale state in the following areas:
* Delete stale ``target`` directories generated by sbt.
* Delete jar collateral generated by FIRRTL (``lib/firrtl.jar``)
* Re-generate generated scripts and source files (for example, ``env.sh``)
* Re-generating/deleting target software state (Linux kernel binaries, Linux images) within FireMarshal
This is by no means a comprehensive list of potential stale state within Chipyard. Hence, as mentioned earlier, the recommended method for a Chipyard version upgrade is a fresh clone (or a merge, and then a fresh clone).

4
docs/Customization/Custom-Chisel.rst
View File

@@ -52,8 +52,8 @@ Then add ``yourproject`` to the Chipyard top-level build.sbt file.
You can then import the classes defined in the submodule in a new project if
you add it as a dependency. For instance, if you want to use this code in
the ``example`` project, change the final line in build.sbt to the following.
the ``chipyard`` project, change the final line in build.sbt to the following.
.. code-block:: scala
lazy val example = (project in file(".")).settings(commonSettings).dependsOn(testchipip, yourproject)
lazy val chipyard = (project in file(".")).settings(commonSettings).dependsOn(testchipip, yourproject)

12
docs/Customization/DMA-Devices.rst
View File

@@ -12,13 +12,13 @@ having the CPU poll data from the device, we may want to have the device write
directly to the coherent memory system instead. For example, here is a device
that writes zeros to the memory at a configured address.
.. literalinclude:: ../../generators/example/src/main/scala/InitZero.scala
.. literalinclude:: ../../generators/chipyard/src/main/scala/example/InitZero.scala
:language: scala
.. literalinclude:: ../../generators/example/src/main/scala/Top.scala
.. literalinclude:: ../../generators/chipyard/src/main/scala/DigitalTop.scala
:language: scala
:start-after: DOC include start: Top
:end-before: DOC include end: Top
:start-after: DOC include start: DigitalTop
:end-before: DOC include end: DigitalTop
We use ``TLHelper.makeClientNode`` to create a TileLink client node for us.
We then connect the client node to the memory system through the front bus (fbus).
@@ -26,12 +26,12 @@ For more info on creating TileLink client nodes, take a look at :ref:`Client Nod
Once we've created our top-level module including the DMA widget, we can create a configuration for it as we did before.
.. literalinclude:: ../../generators/example/src/main/scala/ConfigMixins.scala
.. literalinclude:: ../../generators/chipyard/src/main/scala/example/InitZero.scala
:language: scala
:start-after: DOC include start: WithInitZero
:end-before: DOC include end: WithInitZero
.. literalinclude:: ../../generators/example/src/main/scala/RocketConfigs.scala
.. literalinclude:: ../../generators/chipyard/src/main/scala/config/RocketConfigs.scala
:language: scala
:start-after: DOC include start: InitZeroRocketConfig
:end-before: DOC include end: InitZeroRocketConfig

41
docs/Customization/Heterogeneous-SoCs.rst
View File

@@ -7,29 +7,29 @@ This discussion will focus on how you combine Rocket, BOOM and Hwacha in particu
Creating a Rocket and BOOM System
-------------------------------------------
Instantiating an SoC with Rocket and BOOM cores is all done with the configuration system and two specific mixins.
Both BOOM and Rocket have mixins labelled ``WithNBoomCores(X)`` and ``WithNBigCores(X)`` that automatically create ``X`` copies of the core/tile [1]_.
Instantiating an SoC with Rocket and BOOM cores is all done with the configuration system and two specific config fragments.
Both BOOM and Rocket have config fragments labelled ``WithNBoomCores(X)`` and ``WithNBigCores(X)`` that automatically create ``X`` copies of the core/tile [1]_.
When used together you can create a heterogeneous system.
The following example shows a dual core BOOM with a single core Rocket.
.. literalinclude:: ../../generators/example/src/main/scala/HeteroConfigs.scala
.. literalinclude:: ../../generators/chipyard/src/main/scala/config/HeteroConfigs.scala
:language: scala
:start-after: DOC include start: DualBoomAndRocket
:end-before: DOC include end: DualBoomAndRocket
In this example, the ``WithNBoomCores`` and ``WithNBigCores`` mixins set up the default parameters for the multiple BOOM and Rocket cores, respectively.
However, for BOOM, an extra mixin called ``WithLargeBooms`` is added to override the default parameters with a different set of more common default parameters.
This mixin applies to all BOOM cores in the system and changes the parameters for each.
In this example, the ``WithNBoomCores`` and ``WithNBigCores`` config fragments set up the default parameters for the multiple BOOM and Rocket cores, respectively.
However, for BOOM, an extra config fragment called ``WithLargeBooms`` is added to override the default parameters with a different set of more common default parameters.
This config fragment applies to all BOOM cores in the system and changes the parameters for each.
Great! Now you have a heterogeneous setup with BOOMs and Rockets.
The final thing you need to make this system work is to renumber the ``hartId``'s of the cores so that each core has a unique ``hartId`` (a ``hartId`` is the hardware thread id of the core).
The ``WithRenumberHarts`` mixin solves this by assigning a unique ``hartId`` to all cores in the system (it can label the Rocket cores first or the BOOM cores first).
The reason this is needed is because by default the ``WithN...Cores(X)`` mixin assumes that there are only BOOM or only Rocket cores in the system.
Thus, without the ``WithRenumberHarts`` mixin, each set of cores is labeled starting from zero causing multiple cores to be assigned the same ``hartId``.
The ``WithRenumberHarts`` config fragment solves this by assigning a unique ``hartId`` to all cores in the system (it can label the Rocket cores first or the BOOM cores first).
The reason this is needed is because by default the ``WithN...Cores(X)`` config fragment assumes that there are only BOOM or only Rocket cores in the system.
Thus, without the ``WithRenumberHarts`` config fragment, each set of cores is labeled starting from zero causing multiple cores to be assigned the same ``hartId``.
Another alternative option to create a multi heterogeneous core system is to override the parameters yourself so you can specify the core parameters per core.
The mixin to add to your system would look something like the following.
The config fragment to add to your system would look something like the following.
.. code-block:: scala
@@ -40,23 +40,22 @@ The mixin to add to your system would look something like the following.
val boomTile1 = BoomTileParams(...) // params for boom core 1
val boomTile2 = BoomTileParams(...) // params for boom core 2
val boomTile3 = BoomTileParams(...) // params for boom core 3
boomTile0 ++ boomTile1 ++ boomTile2 ++ boomTile3
Seq(boomTile0, boomTile1, boomTile2, boomTile3)
}
case RocketTilesKey => {
val rocketTile0 = RocketTileParams(...) // params for rocket core 0
val rocketTile1 = RocketTileParams(...) // params for rocket core 1
rocketTile0 ++ rocketTile1
Seq(rocketTile0, rocketTile1)
}
})
Then you could use this new mixin like the following.
Then you could use this new config fragment like the following.
.. code-block:: scala
class SixCoreConfig extends Config(
new WithTSI ++
new WithNoGPIO ++
new WithBootROM ++
new WithUART ++
new freechips.rocketchip.subsystem.WithNoMMIOPort ++
@@ -72,7 +71,7 @@ Adding Hwachas
Adding a Hwacha accelerator is as easy as adding the ``DefaultHwachaConfig`` so that it can setup the Hwacha parameters and add itself to the ``BuildRoCC`` parameter.
An example of adding a Hwacha to all tiles in the system is below.
.. literalinclude:: ../../generators/example/src/main/scala/HeteroConfigs.scala
.. literalinclude:: ../../generators/chipyard/src/main/scala/config/HeteroConfigs.scala
:language: scala
:start-after: DOC include start: BoomAndRocketWithHwacha
:end-before: DOC include end: BoomAndRocketWithHwacha
@@ -83,24 +82,24 @@ All with the same Hwacha parameters.
Assigning Accelerators to Specific Tiles with MultiRoCC
-------------------------------------------------------
Located in ``generators/example/src/main/scala/ConfigMixins.scala`` is a mixin that provides support for adding RoCC accelerators to specific tiles in your SoC.
Located in ``generators/chipyard/src/main/scala/ConfigFragments.scala`` is a config fragment that provides support for adding RoCC accelerators to specific tiles in your SoC.
Named ``MultiRoCCKey``, this key allows you to attach RoCC accelerators based on the ``hartId`` of the tile.
For example, using this allows you to create a 8 tile system with a RoCC accelerator on only a subset of the tiles.
An example is shown below with two BOOM cores, and one Rocket tile with a RoCC accelerator (Hwacha) attached.
.. literalinclude:: ../../generators/example/src/main/scala/HeteroConfigs.scala
.. literalinclude:: ../../generators/chipyard/src/main/scala/config/HeteroConfigs.scala
:language: scala
:start-after: DOC include start: DualBoomAndRocketOneHwacha
:end-before: DOC include end: DualBoomAndRocketOneHwacha
In this example, the ``WithRenumberHarts`` relabels the ``hartId``'s of all the BOOM/Rocket cores.
Then after that is applied to the parameters, the ``WithMultiRoCCHwacha`` mixin assigns a Hwacha accelerator to a particular ``hartId`` (in this case, the ``hartId`` of ``2`` corresponds to the Rocket core).
Finally, the ``WithMultiRoCC`` mixin is called.
This mixin sets the ``BuildRoCC`` key to use the ``MultiRoCCKey`` instead of the default.
Then after that is applied to the parameters, the ``WithMultiRoCCHwacha`` config fragment assigns a Hwacha accelerator to a particular ``hartId`` (in this case, the ``hartId`` of ``2`` corresponds to the Rocket core).
Finally, the ``WithMultiRoCC`` config fragment is called.
This config fragment sets the ``BuildRoCC`` key to use the ``MultiRoCCKey`` instead of the default.
This must be used after all the RoCC parameters are set because it needs to override the ``BuildRoCC`` parameter.
If this is used earlier in the configuration sequence, then MultiRoCC does not work.
This mixin can be changed to put more accelerators on more cores by changing the arguments to cover more ``hartId``'s (i.e. ``WithMultiRoCCHwacha(0,1,3,6,...)``).
This config fragment can be changed to put more accelerators on more cores by changing the arguments to cover more ``hartId``'s (i.e. ``WithMultiRoCCHwacha(0,1,3,6,...)``).
.. [1] Note, in this section "core" and "tile" are used interchangeably but there is subtle distinction between a "core" and "tile" ("tile" contains a "core", L1D/I$, PTW).

41
docs/Customization/IOBinders.rst Normal file
View File

@@ -0,0 +1,41 @@
IOBinders
=========
In Chipyard we use a special ``Parameters`` key, ``IOBinders`` to instantiate IO cells in the ``ChipTop`` layer and determine what modules to bind to the IOs of a ``ChipTop`` in the ``TestHarness``.
.. literalinclude:: ../../generators/chipyard/src/main/scala/IOBinders.scala
:language: scala
:start-after: DOC include start: IOBinders
:end-before: DOC include end: IOBinders
This special key solves the problem of duplicating test-harnesses for each different ``System`` type.
You could just as well create a custom harness module that attaches IOs explicitly.
Instead, the ``IOBinders`` key provides a map from Scala traits to attachment behaviors.
Each ``IOBinder`` returns a tuple of three values: the list of ``ChipTop`` ports created by the ``IOBinder``, the list of all IO cell modules instantiated by the ``IOBinder``, and an optional function to be called inside the test harness.
This function is responsible for instantiating logic inside the ``TestHarness`` to appropriately drive the ``ChipTop`` IO ports created by the ``IOBinder``.
Conveniently, because the ``IOBinder`` is generating the port, it may also use the port inside this function, which prevents the ``BaseChipTop`` code from ever needing to access the port ``val``, thus having the ``IOBinder`` house all port specific code.
This scheme prevents the need to have two separate binder functions for each ``System`` trait.
When creating custom ``IOBinders`` it is important to use ``suggestName`` to name ports; otherwise Chisel will raise an exception trying to name the IOs.
The example ``IOBinders`` demonstrate this.
As an example, the ``WithGPIOTiedOff`` IOBinder creates IO cells for the GPIO module(s) instantiated in the ``System``, then punches out new ``Analog`` ports for each one.
The test harness simply ties these off, but additional logic could be inserted to perform some kind of test in the ``TestHarness``.
.. literalinclude:: ../../generators/chipyard/src/main/scala/IOBinders.scala
:language: scala
:start-after: DOC include start: WithGPIOTiedOff
:end-before: DOC include end: WithGPIOTiedOff
``IOBinders`` also do not need to create ports. Some ``IOBinders`` can simply insert circuitry inside the ``ChipTop`` layer.
For example, the ``WithSimAXIMemTiedOff`` IOBinder specifies that any ``System`` which matches ``CanHaveMasterAXI4MemPortModuleImp`` will have a ``SimAXIMem`` connected inside ``ChipTop``.
.. literalinclude:: ../../generators/chipyard/src/main/scala/IOBinders.scala
:language: scala
:start-after: DOC include start: WithSimAXIMem
:end-before: DOC include end: WithSimAXIMem
These classes are all ``Config`` objects, which can be mixed into the configs to specify IO connection behaviors.
There are two macros for generating these ``Config``s. ``OverrideIOBinder`` overrides any existing behaviors set for a particular IO in the ``Config`` object. This macro is frequently used because typically top-level IOs drive or are driven by only one source, so a composition of ``IOBinders`` does not make sense. The ``ComposeIOBinder`` macro provides the functionality of not overriding existing behaviors.

15
docs/Customization/Incorporating-Verilog-Blocks.rst
View File

@@ -48,16 +48,17 @@ Verilog files into the build process, which are part of the
.settings(commonSettings)
For this concrete GCD example, we will be using a ``GCDMMIOBlackBox``
Verilog module that is defined in the ``example`` project. The Scala
Verilog module that is defined in the ``chipyard`` project. The Scala
and Verilog sources follow the prescribed directory layout.
.. code-block:: none
generators/example/
generators/chipyard/
build.sbt
src/main/
scala/
GCD.scala
example/
GCD.scala
resources/
vsrc/
GCDMMIOBlackBox.v
@@ -81,14 +82,14 @@ as the bitwidth of the GCD calculation does in this example.
**Verilog GCD port list and parameters**
.. literalinclude:: ../../generators/example/src/main/resources/vsrc/GCDMMIOBlackBox.v
.. literalinclude:: ../../generators/chipyard/src/main/resources/vsrc/GCDMMIOBlackBox.v
:language: Verilog
:start-after: DOC include start: GCD portlist
:end-before: DOC include end: GCD portlist
**Chisel BlackBox Definition**
.. literalinclude:: ../../generators/example/src/main/scala/GCD.scala
.. literalinclude:: ../../generators/chipyard/src/main/scala/example/GCD.scala
:language: scala
:start-after: DOC include start: GCD blackbox
:end-before: DOC include end: GCD blackbox
@@ -103,7 +104,7 @@ peripheral-specific traits into a ``TLRegisterRouter``. The ``params``
member and ``HasRegMap`` base trait should look familiar from the
previous memory-mapped GCD device example.
.. literalinclude:: ../../generators/example/src/main/scala/GCD.scala
.. literalinclude:: ../../generators/chipyard/src/main/scala/example/GCD.scala
:language: scala
:start-after: DOC include start: GCD instance regmap
:end-before: DOC include end: GCD instance regmap
@@ -115,7 +116,7 @@ Defining a Chip with a BlackBox
Since we've parameterized the GCD instantiation to choose between the
Chisel and the Verilog module, creating a config is easy.
.. literalinclude:: ../../generators/example/src/main/scala/RocketConfigs.scala
.. literalinclude:: ../../generators/chipyard/src/main/scala/config/RocketConfigs.scala
:language: scala
:start-after: DOC include start: GCDAXI4BlackBoxRocketConfig
:end-before: DOC include end: GCDAXI4BlackBoxRocketConfig

69
docs/Customization/Keys-Traits-Configs.rst
View File

@@ -3,7 +3,7 @@
Keys, Traits, and Configs
=========================
You have probably seen snippets of Chisel referencing Keys, Traits, and Configs by this point.
You have probably seen snippets of Chisel referencing keys, traits, and configs by this point.
This section aims to elucidate the interactions between these Chisel/Scala components, and provide
best practices for how these should be used to create a parameterized design and configure it.
@@ -16,7 +16,7 @@ Keys specify some parameter which controls some custom widget. Keys should typic
Keys should be defined and documented in sub-projects, since they generally deal with some specific block, and not system-level integration. (We make an exception for the example GCD widget).
.. literalinclude:: ../../generators/example/src/main/scala/GCD.scala
.. literalinclude:: ../../generators/chipyard/src/main/scala/example/GCD.scala
:language: scala
:start-after: DOC include start: GCD key
:end-before: DOC include end: GCD key
@@ -24,7 +24,7 @@ Keys should be defined and documented in sub-projects, since they generally deal
The object within a key is typically a ``case class XXXParams``, which defines a set of parameters which some block accepts. For example, the GCD widget's ``GCDParams`` parameterizes its address, operand widths, whether the widget should be connected by Tilelink or AXI4, and whether the widget should use the blackbox-Verilog implementation, or the Chisel implementation.
.. literalinclude:: ../../generators/example/src/main/scala/GCD.scala
.. literalinclude:: ../../generators/chipyard/src/main/scala/example/GCD.scala
:language: scala
:start-after: DOC include start: GCD params
:end-before: DOC include end: GCD params
@@ -34,72 +34,45 @@ Accessing the value stored in the key is easy in Chisel, as long as the ``implic
Traits
------
Typically, most custom blocks will need to modify the behavior of some pre-existing block. For example, the GCD widget needs the ``Top`` module to instantiate and connect the widget via Tilelink, generate a top-level ``gcd_busy`` port, and connect that to the module as well. Traits let us do this without modifying the existing code for the ``Top``, and enables compartmentalization of code for different custom blocks.
Typically, most custom blocks will need to modify the behavior of some pre-existing block. For example, the GCD widget needs the ``DigitalTop`` module to instantiate and connect the widget via Tilelink, generate a top-level ``gcd_busy`` port, and connect that to the module as well. Traits let us do this without modifying the existing code for the ``DigitalTop``, and enables compartmentalization of code for different custom blocks.
Top-level traits specify that the ``Top`` has been parameterized to read some custom Key and optionally instantiate and connect a widget defined by that Key. Traits **should not** mandate the instantiation of custom logic. In other words, traits should be written with ``CanHave`` semantics, where the default behavior when the Key is unset is a no-op.
Top-level traits specify that the ``DigitalTop`` has been parameterized to read some custom key and optionally instantiate and connect a widget defined by that key. Traits **should not** mandate the instantiation of custom logic. In other words, traits should be written with ``CanHave`` semantics, where the default behavior when the key is unset is a no-op.
Top-level traits should be defined and documented in subprojects, alongside their corresponding Keys. The traits should then be added to the ``Top`` being used by Chipyard.
Top-level traits should be defined and documented in subprojects, alongside their corresponding keys. The traits should then be added to the ``DigitalTop`` being used by Chipyard.
Below we see the traits for the GCD example. The Lazy trait connects the GCD module to the Diplomacy graph, while the Implementation trait causes the ``Top`` to instantiate an additional port and concretely connect it to the GCD module.
Below we see the traits for the GCD example. The Lazy trait connects the GCD module to the Diplomacy graph, while the Implementation trait causes the ``DigitalTop`` to instantiate an additional port and concretely connect it to the GCD module.
.. literalinclude:: ../../generators/example/src/main/scala/GCD.scala
.. literalinclude:: ../../generators/chipyard/src/main/scala/example/GCD.scala
:language: scala
:start-after: DOC include start: GCD lazy trait
:end-before: DOC include end: GCD imp trait
These traits are added to the default ``Top`` in Chipyard.
These traits are added to the default ``DigitalTop`` in Chipyard.
.. literalinclude:: ../../generators/example/src/main/scala/Top.scala
.. literalinclude:: ../../generators/chipyard/src/main/scala/DigitalTop.scala
:language: scala
:start-after: DOC include start: Top
:end-before: DOC include end: Top
:start-after: DOC include start: DigitalTop
:end-before: DOC include end: DigitalTop
Mixins
------
Config Fragments
----------------
Mixins set the keys to a non-default value. Together, the collection of Mixins which define a configuration generate the values for all the keys used by the generator.
Config fragments set the keys to a non-default value. Together, the collection of config fragments which define a configuration generate the values for all the keys used by the generator.
For example, the ``WithGCDMixin`` is parameterized by the type of GCD widget you want to instantiate. When this mixin is added to a config, the ``GCDKey`` is set to a instance of ``GCDParams``, informing the previously mentioned traits to instantiate and connect the GCD widget appropriately.
For example, the ``WithGCD`` config fragment is parameterized by the type of GCD widget you want to instantiate. When this config fragment is added to a config, the ``GCDKey`` is set to a instance of ``GCDParams``, informing the previously mentioned traits to instantiate and connect the GCD widget appropriately.
.. literalinclude:: ../../generators/example/src/main/scala/ConfigMixins.scala
.. literalinclude:: ../../generators/chipyard/src/main/scala/example/GCD.scala
:language: scala
:start-after: DOC include start: GCD mixin
:end-before: DOC include end: GCD mixin
:start-after: DOC include start: GCD config fragment
:end-before: DOC include end: GCD config fragment
We can use this mixin when composing our configs.
We can use this config fragment when composing our configs.
.. literalinclude:: ../../generators/example/src/main/scala/RocketConfigs.scala
.. literalinclude:: ../../generators/chipyard/src/main/scala/config/RocketConfigs.scala
:language: scala
:start-after: DOC include start: GCDTLRocketConfig
:end-before: DOC include end: GCDTLRocketConfig
BuildTop
--------
The ``BuildTop`` key is special, because sometimes, we need to instantiate ``TestHarness`` modules to interface with a custom widget. The ``BuildTop`` key provides a function which can call some method of the Top to instantiate these ``TestHarness`` modules. Since the ``BuildTop`` key is called from the ``TestHarness``, these modules will appear in the ``TestHarness``. The config system also lets the ``BuildTop`` key look recursively into previous definitions of itself. This enables composability of the ``Top`` configurations.
For example, conside a config that contains the mixins ``WithGPIO ++ WithTSI``. We need to instantiate the TSI serial adapter, and connect it to the ``success`` signal of our ``TestHarness``. We also need to instantiate the GPIO pins, and tie their inputs to 0 in the ``TestHarness``, since we currently cannot drive the GPIOs in simulation.
.. literalinclude:: ../../generators/example/src/main/scala/ConfigMixins.scala
:language: scala
:start-after: DOC include start: tsi mixin
:end-before: DOC include end: tsi mixin
.. literalinclude:: ../../generators/example/src/main/scala/ConfigMixins.scala
:language: scala
:start-after: DOC include start: gpio mixin
:end-before: DOC include end: gpio mixin
When ``WithGPIO ++ WithTSI`` is evaluated right to left, the call to ``up(BuildTop, site)`` in ``WithGPIO`` will reference the function defined in the ``BuildTop`` key of ``WithTSI``. Thus, at elaboration time, when the ``BuildTop`` function is called by the ``TestHarness``, first the ``BuildTop`` function in ``WithTSI`` will be evaluated. This connects the ``success`` signal of the ``TestHarness`` to the ``SerialAdapter`` enabled by ``WithTSI``. Then, the rest of the code in the ``BuildTop`` function of ``WithGPIO`` will execute, tieing off the top-level GPIO input pins. Thus the evaluation of the ``BuildTop`` functions in a completed config is "right-to-left", matching how the evaluation of the mixins at compile-time is also "right-to-left".
.. warning::
In some cases, the ordering and duplication of mixins which extend ``BuildTop`` will have unintended consequences.
For example, ``WithTSI ++ WithTSI`` will attempt to generate and connect two ``SimSerial`` widgets in the ``TestHarness``,
which will likely break the simulation.
In general, you should avoid attaching multiple mixins which interface to the same top-level ports.
.. note::
Readers who want more information on the configuration system may be interested in reading :ref:`cdes`.

42
docs/Customization/MMIO-Peripherals.rst
View File

@@ -3,21 +3,21 @@
MMIO Peripherals
==================
The easiest way to create a MMIO peripheral is to use the ``TLRegisterRouter`` or ``AXI4RegisterRouter`` widgets, which abstracts away the details of handling the interconnect protocols and provides a convenient interface for specifying memory-mapped registers. Since Chipyard and Rocket Chip SoCs primarily use Tilelink as the on-chip interconnect protocol, this section will primarily focus on designing Tilelink-based peripherals. However, see ``generators/example/src/main/scala/GCD.scala`` for how an example AXI4 based peripheral is defined and connected to the Tilelink graph through converters.
The easiest way to create a MMIO peripheral is to use the ``TLRegisterRouter`` or ``AXI4RegisterRouter`` widgets, which abstracts away the details of handling the interconnect protocols and provides a convenient interface for specifying memory-mapped registers. Since Chipyard and Rocket Chip SoCs primarily use Tilelink as the on-chip interconnect protocol, this section will primarily focus on designing Tilelink-based peripherals. However, see ``generators/chipyard/src/main/scala/example/GCD.scala`` for how an example AXI4 based peripheral is defined and connected to the Tilelink graph through converters.
To create a RegisterRouter-based peripheral, you will need to specify a parameter case class for the configuration settings, a bundle trait with the extra top-level ports, and a module implementation containing the actual RTL.
For this example, we will show how to connect a MMIO peripheral which computes the GCD.
The full code can be found in ``generators/example/src/main/scala/GCD.scala``.
The full code can be found in ``generators/chipyard/src/main/scala/example/GCD.scala``.
In this case we use a submodule ``GCDMMIOChiselModule`` to actually perform the GCD. The ``GCDModule`` class only creates the registers and hooks them up using ``regmap``.
.. literalinclude:: ../../generators/example/src/main/scala/GCD.scala
.. literalinclude:: ../../generators/chipyard/src/main/scala/example/GCD.scala
:language: scala
:start-after: DOC include start: GCD chisel
:end-before: DOC include end: GCD chisel
.. literalinclude:: ../../generators/example/src/main/scala/GCD.scala
.. literalinclude:: ../../generators/chipyard/src/main/scala/example/GCD.scala
:language: scala
:start-after: DOC include start: GCD instance regmap
:end-before: DOC include end: GCD instance regmap
@@ -51,7 +51,7 @@ The second set of arguments is the IO bundle constructor, which we create by ext
The final set of arguments is the module constructor, which we create by extends ``TLRegModule`` with our module trait.
Notice how we can create an analogous AXI4 version of our peripheral.
.. literalinclude:: ../../generators/example/src/main/scala/GCD.scala
.. literalinclude:: ../../generators/chipyard/src/main/scala/example/GCD.scala
:language: scala
:start-after: DOC include start: GCD router
:end-before: DOC include end: GCD router
@@ -69,7 +69,7 @@ In the Rocket Chip cake, there are two kinds of traits: a ``LazyModule`` trait a
The ``LazyModule`` trait runs setup code that must execute before all the hardware gets elaborated.
For a simple memory-mapped peripheral, this just involves connecting the peripheral's TileLink node to the MMIO crossbar.
.. literalinclude:: ../../generators/example/src/main/scala/GCD.scala
.. literalinclude:: ../../generators/chipyard/src/main/scala/example/GCD.scala
:language: scala
:start-after: DOC include start: GCD lazy trait
:end-before: DOC include end: GCD lazy trait
@@ -82,37 +82,37 @@ Also observe how we have to place additional AXI4 buffers and converters for the
For peripherals which instantiate a concrete module, or which need to be connected to concrete IOs or wires, a matching concrete trait is necessary. We will make our GCD example output a ``gcd_busy`` signal as a top-level port to demonstrate. In the concrete module implementation trait, we instantiate the top level IO (a concrete object) and wire it to the IO of our lazy module.
.. literalinclude:: ../../generators/example/src/main/scala/GCD.scala
.. literalinclude:: ../../generators/chipyard/src/main/scala/example/GCD.scala
:language: scala
:start-after: DOC include start: GCD imp trait
:end-before: DOC include end: GCD imp trait
Constructing the Top and Config
-------------------------------
Constructing the DigitalTop and Config
--------------------------------------
Now we want to mix our traits into the system as a whole.
This code is from ``generators/example/src/main/scala/Top.scala``.
This code is from ``generators/chipyard/src/main/scala/DigitalTop.scala``.
.. literalinclude:: ../../generators/example/src/main/scala/Top.scala
.. literalinclude:: ../../generators/chipyard/src/main/scala/DigitalTop.scala
:language: scala
:start-after: DOC include start: Top
:end-before: DOC include end: Top
:start-after: DOC include start: DigitalTop
:end-before: DOC include end: DigitalTop
Just as we need separate traits for ``LazyModule`` and module implementation, we need two classes to build the system.
The ``Top`` class contains the set of traits which parameterize and define the ``Top``. Typically these traits will optionally add IOs or peripherals to the ``Top``.
The ``Top`` class includes the pre-elaboration code and also a ``lazy val`` to produce the module implementation (hence ``LazyModule``).
The ``TopModule`` class is the actual RTL that gets synthesized.
The ``DigitalTop`` class contains the set of traits which parameterize and define the ``DigitalTop``. Typically these traits will optionally add IOs or peripherals to the ``DigitalTop``.
The ``DigitalTop`` class includes the pre-elaboration code and also a ``lazy val`` to produce the module implementation (hence ``LazyModule``).
The ``DigitalTopModule`` class is the actual RTL that gets synthesized.
And finally, we create a configuration class in ``generators/example/src/main/scala/Configs.scala`` that uses the ``WithGCD`` mixin defined earlier.
And finally, we create a configuration class in ``generators/chipyard/src/main/scala/config/RocketConfigs.scala`` that uses the ``WithGCD`` config fragment defined earlier.
.. literalinclude:: ../../generators/example/src/main/scala/ConfigMixins.scala
.. literalinclude:: ../../generators/chipyard/src/main/scala/example/GCD.scala
:language: scala
:start-after: DOC include start: GCD mixin
:end-before: DOC include end: GCD mixin
:start-after: DOC include start: GCD config fragment
:end-before: DOC include end: GCD config fragment
.. literalinclude:: ../../generators/example/src/main/scala/RocketConfigs.scala
.. literalinclude:: ../../generators/chipyard/src/main/scala/config/RocketConfigs.scala
:language: scala
:start-after: DOC include start: GCDTLRocketConfig
:end-before: DOC include end: GCDTLRocketConfig

137
docs/Customization/Memory-Hierarchy.rst
View File

@@ -9,106 +9,61 @@ The L1 Caches
Each CPU tile has an L1 instruction cache and L1 data cache. The size and
associativity of these caches can be configured. The default ``RocketConfig``
uses 16 KiB, 4-way set-associative instruction and data caches. However,
if you use the ``NMedCores`` or ``NSmallCores`` configurations, you can
if you use the ``WithNMedCores`` or ``WithNSmallCores`` configurations, you can
configure 4 KiB direct-mapped caches for L1I and L1D.
.. code-block:: scala
class SmallRocketConfig extends Config(
new WithTSI ++
new WithNoGPIO ++
new WithBootROM ++
new WithUART ++
new freechips.rocketchip.subsystem.WithNoMMIOPort ++
new freechips.rocketchip.subsystem.WithNoSlavePort ++
new freechips.rocketchip.subsystem.WithNSmallCores(1) ++ // small rocket cores
new freechips.rocketchip.system.BaseConfig)
class MediumRocketConfig extends Config(
new WithTSI ++
new WithNoGPIO ++
new WithBootROM ++
new WithUART ++
new freechips.rocketchip.subsystem.WithNoMMIOPort ++
new freechips.rocketchip.subsystem.WithNoSlavePort ++
new freechips.rocketchip.subsystem.WithNMedCores(1) ++ // medium rocket cores
new freechips.rocketchip.system.BaseConfig)
If you only want to change the size or associativity, there are configuration
mixins for those too.
If you only want to change the size or associativity, there are config
fragments for those too. See :ref:`Config Fragments` for how to add these to a custom ``Config``.
.. code-block:: scala
import freechips.rocketchip.subsystem.{WithL1ICacheSets, WithL1DCacheSets, WithL1ICacheWays, WithL1DCacheWays}
new freechips.rocketchip.subsystem.WithL1ICacheSets(128) ++ // change rocket I$
new freechips.rocketchip.subsystem.WithL1ICacheWays(2) ++ // change rocket I$
new freechips.rocketchip.subsystem.WithL1DCacheSets(128) ++ // change rocket D$
new freechips.rocketchip.subsystem.WithL1DCacheWays(2) ++ // change rocket D$
class MyL1RocketConfig extends Config(
new WithTSI ++
new WithNoGPIO ++
new WithBootROM ++
new WithUART ++
new freechips.rocketchip.subsystem.WithNoMMIOPort ++
new freechips.rocketchip.subsystem.WithNoSlavePort ++
new WithL1ICacheSets(128) ++ // change rocket I$
new WithL1ICacheWays(2) ++ // change rocket I$
new WithL1DCacheSets(128) ++ // change rocket D$
new WithL1DCacheWays(2) ++ // change rocket D$
new freechips.rocketchip.subsystem.WithNSmallCores(1) ++
new freechips.rocketchip.system.BaseConfig)
You can also configure the L1 data cache as an data scratchpad instead.
However, there are some limitations on this. If you are using a data scratchpad,
you can only use a single core and you cannot give the design an external DRAM.
Note that these configurations fully remove the L2 cache and mbus.
.. code-block:: scala
class SmallRocketConfigNoL2 extends Config(
new WithTSI ++
new WithNoGPIO ++
new WithBootROM ++
new WithUART ++
new freechips.rocketchip.subsystem.WithNoMMIOPort ++
new freechips.rocketchip.subsystem.WithNoSlavePort ++
new freechips.rocketchip.subsystem.WithNSmallCores(1) ++
new freechips.rocketchip.system.BaseConfig)
.. literalinclude:: ../../generators/chipyard/src/main/scala/config/RocketConfigs.scala
:language: scala
:start-after: DOC include start: scratchpadrocket
:end-before: DOC include end: scratchpadrocket
class ScratchpadRocketConfig extends Config(
new freechips.rocketchip.subsystem.WithNoMemPort ++
new freechips.rocketchip.subsystem.WithNMemoryChannels(0) ++
new freechips.rocketchip.subsystem.WithNBanks(0) ++
new freechips.rocketchip.subsystem.WithScratchpadsOnly ++
new SmallRocketConfigNoL2)
This configuration fully removes the L2 cache and memory bus by setting the
number of channels and number of banks to 0.
The System Bus
--------------
The system bus is the TileLink network that sits between the tiles and the L2
agents and MMIO peripherals. Ordinarily, it is a fully-connected crossbar,
but TestChipIP provides a version that uses a ring network instead. This can
be useful when taping out larger systems. To use the ring network system
bus, simply add the ``WithRingSystemBus`` config fragment to your configuration.
.. literalinclude:: ../../generators/chipyard/src/main/scala/config/RocketConfigs.scala
:language: scala
:start-after: DOC include start: RingSystemBusRocket
:end-before: DOC include end: RingSystemBusRocket
The SiFive L2 Cache
-------------------
The default RocketConfig provided in the Chipyard example project uses SiFive's
The default ``RocketConfig`` provided in the Chipyard example project uses SiFive's
InclusiveCache generator to produce a shared L2 cache. In the default
configuration, the L2 uses a single cache bank with 512 KiB capacity and 8-way
set-associativity. However, you can change these parameters to obtain your
desired cache configuration. The main restriction is that the number of ways
and the number of banks must be powers of 2.
.. code-block:: scala
import freechips.rocketchip.subsystem.WithInclusiveCache
class MyCacheRocketConfig extends Config(
new WithTSI ++
new WithNoGPIO ++
new WithBootROM ++
new WithUART ++
new freechips.rocketchip.subsystem.WithNoMMIOPort ++
new freechips.rocketchip.subsystem.WithNoSlavePort ++
new WithInclusiveCache( // add 1MB, 4-way, 4-bank cache
capacityKB = 1024,
nWays = 4,
nBanks = 4) ++
new freechips.rocketchip.subsystem.WithNSmallCores(1) ++
new freechips.rocketchip.system.BaseConfig)
Refer to the ``CacheParameters`` object defined in sifive-cache for
customization options.
The Broadcast Hub
-----------------
@@ -117,31 +72,13 @@ If you do not want to use the L2 cache (say, for a resource-limited embedded
design), you can create a configuration without it. Instead of using the L2
cache, you will instead use RocketChip's TileLink broadcast hub.
To make such a configuration, you can just copy the definition of
``RocketConfig`` but omit the ``WithInclusiveCache`` mixin from the
``RocketConfig`` but omit the ``WithInclusiveCache`` config fragment from the
list of included mixims.
.. code-block:: scala
class CachelessRocketConfig extends Config(
new WithTSI ++
new WithNoGPIO ++
new WithBootROM ++
new WithUART ++
new freechips.rocketchip.subsystem.WithNoMMIOPort ++
new freechips.rocketchip.subsystem.WithNoSlavePort ++
new freechips.rocketchip.subsystem.WithNBigCores(1) ++
new freechips.rocketchip.system.BaseConfig)
If you want to reduce the resources used even further, you can configure
the Broadcast Hub to use a bufferless design.
the Broadcast Hub to use a bufferless design. This config fragment is
``freechips.rocketchip.subsystem.WithBufferlessBroadcastHub``.
.. code-block:: scala
import freechips.rocketchip.subsystem.WithBufferlessBroadcastHub
class BufferlessRocketConfig extends Config(
new WithBufferlessBroadcastHub ++
new CachelessRocketConfig)
The Outer Memory System
-----------------------
@@ -155,18 +92,8 @@ number of DRAM channels is restricted to powers of two.
.. code-block:: scala
import freechips.rocketchip.subsystem.WithNMemoryChannels
new freechips.rocketchip.subsystem.WithNMemoryChannels(2)
class DualChannelRocketConfig extends Config(
new WithTSI ++
new WithNoGPIO ++
new WithBootROM ++
new WithUART ++
new freechips.rocketchip.subsystem.WithNoMMIOPort ++
new freechips.rocketchip.subsystem.WithNoSlavePort ++
new WithNMemoryChannels(2) ++ // multi-channel outer mem
new freechips.rocketchip.subsystem.WithNBigCores(1) ++
new freechips.rocketchip.system.BaseConfig)
In VCS and Verilator simulation, the DRAM is simulated using the
``SimAXIMem`` module, which simply attaches a single-cycle SRAM to each

2
docs/Customization/RoCC-Accelerators.rst
View File

@@ -45,7 +45,7 @@ The other interfaces available to the accelerator are ``mem``, which provides ac
the ``busy`` signal, which indicates when the accelerator is still handling an instruction;
and the ``interrupt`` signal, which can be used to interrupt the CPU.
Look at the examples in ``generators/rocket-chip/src/main/scala/tile/LazyRocc.scala`` for detailed information on the different IOs.
Look at the examples in ``generators/rocket-chip/src/main/scala/tile/LazyRoCC.scala`` for detailed information on the different IOs.
Adding RoCC accelerator to Config
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

3
docs/Customization/index.rst
View File

@@ -11,7 +11,7 @@ These guides will walk you through customization of your system-on-chip:
- Adding custom MMIO widgets to the Chipyard memory system by Tilelink or AXI4, with custom Top-level IOs
- Standard practices for using Keys, Traits, and Configs to parameterize your design
- Standard practices for using keys, traits, and configs to parameterize your design
- Customizing the memory hierarchy
@@ -42,3 +42,4 @@ We recommend reading all these pages in order. Hit next to get started!
Memory-Hierarchy
Boot-Process
Firrtl-Transforms
IOBinders

14
docs/Generators/Ariane.rst Normal file
View File

@@ -0,0 +1,14 @@
Ariane Core
====================================
`Ariane <https://github.com/pulp-platform/ariane>`__ is a 6-stage in-order scalar processor core, originally developed at ETH-Zurich by F. Zaruba and L. Benini.
The `Ariane core` is wrapped in an `Ariane tile` so it can be used as a component within the `Rocket Chip SoC generator`.
The core by itself exposes an AXI interface, interrupt ports, and other misc. ports that are connected from within the tile to TileLink buses and other parameterization signals.
.. Warning:: Since the core uses an AXI interface to connect to memory, it is highly recommended to use the core in a single-core setup (since AXI is a non-coherent memory interface).
While the core itself is not a generator, we expose the same parameterization that the Ariane core provides (i.e. change branch prediction parameters).
.. Warning:: This target does not support Verilator simulation at this time. Please use VCS.
For more information, please refer to the `GitHub repository <https://github.com/pulp-platform/ariane>`__.

16
docs/Generators/Gemmini.rst
View File

@@ -3,13 +3,13 @@ Gemmini
The Gemmini project is developing a systolic-array based matrix multiplication unit generator for the investigation of software/hardware implications of such integrated SoC accelerators. It is inspired by recent trends in machine learning accelerators for edge and mobile SoCs.
Gemmini is implemented as a RoCC accelerator with non-standard RISC-V custom instructions. The Gemmini unit uses the RoCC port of a Rocket or BOOM `tile`, and by default connects to the memory system through the System Bus (i.e., directly to the L2 cache).
Gemmini is implemented as a RoCC accelerator with non-standard RISC-V custom instructions. The Gemmini unit uses the RoCC port of a Rocket or BOOM `tile`, and by default connects to the memory system through the System Bus (i.e., directly to the L2 cache).
To add a Gemmini unit to an SoC, you should add the ``gemmini.DefaultGemminiConfig`` config mixin to the SoC configurations. To change the configuration of the Gemmini accelerator unit, you can write a custom configuration to replace the ``DefaultGemminiConfig``, which you can view under `generators/gemmini/src/main/scala/configs.scala <https://github.com/ucb-bar/gemmini/blob/master/src/main/scala/gemmini/configs.scala>`__ to see the possible configuration parameters.
To add a Gemmini unit to an SoC, you should add the ``gemmini.DefaultGemminiConfig`` config fragment to the SoC configurations. To change the configuration of the Gemmini accelerator unit, you can write a custom configuration to replace the ``DefaultGemminiConfig``, which you can view under `generators/gemmini/src/main/scala/configs.scala <https://github.com/ucb-bar/gemmini/blob/master/src/main/scala/gemmini/configs.scala>`__ to see the possible configuration parameters.
The example Chipyard config includes the following example SoC configuration which includes Gemmini:
.. literalinclude:: ../../generators/example/src/main/scala/RocketConfigs.scala
.. literalinclude:: ../../generators/chipyard/src/main/scala/config/RocketConfigs.scala
:language: scala
:start-after: DOC include start: GemminiRocketConfig
:end-before: DOC include end: GemminiRocketConfig
@@ -42,16 +42,16 @@ Major parameters of interest include:
* DMA parameters (``dma_maxbytes``, ``dma_buswidth``, ``mem_pipeline``): Gemmini implements a DMA to move data from main memory to the Gemmini scratchpad, and from the Gemmini accumulators to main memory. The size of these DMA transactions is determined by the DMA parameters. These DMA parameters are tightly coupled with Rocket Chip SoC system parameters: in particular ``dma_buswidth`` is associated with the ``SystemBusKey`` ``beatBytes`` parameter, and ``dma_maxbytes`` is associated with ``cacheblockbytes`` Rocket Chip parameters.
Software
Gemmini Software
------------------
The Gemmini non-standard ISA extension is specified in the `Gemmini repository <https://github.com/ucb-bar/gemmini/blob/master/README.md>`__.
The ISA includes configuration instructions, data movement instructions (from main memory to the Gemmini scratchpad, and from the Gemmini accumulators to main memory), and matrix multiplication execution instructions.
The ISA includes configuration instructions, data movement instructions (from main memory to the Gemmini scratchpad, and from the Gemmini accumulators to main memory), and matrix multiplication execution instructions.
Since Gemmini instructions are not exposed through the GNU binutils assembler, several C macros are provided in order to construct the instruction encodings to call these instructions.
The Gemmini generator includes a C matrix multiplication library which wraps the calls to the custom Gemmini instructions.
The ``software`` directory of the generator includes the aforementioned library and macros, as well as bare-metal tests, and some FireMarshal workloads to run the tests in a Linux environment. In particular, the matrix multiplication C library can be found in the ``software/gemmini-rocc-tests/include/gemmini.h`` file.
The ``software`` directory of the generator includes the aforementioned library and macros, as well as bare-metal tests, and some FireMarshal workloads to run the tests in a Linux environment. In particular, the matrix multiplication C library can be found in the ``software/gemmini-rocc-tests/include/gemmini.h`` file.
The Gemmini generator generates a C header file based on the generator parameters. This header files gets compiled together with the matrix multiplication library to tune library performance. The generated header file can be found under ``software/gemmini-rocc-tests/include/gemmini_params.h``
@@ -64,7 +64,7 @@ To build Gemmini tests:
cd generators/gemmini/software/gemmini-rocc-tests/
./build.sh
Afterwards, the test binaries will be found in ``generators/gemmini/software/gemmini-rocc-tests/build``. Binaries whose names end in ``-baremetal`` are meant to be run in a bare-metal environment, while binaries whose names end in ``-linux`` are meant to run in a Linux environment. You can run the tests either on a cycle-accurate RTL simulator, or on a (much faster) functional ISA simulator called Spike.
The Gemmini generator implements a custom non-standard version of Spike. This implementation is found within the ``esp-tools`` Spike implementation, together with the Hwacha vector accelerator non-standard ISA-extension. In order to use this version of Spike, please make sure to build the ``esp-tools`` software toolchain, as described in :ref:`build-toolchains`.
@@ -80,7 +80,7 @@ Spike is built by default without a commit log. However, if you would like to ad
Alternative SoC Configs
--------------------------
The Gemmini generator includes additional alternative SoC configs (configs that are not in the Chipyard example project).
The Gemmini generator includes additional alternative SoC configs (configs that are not in the Chipyard example project).
If you would like to build one of these alternative SoC configurations which are defined in within the Gemmini project repository, you can run the following commands. These commands are similar to the one required when building a simulation from the example project, but they specify that the location of the configs are in the Gemmini subproject, as opposed to the Chipyard example project:
.. code-block:: shell

4
docs/Generators/Hwacha.rst
View File

@@ -7,9 +7,9 @@ The Hwacha project includes the Hwacha microarchitecture generator, as well as t
For more information on the Hwacha project, please visit the `Hwacha website <http://hwacha.org/>`__.
To add the Hwacha vector unit to an SoC, you should add the ``hwacha.DefaultHwachaConfig`` config mixin to the SoC configurations. The Hwacha vector unit uses the RoCC port of a Rocket or BOOM `tile`, and by default connects to the memory system through the `System Bus` (i.e., directly to the L2 cache).
To add the Hwacha vector unit to an SoC, you should add the ``hwacha.DefaultHwachaConfig`` config fragment to the SoC configurations. The Hwacha vector unit uses the RoCC port of a Rocket or BOOM `tile`, and by default connects to the memory system through the `System Bus` (i.e., directly to the L2 cache).
To change the configuration of the Hwacha vector unit, you can write a custom configuration to replace the ``DefaultHwachaConfig``. You can view the ``DefaultHwachaConfig`` under `generators/hwacha/src/main/scala/configs.scala <https://github.com/ucb-bar/hwacha/blob/master/src/main/scala/configs.scala>`__ to see the possible configuration parameters.
Since Hwacha implements a non-standard RISC-V extension, it requires a unique software toolchain to be able to compile and assemble its vector instructions.
To install the Hwacha toolchain, run the ``./scripts/build-toolchains.sh esp-tools`` command within the root Chipyard directory. This may take a while, and it will install the ``esp-tools-install`` directory within your Chipyard root directory. ``esp-tools`` is a fork of ``riscv-tools`` (formerly a collection of relevant software RISC-V tools) that was enhanced with additional non-standard vector instructions. However, due to the upstreaming of the equivalent RISC-V toolchains, ``esp-tools`` may not be up-to-date with the latest mainline version of the tools included in it.

8
docs/Generators/IceNet.rst
View File

@@ -8,7 +8,7 @@ A diagram of IceNet's microarchitecture is shown below.
.. image:: ../_static/images/nic-design.png
There are four basic parts of the NIC: the :ref:`Controller`, which takes requests
There are four basic parts of the NIC: the :ref:`Controller`, which takes requests
from and sends responses to the CPU; the :ref:`Send Path`, which reads data from
memory and sends it out to the network; the :ref:`Receive Path`, which receives
data from the network and writes it to memory; and, optionally,
@@ -78,10 +78,10 @@ Configuration
To add IceNIC to your design, add ``HasPeripheryIceNIC`` to your lazy module
and ``HasPeripheryIceNICModuleImp`` to the module implementation. If you
are confused about the distinction between lazy module and module
implementation, refer to :ref:`Cake Pattern`.
implementation, refer to :ref:`Cake Pattern / Mixin`.
Then add the ``WithIceNIC`` config mixin to your configuration. This will
define ``NICKey``, which IceNIC uses to determine its parameters. The mixin
Then add the ``WithIceNIC`` config fragment to your configuration. This will
define ``NICKey``, which IceNIC uses to determine its parameters. The config fragment
takes two arguments. The ``inBufFlits`` argument is the number of 64-bit flits
that the input packet buffer can hold and the ``usePauser`` argument determines
whether or not the NIC will have a pause handler.

16
docs/Generators/NVDLA.rst Normal file
View File

@@ -0,0 +1,16 @@
NVDLA
====================================
`NVDLA <http://nvdla.org/>`_ is an open-source deep learning accelerator developed by NVIDIA.
The `NVDLA` is attached as a TileLink peripheral so it can be used as a component within the `Rocket Chip SoC generator`.
The accelerator by itself exposes an AXI memory interface (or two if you use the "Large" configuration), a control interface, and an interrupt line.
The main way to use the accelerator in Chipyard is to use the `NVDLA SW repository <https://github.com/ucb-bar/nvdla-sw>`_ that was ported to work on FireSim Linux.
However, you can also use the accelerator in baremetal simulations (refer to ``tests/nvdla.c``).
For more information on both the HW architecture and the SW, please visit their `website <http://nvdla.org/>`_.
NVDLA Software with FireMarshal
-------------------------------
Located at ``software/nvdla-workload`` is a FireMarshal-based workload to boot Linux with the proper NVDLA drivers.
Refer to that ``README.md`` for more information on how to run a simulation.

7
docs/Generators/Rocket-Chip.rst
View File

@@ -58,8 +58,8 @@ The ``PeripheryBus`` attaches additional peripherals like the NIC and Block Devi
It can also optionally expose an external AXI4 port, which can be attached to
vendor-supplied AXI4 IP.
To learn more about adding MMIO peripherals, check out the :ref:`MMIO Peripheral`
section of :ref:`Adding an Accelerator/Device`.
To learn more about adding MMIO peripherals, check out the :ref:`mmio-accelerators`
section.
DMA
---
@@ -68,5 +68,4 @@ You can also add DMA devices that read and write directly from the memory
system. These are attached to the ``FrontendBus``. The ``FrontendBus`` can also
connect vendor-supplied AXI4 DMA devices through an AXI4 to TileLink converter.
To learn more about adding DMA devices, see the :ref:`Adding a DMA port` section
of :ref:`Adding an Accelerator/Device`.
To learn more about adding DMA devices, see the :ref:`dma-devices` section.

6
docs/Generators/SHA3.rst
View File

@@ -68,11 +68,11 @@ Using a SHA3 Accelerator
------------------------
Since the SHA3 accelerator is designed as a RoCC accelerator,
it can be mixed into a Rocket or BOOM core by overriding the
``BuildRoCC`` key. The configuration mixin is defined in the SHA3
``BuildRoCC`` key. The config fragment is defined in the SHA3
generator. An example configuration highlighting the use of
this mixin is shown here:
this config fragment is shown here:
.. literalinclude:: ../../generators/example/src/main/scala/RocketConfigs.scala
.. literalinclude:: ../../generators/chipyard/src/main/scala/config/RocketConfigs.scala
:language: scala
:start-after: DOC include start: Sha3Rocket
:end-before: DOC include end: Sha3Rocket

22
docs/Generators/SiFive-Generators.rst
View File

@@ -1,13 +1,13 @@
SiFive Generators
==================
Chipyard includes several open-source generators developed and maintained by `SiFive <https://www.sifive.com/>`__.
Chipyard includes several open-source generators developed and maintained by `SiFive <https://www.sifive.com/>`__.
These are currently organized within two submodules named ``sifive-blocks`` and ``sifive-cache``.
Last-Level Cache Generator
-----------------------------
``sifive-cache`` includes last-level cache geneator. The Chipyard framework uses this last-level cache as an L2 cache. To use this L2 cache, you should add the ``freechips.rocketchip.subsystem.WithInclusiveCache`` mixin to your SoC configuration.
``sifive-cache`` includes last-level cache geneator. The Chipyard framework uses this last-level cache as an L2 cache. To use this L2 cache, you should add the ``freechips.rocketchip.subsystem.WithInclusiveCache`` config fragment to your SoC configuration.
To learn more about configuring this L2 cache, please refer to the :ref:`memory-hierarchy` section.
@@ -16,24 +16,24 @@ Peripheral Devices
``sifive-blocks`` includes multiple peripheral device generators, such as UART, SPI, PWM, JTAG, GPIO and more.
These peripheral devices usually affect the memory map of the SoC, and its top-level IO as well.
To integrate one of these devices in your SoC, you will need to define a custom mixin with the approriate address for the device using the Rocket Chip parameter system. As an example, for a GPIO device you could add the following mixin to set the GPIO address to ``0x10012000``. This address is the start address for the GPIO configuration registers.
To integrate one of these devices in your SoC, you will need to define a custom config fragment with the approriate address for the device using the Rocket Chip parameter system. As an example, for a GPIO device you could add the following config fragment to set the GPIO address to ``0x10012000``. This address is the start address for the GPIO configuration registers.
.. literalinclude:: ../../generators/example/src/main/scala/ConfigMixins.scala
.. literalinclude:: ../../generators/chipyard/src/main/scala/ConfigFragments.scala
:language: scala
:start-after: DOC include start: gpio mixin
:end-before: DOC include end: gpio mixin
:start-after: DOC include start: gpio config fragment
:end-before: DOC include end: gpio config fragment
Additionally, if the device requires top-level IOs, you will need to define a mixin to change the top-level configuration of your SoC.
Additionally, if the device requires top-level IOs, you will need to define a config fragment to change the top-level configuration of your SoC.
When adding a top-level IO, you should also be aware of whether it interacts with the test-harness.
This example instantiates a top-level module with include GPIO ports (``TopWithGPIO``), and then ties-off the GPIO port inputs to 0 (``false.B``).
This example instantiates a top-level module with include GPIO ports, and then ties-off the GPIO port inputs to 0 (``false.B``).
Finally, you add the relevant config mixin to the SoC config. For example:
Finally, you add the relevant config fragment to the SoC config. For example:
.. literalinclude:: ../../generators/example/src/main/scala/RocketConfigs.scala
.. literalinclude:: ../../generators/chipyard/src/main/scala/config/RocketConfigs.scala
:language: scala
:start-after: DOC include start: GPIORocketConfig
:end-before: DOC include end: GPIORocketConfig
Some of the devices in ``sifive-blocks`` (such as GPIO) may already have pre-defined mixins within the Chipyard example project. You may be able to use these config mixins directly, but you should be aware of their addresses within the SoC address map.
Some of the devices in ``sifive-blocks`` (such as GPIO) may already have pre-defined config fragments within the Chipyard example project. You may be able to use these config fragments directly, but you should be aware of their addresses within the SoC address map.

31
docs/Generators/TestChipIP.rst
View File

@@ -3,7 +3,8 @@ Test Chip IP
Chipyard includes a Test Chip IP library which provides various hardware
widgets that may be useful when designing SoCs. This includes a :ref:`Serial Adapter`,
:ref:`Block Device Controller`, :ref:`TileLink SERDES`, :ref:`TileLink Switcher`, and :ref:`UART Adapter`.
:ref:`Block Device Controller`, :ref:`TileLink SERDES`, :ref:`TileLink Switcher`,
:ref:`TileLink Ring Network`, and :ref:`UART Adapter`.
Serial Adapter
--------------
@@ -22,9 +23,7 @@ The block device controller provides a generic interface for secondary storage.
This device is primarily used in FireSim to interface with a block device
software simulation model. The default Linux configuration in `firesim-software <https://github.com/firesim/firesim-software>`_
To add a block device to your design, add ``HasPeripheryBlockDevice`` to your
lazy module and ``HasPeripheryBlockDeviceModuleImp`` to the implementation.
Then add the ``WithBlockDevice`` config mixin to your configuration.
To add a block device to your design, add the ``WithBlockDevice`` config fragment to your configuration.
TileLink SERDES
@@ -62,6 +61,19 @@ the select signal once TileLink messages have begun sending.
For an example of how to use the switcher, take a look at the ``SwitcherTest``
unit test in the `Test Chip IP unit tests <https://github.com/ucb-bar/testchipip/blob/master/src/main/scala/Unittests.scala>`_.
TileLink Ring Network
---------------------
TestChipIP provides a TLRingNetwork generator that has a similar interface
to the TLXbar provided by RocketChip, but uses ring networks internally rather
than crossbars. This can be useful for chips with very wide TileLink networks
(many cores and L2 banks) that can sacrifice cross-section bandwidth to relieve
wire routing congestion. Documentation on how to use the ring network can be
found in :ref:`The System Bus`. The implementation itself can be found
`here <https://github.com/ucb-bar/testchipip/blob/master/src/main/scala/Ring.scala>`_,
and may serve as an example of how to implement your own TileLink network with
a different topology.
UART Adapter
------------
@@ -71,5 +83,12 @@ during Linux boot). In addition to working with ``stdin/stdout`` of the host, it
output a UART log to a particular file using ``+uartlog=<NAME_OF_FILE>`` during simulation.
By default, this UART Adapter is added to all systems within Chipyard by adding the
``CanHavePeripheryUARTWithAdapter`` and ``CanHavePeripheryUARTWithAdapterImp`` traits to the ``Top`` system.
These traits add a SiFive UART to the system as well as add the UART Adapter to the TestHarness.
``WithUART`` and ``WithUARTAdapter`` configs.
SPI Flash Model
---------------
The SPI flash model is a device that models a simple SPI flash device. It currently
only supports single read, quad read, single write, and quad write instructions. The
memory is backed by a file which is provided using ``+spiflash#=<NAME_OF_FILE>``,
where ``#`` is the SPI flash ID (usually ``0``).

4
docs/Generators/index.rst
View File

@@ -1,6 +1,6 @@
.. _generator-index:
Generators
Included RTL Generators
============================
A Generator can be thought of as a generalized RTL design, written using a mix of meta-programming and standard RTL.
@@ -27,4 +27,6 @@ so changes to the generators themselves will automatically be used when building
TestChipIP
SiFive-Generators
SHA3
Ariane
NVDLA

4
docs/Makefile
View File

@@ -2,8 +2,8 @@
#
# You can set these variables from the command line.
SPHINXOPTS =
SPHINXBUILD = python -msphinx
SPHINXOPTS = -w warnings.txt -n -W
SPHINXBUILD = python3 -msphinx
SPHINXPROJ = Chipyard
SOURCEDIR = .
BUILDDIR = _build

65
docs/Quick-Start.rst
View File

@@ -1,65 +0,0 @@
Quick Start
===============================
Requirements
-------------------------------------------
Chipyard is developed and tested on Linux-based systems.
.. Warning:: It is possible to use this on macOS or other BSD-based systems, although GNU tools will need to be installed; it is also recommended to install the RISC-V toolchain from ``brew``.
.. Warning:: Working under Windows is not recommended.
Setting up the Chipyard Repo
-------------------------------------------
Start by fetching Chipyard's sources. Run:
.. code-block:: shell
git clone https://github.com/ucb-bar/chipyard.git
cd chipyard
./scripts/init-submodules-no-riscv-tools.sh
This will initialize and checkout all of the necessary git submodules.
Installing the RISC-V Tools
-------------------------------------------
We need to install the RISC-V toolchain in order to be able to run RISC-V programs using the Chipyard infrastructure.
This will take about 20-30 minutes. You can expedite the process by setting a ``make`` environment variable to use parallel cores: ``export MAKEFLAGS=-j8``.
To build the toolchains, you should run:
.. code-block:: shell
./scripts/build-toolchains.sh
.. Note:: If you are planning to use the Hwacha vector unit, or other RoCC-based accelerators, you should build the esp-tools toolchain by adding the ``esp-tools`` argument to the script above.
If you are running on an Amazon Web Services EC2 instance, intending to use FireSim, you can also use the ``--ec2fast`` flag for an expedited installation of a pre-compiled toolchain.
Finally, set up Chipyard's environment variables and put the newly built toolchain on your path:
.. code-block:: shell
source ./env.sh
What's Next?
-------------------------------------------
This depends on what you are planning to do with Chipyard.
* If you intend to run a simulation of one of the vanilla Chipyard examples, go to :ref:`sw-rtl-sim-intro` and follow the instructions.
* If you intend to run a simulation of a custom Chipyard SoC Configuration, go to :ref:`Simulating A Custom Project` and follow the instructions.
* If you intend to run a full-system FireSim simulation, go to :ref:`firesim-sim-intro` and follow the instructions.
* If you intend to add a new accelerator, go to :ref:`customization` and follow the instructions.
* If you want to learn about the structure of Chipyard, go to :ref:`chipyard-components`.
* If you intend to change the generators (BOOM, Rocket, etc) themselves, see :ref:`generator-index`.
* If you intend to run a tutorial VLSI flow using one of the Chipyard examples, go to :ref:`tutorial` and follow the instructions.
* If you intend to build a chip using one of the vanilla Chipyard examples, go to :ref:`build-a-chip` and follow the instructions.

56
docs/Simulation/FPGA-Accelerated-Simulation.rst
View File

@@ -44,47 +44,19 @@ familiar with FireSim, please return to the `FireSim Docs
<https://docs.fires.im/en/latest/Initial-Setup/Setting-up-your-Manager-Instance.html#completing-setup-using-the-manager>`__,
and proceed with the rest of the tutorial.
Current Limitations:
++++++++++++++++++++
FireSim integration in Chipyard is still a work in progress. Presently, you
cannot build a FireSim simulator from any generator project in Chipyard except ``firechip``,
which properly invokes MIDAS on the target RTL.
In the interim, workaround this limitation by importing Config and Module
classes from other generator projects into FireChip. For example, assuming you Chipyard
config looks as following:
.. code-block:: scala
class CustomConfig extends Config(
new WithInclusiveCache ++
new myproject.MyCustomConfig ++
new DefaultRocketConfig
)
Then the equivalent FireChip config (in ``generators/firechip/src/main/scala/TargetConfigs.scala``) based on ``FireSimRocketChipConfig``
will look as follows:
.. code-block:: scala
class FireSimCustomConfig extends Config(
new WithBootROM ++
new WithPeripheryBusFrequency(BigInt(3200000000L)) ++
new WithExtMemSize(0x400000000L) ++ // 16GB
new WithoutTLMonitors ++
new WithUARTKey ++
new WithNICKey ++
new WithBlockDevice ++
new WithRocketL2TLBs(1024) ++
new WithPerfCounters ++
new WithoutClockGating ++
new WithInclusiveCache ++
new myproject.MyCustomConfig ++
new freechips.rocketchip.system.DefaultConfig)
Running your Design in FireSim
------------------------------
Converting a Chipyard config (one in ``chipyard/src/main/scala`` to run in FireSim is simple. We are using the same target (top) RTL, and only need to specify a new set of connection behaviors for the IOs of that module. Simply create a matching config within ``generators/firechip/src/main/scala/TargetConfigs`` that inherits your config defined in ``chipyard``.
You should then be able to refer to those classes or an alias of them in your ``DESIGN`` or ``TARGET_CONFIG``
variables. Note that if your target machine has I/O not provided in the default
FireChip targets (see ``generators/firechip/src/main/scala/Targets.scala``) you may need
to write a custom bridge.
.. literalinclude:: ../../generators/firechip/src/main/scala/TargetConfigs.scala
:language: scala
:start-after: DOC include start: firesimconfig
:end-before: DOC include end: firesimconfig
Only 3 additional config fragments are needed.
* ``WithFireSimConfigTweaks`` modifies your design to better fit the FireSim usage model. For example, FireSim designs typically include a UART. Technically, adding this in is optional, but *strongly* recommended.
* ``WithDefaultMemModel`` sets the external memory model in the FireSim simulation. See the FireSim documentation for details.
* ``WithDefaultFireSimBridges`` sets the ``IOBinders`` key to use FireSim's Bridge system, which can drive target IOs with software bridge models running on the simulation host. See the FireSim documentation for details.

10
docs/Simulation/Software-RTL-Simulation.rst
View File

@@ -49,16 +49,18 @@ Simulating The Default Example
To compile the example design, run ``make`` in the selected verilator or VCS directory.
This will elaborate the ``RocketConfig`` in the example project.
An executable called ``simulator-example-RocketConfig`` will be produced.
.. Note:: The elaboration of ``RocketConfig`` requires about 6.5 GB of main memory. Otherwise the process will fail with ``make: *** [firrtl_temp] Error 137`` which is most likely related to limited resources. Other configurations might require even more main memory.
An executable called ``simulator-chipyard-RocketConfig`` will be produced.
This executable is a simulator that has been compiled based on the design that was built.
You can then use this executable to run any compatible RV64 code.
For instance, to run one of the riscv-tools assembly tests.
.. code-block:: shell
./simulator-example-RocketConfig $RISCV/riscv64-unknown-elf/share/riscv-tests/isa/rv64ui-p-simple
./simulator-chipyard-RocketConfig $RISCV/riscv64-unknown-elf/share/riscv-tests/isa/rv64ui-p-simple
.. Note:: In a VCS simulator, the simulator name will be ``simv-example-RocketConfig`` instead of ``simulator-example-RocketConfig``.
.. Note:: In a VCS simulator, the simulator name will be ``simv-chipyard-RocketConfig`` instead of ``simulator-chipyard-RocketConfig``.
Alternatively, we can run a pre-packaged suite of RISC-V assembly or benchmark tests, by adding the make target ``run-asm-tests`` or ``run-bmark-tests``.
For example:
@@ -93,7 +95,7 @@ The ``MODEL`` and ``VLOG_MODEL`` are the top-level class names of the design. No
The ``MODEL_PACKAGE`` is the Scala package (in the Scala code that says ``package ...``) that holds the ``MODEL`` class.
The ``CONFIG`` is the name of the class used for the parameter Config while the ``CONFIG_PACKAGE`` is the Scala package it resides in.
The ``CONFIG`` is the name of the class used for the parameter config while the ``CONFIG_PACKAGE`` is the Scala package it resides in.
The ``GENERATOR_PACKAGE`` is the Scala package that holds the Generator class that elaborates the design.

27
docs/Software/Baremetal.rst Normal file
View File

@@ -0,0 +1,27 @@
.. _baremetal-programs:
Baremetal RISC-V Programs
==========================
To build baremetal RISC-V programs to run in simulation, we use the riscv64-unknown-elf cross-compiler and a fork of the libgloss board support package. To build such a program yourself, simply invoke the cross-compiler with the flags "-fno-common -fno-builtin-printf -specs=htif_nano.specs" and the link with the arguments "-static -specs=htif_nano.specs". For instance, if we want to run a "Hello, World" program in baremetal, we could do the following.
.. code:: c
#include <stdio.h>
int main(void)
{
printf("Hello, World!\n");
return 0;
}
.. code:: bash
$ riscv64-unknown-elf-gcc -fno-common -fno-builtin-printf -specs=htif_nano.specs -c hello.c
$ riscv64-unknown-elf-gcc -static -specs=htif_nano.specs hello.o -o hello.riscv
$ spike hello.riscv
Hello, World!
For more examples, look at the `tests/ directory <https://github.com/ucb-bar/chipyard/tree/master/tests>`_ in the chipyard repository.
For more information about the libgloss port, take a look at `its README <https://github.com/ucb-bar/libgloss-htif/blob/master/README.md>`_.

1
docs/Software/FireMarshal.rst
View File

@@ -1,4 +1,5 @@
.. _fire-marshal:
FireMarshal
=================

1
docs/Software/index.rst
View File

@@ -19,3 +19,4 @@ challenging to modify.
FireMarshal
Spike
Baremetal

12
docs/TileLink-Diplomacy-Reference/NodeTypes.rst
View File

@@ -17,7 +17,7 @@ The L1 caches and DMA devices in RocketChip/Chipyard have client nodes.
You can add a TileLink client node to your LazyModule using the TLHelper
object from testchipip like so:
.. literalinclude:: ../../generators/example/src/main/scala/NodeTypes.scala
.. literalinclude:: ../../generators/chipyard/src/main/scala/example/NodeTypes.scala
:language: scala
:start-after: DOC include start: MyClient
:end-before: DOC include end: MyClient
@@ -66,7 +66,7 @@ TileLink managers take requests from clients on the A channel and send
responses back on the D channel. You can create a manager node using the
TLHelper like so:
.. literalinclude:: ../../generators/example/src/main/scala/NodeTypes.scala
.. literalinclude:: ../../generators/chipyard/src/main/scala/example/NodeTypes.scala
:language: scala
:start-after: DOC include start: MyManager
:end-before: DOC include end: MyManager
@@ -146,7 +146,7 @@ to the outputs unchanged. This node is mainly used to combine multiple
nodes into a single node with multiple edges. For instance, say we have two
client lazy modules, each with their own client node.
.. literalinclude:: ../../generators/example/src/main/scala/NodeTypes.scala
.. literalinclude:: ../../generators/chipyard/src/main/scala/example/NodeTypes.scala
:language: scala
:start-after: DOC include start: MyClient1+MyClient2
:end-before: DOC include end: MyClient1+MyClient2
@@ -154,21 +154,21 @@ client lazy modules, each with their own client node.
Now we instantiate these two clients in another lazy module and expose their
nodes as a single node.
.. literalinclude:: ../../generators/example/src/main/scala/NodeTypes.scala
.. literalinclude:: ../../generators/chipyard/src/main/scala/example/NodeTypes.scala
:language: scala
:start-after: DOC include start: MyClientGroup
:end-before: DOC include end: MyClientGroup
We can also do the same for managers.
.. literalinclude:: ../../generators/example/src/main/scala/NodeTypes.scala
.. literalinclude:: ../../generators/chipyard/src/main/scala/example/NodeTypes.scala
:language: scala
:start-after: DOC include start: MyManagerGroup
:end-before: DOC include end: MyManagerGroup
If we want to connect the client and manager groups together, we can now do this.
.. literalinclude:: ../../generators/example/src/main/scala/NodeTypes.scala
.. literalinclude:: ../../generators/chipyard/src/main/scala/example/NodeTypes.scala
:language: scala
:start-after: DOC include start: MyClientManagerComplex
:end-before: DOC include end: MyClientManagerComplex

14
docs/TileLink-Diplomacy-Reference/Register-Router.rst
View File

@@ -11,14 +11,14 @@ for exposing registers themselves, it's much easier to use RocketChip's
``regmap`` interface, which can generate most of the glue logic.
For TileLink devices, you can use the ``regmap`` interface by extending
the ``TLRegisterRouter`` class, as shown in :ref:`Adding An Accelerator/Device`,
the ``TLRegisterRouter`` class, as shown in :ref:`mmio-accelerators`,
or you can create a regular LazyModule and instantiate a ``TLRegisterNode``.
This section will focus on the second method.
Basic Usage
-----------
.. literalinclude:: ../../generators/example/src/main/scala/RegisterNodeExample.scala
.. literalinclude:: ../../generators/chipyard/src/main/scala/example/RegisterNodeExample.scala
:language: scala
:start-after: DOC include start: MyDeviceController
:end-before: DOC include end: MyDeviceController
@@ -56,7 +56,7 @@ register. The ``RegField`` interface also provides support for reading
and writing ``DecoupledIO`` interfaces. For instance, you can implement a
hardware FIFO like so.
.. literalinclude:: ../../generators/example/src/main/scala/RegisterNodeExample.scala
.. literalinclude:: ../../generators/chipyard/src/main/scala/example/RegisterNodeExample.scala
:language: scala
:start-after: DOC include start: MyQueueRegisters
:end-before: DOC include end: MyQueueRegisters
@@ -71,7 +71,7 @@ You need not specify both read and write for a register. You can also create
read-only or write-only registers. So for the previous example, if you wanted
enqueue and dequeue to use different addresses, you could write the following.
.. literalinclude:: ../../generators/example/src/main/scala/RegisterNodeExample.scala
.. literalinclude:: ../../generators/chipyard/src/main/scala/example/RegisterNodeExample.scala
:language: scala
:start-after: DOC include start: MySeparateQueueRegisters
:end-before: DOC include end: MySeparateQueueRegisters
@@ -93,7 +93,7 @@ You can also create registers using functions. Say, for instance, that you
want to create a counter that gets incremented on a write and decremented on
a read.
.. literalinclude:: ../../generators/example/src/main/scala/RegisterNodeExample.scala
.. literalinclude:: ../../generators/chipyard/src/main/scala/example/RegisterNodeExample.scala
:language: scala
:start-after: DOC include start: MyCounterRegisters
:end-before: DOC include end: MyCounterRegisters
@@ -107,7 +107,7 @@ You can also pass functions that decouple the read/write request and response.
The request will appear as a decoupled input and the response as a decoupled
output. So for instance, if we wanted to do this for the previous example.
.. literalinclude:: ../../generators/example/src/main/scala/RegisterNodeExample.scala
.. literalinclude:: ../../generators/chipyard/src/main/scala/example/RegisterNodeExample.scala
:language: scala
:start-after: DOC include start: MyCounterReqRespRegisters
:end-before: DOC include end: MyCounterReqRespRegisters
@@ -131,7 +131,7 @@ change the protocol being used. For instance, in the first example in
:ref:`Basic Usage`, you could simply change the ``TLRegisterNode`` to
and ``AXI4RegisterNode``.
.. literalinclude:: ../../generators/example/src/main/scala/RegisterNodeExample.scala
.. literalinclude:: ../../generators/chipyard/src/main/scala/example/RegisterNodeExample.scala
:language: scala
:start-after: DOC include start: MyAXI4DeviceController
:end-before: DOC include end: MyAXI4DeviceController

18
docs/TileLink-Diplomacy-Reference/Widgets.rst
View File

@@ -169,7 +169,7 @@ transactions.
- ``minSize: Int`` - Minimum size of transfers supported by all outward managers.
- ``maxSize: Int`` - Maximum size of transfers supported after the Fragmenter is applied.
- ``alwaysMin: Boolean`` - (optional) Fragment all requests down to minSize (else fragment to maximum supported by manager). (default: false)
- ``earlyAck: EarlyAck.T`` - (optional) Should a multibeat Put be acknowledged on the first beat or last beat?
- ``earlyAck: EarlyAck.T`` - (optional) Should a multibeat Put be acknowledged on the first beat or last beat?
Possible values (default: ``EarlyAck.None``):
- ``EarlyAck.AllPuts`` - always acknowledge on first beat.
@@ -270,7 +270,7 @@ the client to see a particular width.
**Example Usage:**
.. code-block::
.. code-block:: scala
// Assume the manager node sets beatBytes to 8
// With WidthWidget, client sees beatBytes of 4
@@ -398,11 +398,11 @@ package, not the ``freechips.rocketchip.tilelink`` package like the others.
- ``size: Int`` - The size of the memory in bytes
- ``contentsDelayed: => Seq[Byte]`` - A function which, when called generates
the byte contents of the ROM.
- ``executable: Boolean`` - (optional) Specify whether the CPU can fetch
- ``executable: Boolean`` - (optional) Specify whether the CPU can fetch
instructions from the ROM (default: ``true``).
- ``beatBytes: Int`` - (optional) The width of the interface in bytes.
- ``beatBytes: Int`` - (optional) The width of the interface in bytes.
(default: 4).
- ``resources: Seq[Resource]`` - (optional) Sequence of resources to add to
- ``resources: Seq[Resource]`` - (optional) Sequence of resources to add to
the device tree.
**Example Usage:**
@@ -429,13 +429,13 @@ The TLRAM and AXI4RAM widgets provide read-write memories implemented as SRAMs.
**Arguments:**
- ``address: AddressSet`` - The address range that this RAM will cover.
- ``cacheable: Boolean`` - (optional) Can the contents of this RAM be cached.
- ``cacheable: Boolean`` - (optional) Can the contents of this RAM be cached.
(default: ``true``)
- ``executable: Boolean`` - (optional) Can the contents of this RAM be fetched
- ``executable: Boolean`` - (optional) Can the contents of this RAM be fetched
as instructions. (default: ``true``)
- ``beatBytes: Int`` - (optional) Width of the TL/AXI4 interface in bytes.
- ``beatBytes: Int`` - (optional) Width of the TL/AXI4 interface in bytes.
(default: 4)
- ``atomics: Boolean`` - (optional, TileLink only) Does the RAM support
- ``atomics: Boolean`` - (optional, TileLink only) Does the RAM support
atomic operations? (default: ``false``)
**Example Usage:**

2
docs/TileLink-Diplomacy-Reference/index.rst
View File

@@ -11,7 +11,7 @@ elaboration scheme. For a detailed explanation of Diplomacy, see `the paper
by Cook, Terpstra, and Lee <https://carrv.github.io/2017/papers/cook-diplomacy-carrv2017.pdf>`_.
A brief overview of how to connect simple TileLink widgets can be found
in the :ref:`Adding-an-Accelerator` section. This section will provide a
in the :ref:`mmio-accelerators` section. This section will provide a
detailed reference for the TileLink and Diplomacy functionality provided by
RocketChip.

130
docs/Tools/Barstools.rst
View File

@@ -3,3 +3,133 @@ Barstools
Barstools is a collection of useful FIRRTL transformations and compilers to help the build process.
Included in the tools are a MacroCompiler (used to map Chisel memory constructs to vendor SRAMs), FIRRTL transforms (to separate harness and top-level SoC files), and more.
Mapping technology SRAMs (MacroCompiler)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If you are planning on building a real chip, it is likely that you will plan on using some amount of static random access memory, or SRAM.
SRAM macros offer superior storage density over flip-flop arrays at the cost of restricting the number of read or write transactions that can happen in a cycle.
Unlike in Verilog, these types of sequential memory elements are first-class primitives in Chisel and FIRRTL (``SeqMem`` elements).
This allows Chisel designs to contain abstract instantiations of sequential memory elements without knowing the underlying implementation or process technology.
Modern CAD tools typically cannot synthesize SRAMs from a high-level RTL description.
This, unfortunately, requires the designer to include the SRAM instantiation in the source RTL, which removes its process portability.
In Verilog-entry designs, it is possible to create a layer of abstraction that allows a new process technology to implement a specific sequential memory block in a wrapper module.
However, this method can be fragile and laborious.
The FIRRTL compiler contains a transformation to replace the ``SeqMem`` primitives called ``ReplSeqMem``.
This simply converts all ``SeqMem`` instances above a size threshold into external module references.
An external module reference is a FIRRTL construct that enables a design to reference a module without describing its contents, only its inputs and outputs.
A list of unique SRAM configurations is output to a ``.conf`` file by FIRRTL, which is used to map technology SRAMs.
Without this transform, FIRRTL will map all ``SeqMem`` s to flip-flop arrays with equivalent behavior, which may lead to a design that is difficult to route.
The ``.conf`` file is consumed by a tool called MacroCompiler, which is part of the :ref:`Barstools` scala package.
MacroCompiler is also passed an ``.mdf`` file that describes the available list of technology SRAMs or the capabilities of the SRAM compiler, if one is provided by the foundry.
Typically a foundry SRAM compiler will be able to generate a set of different SRAMs collateral based on some requirements on size, aspect ratio, etc. (see :ref:`SRAM MDF Fields`).
Using a user-customizable cost function, MacroCompiler will select the SRAMs that are the best fit for each dimensionality in the ``.conf`` file.
This may include over provisioning (e.g. using a 64x1024 SRAM for a requested 60x1024, if the latter is not available) or arraying.
Arraying can be done in both width and depth, as well as to solve masking constraints.
For example, a 128x2048 array could be composed of four 64x1024 arrays, with two macros in parallel to create two 128x1024 virtual SRAMs which are combinationally muxed to add depth.
If this macro requires byte-granularity write masking, but no technology SRAMs support masking, then the tool may choose to use thirty-two 8x1024 arrays in a similar configuration.
For information on writing ``.mdf`` files, look at `MDF on github <https://github.com/ucb-bar/plsi-mdf>`__ and a brief description in :ref:`SRAM MDF Fields` section.
The output of MacroCompiler is a Verilog file containing modules that wrap the technology SRAMs into the specified interface names from the ``.conf``.
If the technology supports an SRAM compiler, then MacroCompiler will also emit HammerIR that can be passed to Hammer to run the compiler itself and generate design collateral.
Documentation for SRAM compilers is forthcoming.
MacroCompiler Options
+++++++++++++++++++++
MacroCompiler accepts many command-line parameters which affect how it maps ``SeqMem`` s to technology specific macros.
This highest level option ``--mode`` specifies in general how MacroCompiler should map the input ``SeqMem`` s to technology macros.
The ``strict`` value forces MacroCompiler to map all memories to technology macros and error if it is unable to do so.
The ``synflops`` value forces MacroCompiler to map all memories to flip flops.
The ``compileandsynflops`` value instructs MacroCompiler to use the technology compiler to determine sizes of technology macros used but to then create mock versions of these macros with flip flops.
The ``fallbacksynflops`` value causes MacroCompiler to compile all possible memories to technology macros but when unable to do so to use flip flops to implement the remaining memories.
The final and default value, ``compileavailable``, instructs MacroCompiler to compile all memories to the technology macros and do nothing if it is unable to map them.
Most of the rest of the options are used to control where different inputs and outputs are expected and produced.
The option ``--macro-conf`` is the file that contains the set of input ``SeqMem`` configurations to map in the ``.conf`` format described above.
The option ``--macro-mdf`` also describes the input ``SeqMem`` s but is instead in the ``.mdf`` format.
The option ``--library`` is an ``.mdf`` description of the available technology macros that can be mapped to.
This file could be a list of fixed size memories often referred to as a cache of macros, or a description of what size memories could be made available through some technology specific process (usually an SRAM compiler), or a mix of both.
The option ``--use-compiler`` instructs MacroCompiler that it is allowed to use any compilers listed in the ``--library`` specification.
If this option is not set MacroCompiler will only map to macros directly listed in the ``--library`` specification.
The ``--verilog`` option specifies where MacroCompiler will write the verilog containing the new technology mapped memories.
The ``--firrtl`` option similarly specifies where MacroCompiler will write the FIRRTL that will be used to generate this verilog.
This option is optional and no FIRRTL will be emitted if it is not specified.
The ``--hammer-ir`` option specifies where MacroCompiler will write the details of which macros need to be generated from a technology compiler.
This option is not needed if ``--use-compiler`` is not specified.
This file can then be passed to HAMMER to have it run the technology compiler producing the associated macro collateral.
The ``--cost-func`` option allows the user to specify a different cost function for the mapping task.
Because the mapping of memories is a multi-dimensional space spanning performance, power, and area, the cost function setting of MacroCompiler allows the user to tune the mapping to their preference.
The default option is a reasonable heuristic that attempts to minimize the number of technology macros instantiated per ``SeqMem`` without wasting too many memory bits.
There are two ways to add additional cost functions.
First, you can simply write another one in scala and call `registerCostMetric` which then enables you to pass its name to this command-line flag.
Second, there is a pre-defined `ExternalMetric` which will execute a program (passed in as a path) with the MDF description of the memory being compiled and the memory being proposed as a mapping.
The program should print a floating point number which is the cost for this mapping, if no number is printed MacroCompiler will assume this is an illegal mapping.
The ``--cost-param`` option allows the user to specify parameters to pass to the cost function if the cost function supports that.
The ``--force-synflops [mem]`` options allows the user to override any heuristics in MacroCompiler and force it to map the given memory to flip-flops.
Likewise, the ``--force-compile [mem]`` option allows the user to force MacroCompiler to map the given ``mem`` to a technology macro.
SRAM MDF Fields
+++++++++++++++
Technology SRAM macros described in MDF can be defined at three levels of detail.
A single instance can be defined with the `SRAMMacro` format.
A group of instances that share the number and type of ports but vary in width and depth can be defined with the `SRAMGroup` format.
A set of groups of SRAMs that can be generated together from a single source like a compiler can be defined with the `SRAMCompiler` format.
At the most concrete level the `SRAMMAcro` defines a particular instance of an SRAM.
That includes its functional attributes such as its width, depth, and number of access ports.
These ports can be read, write, or read and write ports, and the instance can have any number.
In order to correctly map to these functional ports to the physical instance each port is described in a list of sub-structures, in the parent instance's structure.
Each port is only required to have an address and data field, but can have many other optional fields.
These optional fields include a clock, write enable, read enable, chip enable, mask.
The mask field can have a different granularity than the data field, e.g. it could be a bit mask or a byte mask.
Each field must also specify its polarity, whether it is active high or active low.
In addition to these functional descriptions of the SRAM there are also other fields that specify physical/implementation characteristics.
These include the threshold voltage, the mux factor, as well as a list of extra non-functional ports.
The next level of detail, an `SRAMGroup` includes a range of depths and widths, as well as a set of threshold voltages.
A range has a lower bound, upper bound, and a step size.
The least concrete level, an `SRAMCompiler` is simply a set of `SRAMGroups`.
Separating the Top module from the TestHarness module
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Unlike the FireSim and Software simulation flows, a VLSI flow needs to separate the test harness and the chip (a.k.a. DUT) into separate files.
This is necessary to facilitate post-synthesis and post-place-and-route simulation, as the module names in the RTL and gate-level verilog files would collide.
Simulations after you the design goes through a VLSI flow will use the verilog netlist generated from the flow and will need an untouched test harness to drive it.
Separating these components into separate files makes this straightforward.
Without the separation the file that included the test harness would also redefine the DUT which is often disallowed in simulation tools.
To do this, there is a FIRRTL ``App`` in :ref:`Barstools` called ``GenerateTopAndHarness``, which runs the appropriate transforms to elaborate the modules separately.
This also renames modules in the test harness so that any modules that are instantiated in both the test harness and the chip are uniquified.
.. Note:: For VLSI projects, this ``App`` is run instead of the normal FIRRTL ``App`` to elaborate Verilog.
Macro Description Format
~~~~~~~~~~~~~~~~~~~~~~~~
The SRAM technology macros and IO cells are described in a json format called Macro Description Format (MDF).
MDF is specialized for each type of macro it supports.
The specialization is defined in their respective sections.
Mapping technology IO cells
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Like technology SRAMs, IO cells are almost always included in digital ASIC designs to allow pin configurability, increase the voltage level of the IO signal, and provide ESD protection.
Unlike SRAMs, there is no corresponding primitive in Chisel or FIRRTL.
However, this problem can be solved similarly to ``SeqMems`` by leveraging the strong typing available in these scala-based tools.
We are actively developing a FIRRTL transform that will automatically configure, map, and connect technology IO cells.
Stay tuned for more information!
In the meantime, it is recommended that you instantiate the IO cells in your Chisel design.
This, unfortunately, breaks the process-agnostic RTL abstraction, so it is recommended that inclusion of these cells be configurable using the ``rocket-chip`` parameterization system.
The simplest way to do this is to have a config fragment that when included updates instantiates the IO cells and connects them in the test harness.
When simulating chip-specific designs, it is important to include the IO cells.
The IO cell behavioral models will often assert if they are connected incorrectly, which is a useful runtime check.
They also keep the IO interface at the chip and test harness boundary (see :ref:`Separating the Top module from the TestHarness module`) consistent after synthesis and place-and-route,
which allows the RTL simulation test harness to be reused.

22
docs/Tools/Dromajo.rst Normal file
View File

@@ -0,0 +1,22 @@
Dromajo
===============================
`Dromajo <https://github.com/chipsalliance/dromajo/>`__ is a RV64GC functional simulator designed for co-simulation.
To use it as a co-simulator, it requires you to pass the committed trace of instructions coming from the core into the tool.
Within Chipyard, this is done by connecting to the `TracePort`` signals that are piped to the top level of the DUT.
While the Rocket core does have a `TracePort`, it does not provide the committed write data that Dromajo requires.
Thus, Dromajo uses the `ExtendedTracePort` only probided by BOOM (BOOM is the only core that supports Dromajo co-simulation).
An example of a divergence and Dromajo's printout is shown below.
.. code-block:: shell
[error] EMU PC ffffffe001055d84, DUT PC ffffffe001055d84
[error] EMU INSN 14102973, DUT INSN 14102973
[error] EMU WDATA 00000000000220d6, DUT WDATA 00000000000220d4
[error] EMU MSTATUS a000000a0, DUT MSTATUS 00000000
[error] DUT pending exception -1 pending interrupt -1
Dromajo shows the divergence compared to simulation (PC, inst, inst-bits, write data, etc) and also provides the register state on failure.
It is useful to catch bugs that affect architectural state before a simulation hangs or crashes.
To use Dromajo with BOOM, refer to :ref:`Debugging RTL` section on Dromajo.

1
docs/Tools/FIRRTL.rst
View File

@@ -1,4 +1,3 @@
.. _firrtl:
FIRRTL
================================

4
docs/Tools/index.rst
View File

@@ -1,4 +1,4 @@
Tools
Development Tools
==============================
The Chipyard framework relays heavily on a set of Scala-based tools.
@@ -14,4 +14,4 @@ The following pages will introduce them, and how we can use them in order to gen
Chisel-Testers
Dsptools
Barstools
Dromajo

4
docs/VLSI/Advanced-Usage.rst
View File

@@ -49,6 +49,6 @@ Say you need to update some power straps settings in ``example.yml`` and want to
make redo-par HAMMER_REDO_ARGS='-p example.yml --only_step power_straps'
Simulation
----------
RTL and Gate-level Simulation
-----------------------------
With the Synopsys plugin, RTL and gate-level simulation is supported using VCS. While this example does not implement any simulation, refer to Hammer's documentation for how to set it up for your design.

52
docs/VLSI/Building-A-Chip.rst
View File

@@ -1,6 +1,54 @@
.. _build-a-chip:
Building A Chip
==============================
===============
In this section, we will discuss many of the ASIC-specific transforms and methodologies within Chipyard.
For the full documentation on how to use the VLSI tool flow, see the `Hammer Documentation <https://hammer-vlsi.readthedocs.io/>`__.
Transforming the RTL
--------------------
Building a chip requires specializing the generic verilog emitted by FIRRTL to adhere to the constraints imposed by the technology used for fabrication.
This includes mapping Chisel memories to available technology macros such as SRAMs, mapping the input and output of your chip to connect to technology IO cells, see :ref:`Barstools`.
In addition to these required transformations, it may also be beneficial to transform the RTL to make it more amenable to hierarchical physical design easier.
This often includes modifying the logical hierarchy to match the physical hierarchy through grouping components together or flattening components into a single larger module.
Modifying the logical hierarchy
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Building a large or complex chip often requires using hierarchical design to place and route sections of the chip separately.
In addition, the design as written in Chipyard may not have a hierarchy that matches the physical hierarchy that would work best in the place and route tool.
In order to reorganize the design to have its logical hierarchy match its physical hierarchy there are several FIRRTL transformations that can be run.
These include grouping, which pull several modules into a larger one, and flattening, which dissolves a modules boundary leaving its components in its containing module.
These transformations can be applied repeatedly to different parts of the design to arrange it as the physical designer sees fit.
More details on how to use these transformations to reorganize the design hierarchy are forthcoming.
Creating a floorplan
--------------------
An ASIC floorplan is a specification that the place-and-route tools will follow when placing instances in the design.
This includes the top-level chip dimensions, placement of SRAM macros, placement of custom (analog) circuits, IO cell placement, bump or wirebond pad placement, blockages, hierarchical boundaries, and pin placement.
Much of the design effort that goes into building a chip involves developing optimal floorplans for the instance of the design that is being manufactured.
Often this is a highly manual and iterative process which consumes much of the physical designer's time.
This cost becomes increasingly apparent as the parameterization space grows rapidly when using tools like Chisel- cycle times are hampered by the human labor
that is required to floorplan each instance of the design.
The Hammer team is actively developing methods of improving the agility of floorplanning for generator-based designs, like those that use Chisel.
The libraries we are developing will emit Hammer IR that can be passed directly to the Hammer tool without the need for human intervention.
Stay tuned for more information.
In the meantime, see the `Hammer Documentation <https://hammer-vlsi.readthedocs.io/>`__ for information on the Hammer IR floorplan API.
It is possible to write this IR directly, or to generate it using simple python scripts.
While we certainly look forward to having a more featureful toolkit, we have built many chips to date in this way.
Running the VLSI tool flow
--------------------------
For the full documentation on how to use the VLSI tool flow, see the `Hammer Documentation <https://hammer-vlsi.readthedocs.io/>`__.
For an example of how to use the VLSI in the context of Chipyard, see :ref:`ASAP7 Tutorial`.
.. Note:: Please refer to the other sections in VLSI for tools/flows on how to build a chip. This section will be filled in ASAP.

6
docs/_static/css/custom.css vendored Normal file
View File

@@ -0,0 +1,6 @@
.important {
font-size: 175%;
}
.important p{
font-size: 100%;
}

3
docs/conf.py
View File

@@ -106,6 +106,9 @@ html_theme_options = {
# relative to this directory. They are copied after the builtin static files,
# so a file named "default.css" will overwrite the builtin "default.css".
html_static_path = ['_static']
html_css_files = [
'css/custom.css',
]
# Custom sidebar templates, must be a dictionary that maps document names
# to template names.

7
docs/index.rst
View File

@@ -8,11 +8,10 @@ Welcome to Chipyard's documentation!
.. image:: ./_static/images/chipyard-logo.svg
Chipyard is a a framework for designing and evaluating full-system hardware using agile teams.
It is composed of a collection of tools and libraries designed to provide an intergration between open-source and commercial tools for the development of systems-on-chip.
New to Chipyard? Jump to the :ref:`Chipyard Basics` page for more info.
Chipyard is a framework for designing and evaluating full-system hardware using agile teams.
It is composed of a collection of tools and libraries designed to provide an integration between open-source and commercial tools for the development of systems-on-chip.
.. include:: Quick-Start.rst
.. IMPORTANT:: **New to Chipyard?** Jump to the :ref:`Initial Repository Setup` page for setup instructions.
Getting Help
------------

2
docs/requirements.txt
View File

@@ -1,4 +1,4 @@
Sphinx==1.7.4
Sphinx==1.8.5
Pygments==2.2.0
sphinx-autobuild
sphinx_rtd_theme==0.2.5b1

1
generators/ariane Submodule

Submodule generators/ariane added at d914fc8f03

2
generators/boom

Submodule generators/boom updated: 779c62c563...f0caca8d6b

0
generators/example/src/main/resources/vsrc/GCDMMIOBlackBox.v → generators/chipyard/src/main/resources/vsrc/GCDMMIOBlackBox.v
View File

121
generators/chipyard/src/main/scala/ChipTop.scala Normal file
View File

@@ -0,0 +1,121 @@
package chipyard
import chisel3._
import scala.collection.mutable.{ArrayBuffer}
import freechips.rocketchip.config.{Parameters, Field}
import freechips.rocketchip.diplomacy.{LazyModule}
import freechips.rocketchip.util.{ResetCatchAndSync}
import chipyard.config.ConfigValName._
import chipyard.iobinders.{IOBinders, TestHarnessFunction, IOBinderTuple}
import barstools.iocell.chisel._
case object BuildSystem extends Field[Parameters => LazyModule]((p: Parameters) => LazyModule(new DigitalTop()(p)))
/**
* Chipyard provides three baseline, top-level reset schemes, set using the
* [[GlobalResetSchemeKey]] in a Parameters instance. These are:
*
* 1) Synchronous: The input coming to the chip is synchronous to the provided
* clocks and will be used without modification as a synchronous reset.
* This is safe only for use in FireSim and SW simulation.
*
* 2) Asynchronous: The input reset is asynchronous to the input clock, but it
* is caught and synchronized to that clock before it is dissemenated.
* Thus, downsteam modules will be emitted with synchronously reset state
* elements.
*
* 3) Asynchronous Full: The input reset is asynchronous to the input clock,
* and is used globally as an async reset. Downstream modules will be emitted
* with asynchronously reset state elements.
*
*/
sealed trait GlobalResetScheme {
def pinIsAsync: Boolean
}
sealed trait HasAsyncInput { self: GlobalResetScheme =>
def pinIsAsync = true
}
sealed trait HasSyncInput { self: GlobalResetScheme =>
def pinIsAsync = false
}
case object GlobalResetSynchronous extends GlobalResetScheme with HasSyncInput
case object GlobalResetAsynchronous extends GlobalResetScheme with HasAsyncInput
case object GlobalResetAsynchronousFull extends GlobalResetScheme with HasAsyncInput
case object GlobalResetSchemeKey extends Field[GlobalResetScheme](GlobalResetSynchronous)
/**
* The base class used for building chips. This constructor instantiates a module specified by the BuildSystem parameter,
* named "system", which is an instance of DigitalTop by default. The default clock and reset for "system" are set by two
* wires, "systemClock" and "systemReset", which are intended to be driven by traits mixed-in with this base class.
*/
abstract class BaseChipTop()(implicit val p: Parameters) extends RawModule with HasTestHarnessFunctions {
// A publicly accessible list of IO cells (useful for a floorplanning tool, for example)
val iocells = ArrayBuffer.empty[IOCell]
// A list of functions to call in the test harness
val harnessFunctions = ArrayBuffer.empty[TestHarnessFunction]
// The system clock
// These are given so that IOCell can use DataMirror and generate ports with
// the right flow (Input/Output)
val systemClock = Wire(Input(Clock()))
val systemReset = Wire(Input(Reset()))
// The system module specified by BuildSystem
val lSystem = p(BuildSystem)(p).suggestName("system")
val system = withClockAndReset(systemClock, systemReset) { Module(lSystem.module) }
// Call all of the IOBinders and provide them with a default clock and reset
withClockAndReset(systemClock, systemReset) {
// Call each IOBinder on both the lazyModule instance and the module
// instance. Generally, an IOBinder PF should only be defined on one, so
// this should not lead to two invocations.
val (_ports, _iocells, _harnessFunctions) = p(IOBinders).values.flatMap(f => f(lSystem) ++ f(system)).unzip3
// We ignore _ports for now...
iocells ++= _iocells.flatten
harnessFunctions ++= _harnessFunctions.flatten
}
}
/**
* A simple clock and reset implementation that punches out clock and reset ports with the same
* names as the implicit clock and reset for standard Module classes. Three basic reset schemes
* are provided. See [[GlobalResetScheme]].
*/
trait HasChipTopSimpleClockAndReset { this: BaseChipTop =>
val (clock, systemClockIO) = IOCell.generateIOFromSignal(systemClock, Some("iocell_clock"))
val (reset, systemResetIO) = p(GlobalResetSchemeKey) match {
case GlobalResetSynchronous =>
IOCell.generateIOFromSignal(systemReset, Some("iocell_reset"))
case GlobalResetAsynchronousFull =>
IOCell.generateIOFromSignal(systemReset, Some("iocell_reset"), abstractResetAsAsync = true)
case GlobalResetAsynchronous =>
val asyncResetCore = Wire(Input(AsyncReset()))
systemReset := ResetCatchAndSync(systemClock, asyncResetCore.asBool)
IOCell.generateIOFromSignal(asyncResetCore, Some("iocell_reset"), abstractResetAsAsync = true)
}
iocells ++= systemClockIO
iocells ++= systemResetIO
// Add a TestHarnessFunction that connects clock and reset
harnessFunctions += { (th: TestHarness) => {
// Connect clock; it's not done implicitly with RawModule
clock := th.clock
// Connect reset; it's not done implicitly with RawModule
// Note that we need to use dutReset, not harnessReset
reset := th.dutReset
Nil
} }
}
class ChipTop()(implicit p: Parameters) extends BaseChipTop()(p)
with HasChipTopSimpleClockAndReset

154
generators/chipyard/src/main/scala/ConfigFragments.scala Normal file
View File

@@ -0,0 +1,154 @@
package chipyard.config
import chisel3._
import chisel3.util.{log2Up}
import freechips.rocketchip.config.{Field, Parameters, Config}
import freechips.rocketchip.subsystem.{SystemBusKey, RocketTilesKey, WithRoccExample, WithNMemoryChannels, WithNBigCores, WithRV32, CacheBlockBytes}
import freechips.rocketchip.diplomacy.{LazyModule, ValName}
import freechips.rocketchip.devices.tilelink.BootROMParams
import freechips.rocketchip.devices.debug.{Debug}
import freechips.rocketchip.tile.{XLen, BuildRoCC, TileKey, LazyRoCC, RocketTileParams, MaxHartIdBits}
import freechips.rocketchip.rocket.{RocketCoreParams, MulDivParams, DCacheParams, ICacheParams}
import freechips.rocketchip.util.{AsyncResetReg}
import boom.common.{BoomTilesKey}
import ariane.{ArianeTilesKey}
import testchipip._
import hwacha.{Hwacha}
import sifive.blocks.devices.gpio._
import sifive.blocks.devices.uart._
import sifive.blocks.devices.spi._
import chipyard.{BuildTop, BuildSystem}
/**
* TODO: Why do we need this?
*/
object ConfigValName {
implicit val valName = ValName("TestHarness")
}
import ConfigValName._
// -----------------------
// Common Config Fragments
// -----------------------
class WithBootROM extends Config((site, here, up) => {
case BootROMParams => BootROMParams(
contentFileName = s"./bootrom/bootrom.rv${site(XLen)}.img")
})
// DOC include start: gpio config fragment
class WithGPIO extends Config((site, here, up) => {
case PeripheryGPIOKey => Seq(
GPIOParams(address = 0x10012000, width = 4, includeIOF = false))
})
// DOC include end: gpio config fragment
class WithUART extends Config((site, here, up) => {
case PeripheryUARTKey => Seq(
UARTParams(address = 0x54000000L, nTxEntries = 256, nRxEntries = 256))
})
class WithSPIFlash(size: BigInt = 0x10000000) extends Config((site, here, up) => {
// Note: the default size matches freedom with the addresses below
case PeripherySPIFlashKey => Seq(
SPIFlashParams(rAddress = 0x10040000, fAddress = 0x20000000, fSize = size))
})
class WithL2TLBs(entries: Int) extends Config((site, here, up) => {
case RocketTilesKey => up(RocketTilesKey) map (tile => tile.copy(
core = tile.core.copy(nL2TLBEntries = entries)
))
case BoomTilesKey => up(BoomTilesKey) map (tile => tile.copy(
core = tile.core.copy(nL2TLBEntries = entries)
))
})
class WithTracegenSystem extends Config((site, here, up) => {
case BuildSystem => (p: Parameters) => LazyModule(new tracegen.TraceGenSystem()(p))
})
class WithRenumberHarts(rocketFirst: Boolean = false) extends Config((site, here, up) => {
case RocketTilesKey => up(RocketTilesKey, site).zipWithIndex map { case (r, i) =>
r.copy(hartId = i + (if(rocketFirst) 0 else up(BoomTilesKey, site).length))
}
case BoomTilesKey => up(BoomTilesKey, site).zipWithIndex map { case (b, i) =>
b.copy(hartId = i + (if(rocketFirst) up(RocketTilesKey, site).length else 0))
}
case MaxHartIdBits => log2Up(up(BoomTilesKey, site).size + up(RocketTilesKey, site).size)
})
/**
* Map from a hartId to a particular RoCC accelerator
*/
case object MultiRoCCKey extends Field[Map[Int, Seq[Parameters => LazyRoCC]]](Map.empty[Int, Seq[Parameters => LazyRoCC]])
/**
* Config fragment to enable different RoCCs based on the hartId
*/
class WithMultiRoCC extends Config((site, here, up) => {
case BuildRoCC => site(MultiRoCCKey).getOrElse(site(TileKey).hartId, Nil)
})
/**
* Config fragment to add Hwachas to cores based on hart
*
* For ex:
* Core 0, 1, 2, 3 have been defined earlier
* with hartIds of 0, 1, 2, 3 respectively
* And you call WithMultiRoCCHwacha(0,1)
* Then Core 0 and 1 will get a Hwacha
*
* @param harts harts to specify which will get a Hwacha
*/
class WithMultiRoCCHwacha(harts: Int*) extends Config((site, here, up) => {
case MultiRoCCKey => {
require(harts.max <= ((up(RocketTilesKey, site).length + up(BoomTilesKey, site).length) - 1))
up(MultiRoCCKey, site) ++ harts.distinct.map{ i =>
(i -> Seq((p: Parameters) => {
LazyModule(new Hwacha()(p)).suggestName("hwacha")
}))
}
}
})
/**
* Config fragment to add a small Rocket core to the system as a "control" core.
* Used as an example of a PMU core.
*/
class WithControlCore extends Config((site, here, up) => {
case RocketTilesKey => up(RocketTilesKey, site) :+
RocketTileParams(
core = RocketCoreParams(
useVM = false,
fpu = None,
mulDiv = Some(MulDivParams(mulUnroll = 8))),
btb = None,
dcache = Some(DCacheParams(
rowBits = site(SystemBusKey).beatBits,
nSets = 64,
nWays = 1,
nTLBEntries = 4,
nMSHRs = 0,
blockBytes = site(CacheBlockBytes))),
icache = Some(ICacheParams(
rowBits = site(SystemBusKey).beatBits,
nSets = 64,
nWays = 1,
nTLBEntries = 4,
blockBytes = site(CacheBlockBytes))),
hartId = up(RocketTilesKey, site).size + up(BoomTilesKey, site).size
)
case MaxHartIdBits => log2Up(up(RocketTilesKey, site).size + up(BoomTilesKey, site).size + 1)
})
class WithTraceIO extends Config((site, here, up) => {
case BoomTilesKey => up(BoomTilesKey) map (tile => tile.copy(trace = true))
case ArianeTilesKey => up(ArianeTilesKey) map (tile => tile.copy(trace = true))
case TracePortKey => Some(TracePortParams())
})

41
generators/chipyard/src/main/scala/DigitalTop.scala Normal file
View File

@@ -0,0 +1,41 @@
package chipyard
import chisel3._
import freechips.rocketchip.subsystem._
import freechips.rocketchip.system._
import freechips.rocketchip.config.Parameters
import freechips.rocketchip.devices.tilelink._
// ------------------------------------
// BOOM and/or Rocket Top Level Systems
// ------------------------------------
// DOC include start: DigitalTop
class DigitalTop(implicit p: Parameters) extends System
with testchipip.CanHaveTraceIO // Enables optionally adding trace IO
with testchipip.CanHaveBackingScratchpad // Enables optionally adding a backing scratchpad
with testchipip.CanHavePeripheryBlockDevice // Enables optionally adding the block device
with testchipip.CanHavePeripherySerial // Enables optionally adding the TSI serial-adapter and port
with sifive.blocks.devices.uart.HasPeripheryUART // Enables optionally adding the sifive UART
with sifive.blocks.devices.gpio.HasPeripheryGPIO // Enables optionally adding the sifive GPIOs
with sifive.blocks.devices.spi.HasPeripherySPIFlash // Enables optionally adding the sifive SPI flash controller
with icenet.CanHavePeripheryIceNIC // Enables optionally adding the IceNIC for FireSim
with chipyard.example.CanHavePeripheryInitZero // Enables optionally adding the initzero example widget
with chipyard.example.CanHavePeripheryGCD // Enables optionally adding the GCD example widget
with nvidia.blocks.dla.CanHavePeripheryNVDLA // Enables optionally having an NVDLA
{
override lazy val module = new DigitalTopModule(this)
}
class DigitalTopModule[+L <: DigitalTop](l: L) extends SystemModule(l)
with testchipip.CanHaveTraceIOModuleImp
with testchipip.CanHavePeripheryBlockDeviceModuleImp
with testchipip.CanHavePeripherySerialModuleImp
with sifive.blocks.devices.uart.HasPeripheryUARTModuleImp
with sifive.blocks.devices.gpio.HasPeripheryGPIOModuleImp
with sifive.blocks.devices.spi.HasPeripherySPIFlashModuleImp
with icenet.CanHavePeripheryIceNICModuleImp
with chipyard.example.CanHavePeripheryGCDModuleImp
with freechips.rocketchip.util.DontTouch
// DOC include end: DigitalTop

6
generators/chipyard/src/main/scala/Generator.scala Normal file
View File

@@ -0,0 +1,6 @@
package chipyard
import firrtl.options.{StageMain}
import chipyard.stage.ChipyardStage
object Generator extends StageMain(new ChipyardStage)

362
generators/chipyard/src/main/scala/IOBinders.scala Normal file
View File

@@ -0,0 +1,362 @@
package chipyard
package object iobinders {
import chisel3._
import chisel3.experimental.{Analog, IO}
import freechips.rocketchip.config.{Field, Config, Parameters}
import freechips.rocketchip.diplomacy.{LazyModule}
import freechips.rocketchip.devices.debug._
import freechips.rocketchip.subsystem._
import freechips.rocketchip.system.{SimAXIMem}
import freechips.rocketchip.util._
import sifive.blocks.devices.gpio._
import sifive.blocks.devices.uart._
import sifive.blocks.devices.spi._
import barstools.iocell.chisel._
import testchipip._
import icenet.{CanHavePeripheryIceNICModuleImp, SimNetwork, NicLoopback, NICKey}
import tracegen.{HasTraceGenTilesModuleImp}
import scala.reflect.{ClassTag}
// System for instantiating binders based
// on the scala type of the Target (_not_ its IO). This avoids needing to
// duplicate harnesses (essentially test harnesses) for each target.
// IOBinders is map between string representations of traits to the desired
// IO connection behavior for tops matching that trait. We use strings to enable
// composition and overriding of IOBinders, much like how normal Keys in the config
// system are used/ At elaboration, the testharness traverses this set of functions,
// and functions which match the type of the DigitalTop are evaluated.
// You can add your own binder by adding a new (key, fn) pair, typically by using
// the OverrideIOBinder or ComposeIOBinder macros
// DOC include start: IOBinders
// This type describes a function callable on the TestHarness instance. Its return type is unused.
type TestHarnessFunction = (chipyard.TestHarness) => Seq[Any]
// IOBinders will return a Seq of this tuple, which contains three fields:
// 1. A Seq containing all IO ports created by the IOBinder function
// 2. A Seq containing all IO cell modules created by the IOBinder function
// 3. An optional function to call inside the test harness (e.g. to connect the IOs)
type IOBinderTuple = (Seq[Data], Seq[IOCell], Option[TestHarnessFunction])
case object IOBinders extends Field[Map[String, (Any) => Seq[IOBinderTuple]]](
Map[String, (Any) => Seq[IOBinderTuple]]().withDefaultValue((Any) => Nil)
)
// This macro overrides previous matches on some Top mixin. This is useful for
// binders which drive IO, since those typically cannot be composed
class OverrideIOBinder[T](fn: => (T) => Seq[IOBinderTuple])(implicit tag: ClassTag[T]) extends Config((site, here, up) => {
case IOBinders => up(IOBinders, site) + (tag.runtimeClass.toString ->
((t: Any) => {
t match {
case system: T => fn(system)
case _ => Nil
}
})
)
})
// This macro composes with previous matches on some Top mixin. This is useful for
// annotation-like binders, since those can typically be composed
class ComposeIOBinder[T](fn: => (T) => Seq[IOBinderTuple])(implicit tag: ClassTag[T]) extends Config((site, here, up) => {
case IOBinders => up(IOBinders, site) + (tag.runtimeClass.toString ->
((t: Any) => {
t match {
case system: T => (up(IOBinders, site)(tag.runtimeClass.toString)(system)
++ fn(system))
case _ => Nil
}
})
)
})
// DOC include end: IOBinders
object AddIOCells {
/**
* Add IO cells to a SiFive GPIO devices and name the IO ports.
* @param gpios A Seq of GPIO port bundles
* @param genFn A callable function to generate a DigitalGPIOCell module to use
* @return Returns a tuple of (a 2D Seq of Analog IOs corresponding to individual GPIO pins; a 2D Seq of IOCell module references)
*/
def gpio(gpios: Seq[GPIOPortIO], genFn: () => DigitalGPIOCell = IOCell.genericGPIO): (Seq[Seq[Analog]], Seq[Seq[IOCell]]) = {
gpios.zipWithIndex.map({ case (gpio, i) =>
gpio.pins.zipWithIndex.map({ case (pin, j) =>
val g = IO(Analog(1.W)).suggestName(s"gpio_${i}_${j}")
val iocell = genFn().suggestName(s"iocell_gpio_${i}_${j}")
iocell.io.o := pin.o.oval
iocell.io.oe := pin.o.oe
iocell.io.ie := pin.o.ie
pin.i.ival := iocell.io.i
iocell.io.pad <> g
(g, iocell)
}).unzip
}).unzip
}
/**
* Add IO cells to a SiFive UART devices and name the IO ports.
* @param uartPins A Seq of UART port bundles
* @return Returns a tuple of (A Seq of top-level UARTPortIO IOs; a 2D Seq of IOCell module references)
*/
def uart(uartPins: Seq[UARTPortIO]): (Seq[UARTPortIO], Seq[Seq[IOCell]]) = {
uartPins.zipWithIndex.map({ case (u, i) =>
val (port, ios) = IOCell.generateIOFromSignal(u, Some(s"iocell_uart_${i}"))
port.suggestName(s"uart_${i}")
(port, ios)
}).unzip
}
/**
* Add IO cells to a SiFive SPI devices and name the IO ports.
* @param spiPins A Seq of SPI port bundles
* @param basename The base name for this port (defaults to "spi")
* @param genFn A callable function to generate a DigitalGPIOCell module to use
* @return Returns a tuple of (A Seq of top-level SPIChipIO IOs; a 2D Seq of IOCell module references)
*/
def spi(spiPins: Seq[SPIPortIO], basename: String = "spi", genFn: () => DigitalGPIOCell = IOCell.genericGPIO): (Seq[SPIChipIO], Seq[Seq[IOCell]]) = {
spiPins.zipWithIndex.map({ case (s, i) =>
val port = IO(new SPIChipIO(s.c.csWidth)).suggestName(s"${basename}_${i}")
val iocellBase = s"iocell_${basename}_${i}"
// SCK and CS are unidirectional outputs
val sckIOs = IOCell.generateFromSignal(s.sck, port.sck, Some(s"${iocellBase}_sck"))
val csIOs = IOCell.generateFromSignal(s.cs, port.cs, Some(s"${iocellBase}_cs"))
// DQ are bidirectional, so then need special treatment
val dqIOs = s.dq.zip(port.dq).zipWithIndex.map { case ((pin, ana), j) =>
val iocell = genFn().suggestName(s"${iocellBase}_dq_${j}")
iocell.io.o := pin.o
iocell.io.oe := pin.oe
iocell.io.ie := true.B
pin.i := iocell.io.i
iocell.io.pad <> ana
iocell
}
(port, dqIOs ++ csIOs ++ sckIOs)
}).unzip
}
/**
* Add IO cells to a debug module and name the IO ports.
* @param psd A PSDIO bundle
* @param resetctrlOpt An optional ResetCtrlIO bundle
* @param debugOpt An optional DebugIO bundle
* @return Returns a tuple3 of (Top-level PSDIO IO; Optional top-level DebugIO IO; a list of IOCell module references)
*/
def debug(psd: PSDIO, resetctrlOpt: Option[ResetCtrlIO], debugOpt: Option[DebugIO])(implicit p: Parameters):
(PSDIO, Option[ResetCtrlIO], Option[DebugIO], Seq[IOCell]) = {
val (psdPort, psdIOs) = IOCell.generateIOFromSignal(
psd, Some("iocell_psd"), abstractResetAsAsync = p(GlobalResetSchemeKey).pinIsAsync)
val debugTuple = debugOpt.map(d =>
IOCell.generateIOFromSignal(d, Some("iocell_debug"), abstractResetAsAsync = p(GlobalResetSchemeKey).pinIsAsync))
val debugPortOpt: Option[DebugIO] = debugTuple.map(_._1)
val debugIOs: Seq[IOCell] = debugTuple.map(_._2).toSeq.flatten
debugPortOpt.foreach(_.suggestName("debug"))
val resetctrlTuple = resetctrlOpt.map(d =>
IOCell.generateIOFromSignal(d, Some("iocell_resetctrl"), abstractResetAsAsync = p(GlobalResetSchemeKey).pinIsAsync))
val resetctrlPortOpt: Option[ResetCtrlIO] = resetctrlTuple.map(_._1)
val resetctrlIOs: Seq[IOCell] = resetctrlTuple.map(_._2).toSeq.flatten
resetctrlPortOpt.foreach(_.suggestName("resetctrl"))
psdPort.suggestName("psd")
(psdPort, resetctrlPortOpt, debugPortOpt, psdIOs ++ debugIOs ++ resetctrlIOs)
}
/**
* Add IO cells to a serial module and name the IO ports.
* @param serial A SerialIO bundle
* @return Returns a tuple of (Top-level SerialIO IO; a list of IOCell module references)
*/
def serial(serial: SerialIO): (SerialIO, Seq[IOCell]) = {
val (port, ios) = IOCell.generateIOFromSignal(serial, Some("iocell_serial"))
port.suggestName("serial")
(port, ios)
}
}
// DOC include start: WithGPIOTiedOff
class WithGPIOTiedOff extends OverrideIOBinder({
(system: HasPeripheryGPIOModuleImp) => {
val (ports2d, ioCells2d) = AddIOCells.gpio(system.gpio)
val harnessFn = (th: chipyard.TestHarness) => { ports2d.flatten.foreach(_ <> AnalogConst(0)); Nil }
Seq((ports2d.flatten, ioCells2d.flatten, Some(harnessFn)))
}
})
// DOC include end: WithGPIOTiedOff
class WithUARTAdapter extends OverrideIOBinder({
(system: HasPeripheryUARTModuleImp) => {
val (ports, ioCells2d) = AddIOCells.uart(system.uart)
val harnessFn = (th: chipyard.TestHarness) => { UARTAdapter.connect(ports)(system.p); Nil }
Seq((ports, ioCells2d.flatten, Some(harnessFn)))
}
})
class WithSimSPIFlashModel(rdOnly: Boolean = true) extends OverrideIOBinder({
(system: HasPeripherySPIFlashModuleImp) => {
val (ports, ioCells2d) = AddIOCells.spi(system.qspi, "qspi")
val harnessFn = (th: chipyard.TestHarness) => { SimSPIFlashModel.connect(ports, th.reset, rdOnly)(system.p); Nil }
Seq((ports, ioCells2d.flatten, Some(harnessFn)))
}
})
class WithSimBlockDevice extends OverrideIOBinder({
(system: CanHavePeripheryBlockDeviceModuleImp) => system.connectSimBlockDevice(system.clock, system.reset.asBool); Nil
})
class WithBlockDeviceModel extends OverrideIOBinder({
(system: CanHavePeripheryBlockDeviceModuleImp) => system.connectBlockDeviceModel(); Nil
})
class WithLoopbackNIC extends OverrideIOBinder({
(system: CanHavePeripheryIceNICModuleImp) => system.connectNicLoopback(); Nil
})
class WithSimNIC extends OverrideIOBinder({
(system: CanHavePeripheryIceNICModuleImp) => system.connectSimNetwork(system.clock, system.reset.asBool); Nil
})
// Note: The parameters instance is accessible only through the BaseSubsystem
// or some parent class (IsAttachable, BareSubsystem -> LazyModule). The
// self-type requirement in CanHaveMasterAXI4MemPort is insufficient to make it
// accessible to the IOBinder
// DOC include start: WithSimAXIMem
class WithSimAXIMem extends OverrideIOBinder({
(system: CanHaveMasterAXI4MemPort with BaseSubsystem) => SimAXIMem.connectMem(system)(system.p); Nil
})
// DOC include end: WithSimAXIMem
class WithBlackBoxSimMem extends OverrideIOBinder({
(system: CanHaveMasterAXI4MemPort with BaseSubsystem) => {
(system.mem_axi4 zip system.memAXI4Node.in).foreach { case (io, (_, edge)) =>
val memSize = system.p(ExtMem).get.master.size
val lineSize = system.p(CacheBlockBytes)
val mem = Module(new SimDRAM(memSize, lineSize, edge.bundle))
mem.io.axi <> io
mem.io.clock := system.module.clock
mem.io.reset := system.module.reset
}
Nil
}
})
class WithSimAXIMMIO extends OverrideIOBinder({
(system: CanHaveMasterAXI4MMIOPort with BaseSubsystem) => SimAXIMem.connectMMIO(system)(system.p); Nil
})
class WithDontTouchPorts extends OverrideIOBinder({
(system: DontTouch) => system.dontTouchPorts(); Nil
})
class WithTieOffInterrupts extends OverrideIOBinder({
(system: HasExtInterruptsModuleImp) => {
val (port, ioCells) = IOCell.generateIOFromSignal(system.interrupts, Some("iocell_interrupts"))
port.suggestName("interrupts")
val harnessFn = (th: chipyard.TestHarness) => { port := 0.U; Nil }
Seq((Seq(port), ioCells, Some(harnessFn)))
}
})
class WithTieOffL2FBusAXI extends OverrideIOBinder({
(system: CanHaveSlaveAXI4Port with BaseSubsystem) => {
system.l2_frontend_bus_axi4.foreach(axi => {
axi.tieoff()
experimental.DataMirror.directionOf(axi.ar.ready) match {
case ActualDirection.Input =>
axi.r.bits := DontCare
axi.b.bits := DontCare
case ActualDirection.Output =>
axi.aw.bits := DontCare
axi.ar.bits := DontCare
axi.w.bits := DontCare
case _ => throw new Exception("Unknown AXI port direction")
}
})
Nil
}
})
class WithTiedOffDebug extends OverrideIOBinder({
(system: HasPeripheryDebugModuleImp) => {
val (psdPort, resetctrlOpt, debugPortOpt, ioCells) =
AddIOCells.debug(system.psd, system.resetctrl, system.debug)(system.p)
val harnessFn = (th: chipyard.TestHarness) => {
Debug.tieoffDebug(debugPortOpt, resetctrlOpt, Some(psdPort))(system.p)
// tieoffDebug doesn't actually tie everything off :/
debugPortOpt.foreach { d =>
d.clockeddmi.foreach({ cdmi => cdmi.dmi.req.bits := DontCare; cdmi.dmiClock := th.clock })
d.dmactiveAck := DontCare
d.clock := th.clock
}
Nil
}
Seq((Seq(psdPort) ++ resetctrlOpt ++ debugPortOpt.toSeq, Nil, Some(harnessFn)))
}
})
class WithSimDebug extends OverrideIOBinder({
(system: HasPeripheryDebugModuleImp) => {
val (psdPort, resetctrlPortOpt, debugPortOpt, ioCells) =
AddIOCells.debug(system.psd, system.resetctrl, system.debug)(system.p)
val harnessFn = (th: chipyard.TestHarness) => {
val dtm_success = Wire(Bool())
Debug.connectDebug(debugPortOpt, resetctrlPortOpt, psdPort, th.clock, th.harnessReset, dtm_success)(system.p)
when (dtm_success) { th.success := true.B }
th.dutReset := th.harnessReset | debugPortOpt.map { debug => AsyncResetReg(debug.ndreset).asBool }.getOrElse(false.B)
Nil
}
Seq((Seq(psdPort) ++ debugPortOpt.toSeq, ioCells, Some(harnessFn)))
}
})
class WithTiedOffSerial extends OverrideIOBinder({
(system: CanHavePeripherySerialModuleImp) => system.serial.map({ serial =>
val (port, ioCells) = AddIOCells.serial(serial)
val harnessFn = (th: chipyard.TestHarness) => {
SerialAdapter.tieoff(port)
Nil
}
Seq((Seq(port), ioCells, Some(harnessFn)))
}).getOrElse(Nil)
})
class WithSimSerial extends OverrideIOBinder({
(system: CanHavePeripherySerialModuleImp) => system.serial.map({ serial =>
val (port, ioCells) = AddIOCells.serial(serial)
val harnessFn = (th: chipyard.TestHarness) => {
val ser_success = SerialAdapter.connectSimSerial(port, th.clock, th.harnessReset)
when (ser_success) { th.success := true.B }
Nil
}
Seq((Seq(port), ioCells, Some(harnessFn)))
}).getOrElse(Nil)
})
class WithTraceGenSuccessBinder extends OverrideIOBinder({
(system: HasTraceGenTilesModuleImp) => {
val (successPort, ioCells) = IOCell.generateIOFromSignal(system.success, Some("iocell_success"))
successPort.suggestName("success")
val harnessFn = (th: chipyard.TestHarness) => { when (successPort) { th.success := true.B }; Nil }
Seq((Seq(successPort), ioCells, Some(harnessFn)))
}
})
class WithSimDromajoBridge extends ComposeIOBinder({
(system: CanHaveTraceIOModuleImp) => {
system.traceIO match { case Some(t) => t.traces.map(tileTrace => SimDromajoBridge(tileTrace)(system.p)) }
Nil
}
})
} /* end package object */

40
generators/utilities/src/main/scala/Subsystem.scala → generators/chipyard/src/main/scala/Subsystem.scala
View File

@@ -3,7 +3,7 @@
// All Rights Reserved. See LICENSE and LICENSE.SiFive for license details.
//------------------------------------------------------------------------------
package utilities
package chipyard
import chisel3._
import chisel3.internal.sourceinfo.{SourceInfo}
@@ -22,24 +22,28 @@ import freechips.rocketchip.subsystem._
import freechips.rocketchip.amba.axi4._
import boom.common.{BoomTile, BoomTilesKey, BoomCrossingKey, BoomTileParams}
import ariane.{ArianeTile, ArianeTilesKey, ArianeCrossingKey, ArianeTileParams}
import testchipip.{DromajoHelper}
trait HasBoomAndRocketTiles extends HasTiles
trait HasChipyardTiles extends HasTiles
with CanHavePeripheryPLIC
with CanHavePeripheryCLINT
with HasPeripheryDebug
{ this: BaseSubsystem =>
val module: HasBoomAndRocketTilesModuleImp
val module: HasChipyardTilesModuleImp
protected val rocketTileParams = p(RocketTilesKey)
protected val boomTileParams = p(BoomTilesKey)
protected val arianeTileParams = p(ArianeTilesKey)
// crossing can either be per tile or global (aka only 1 crossing specified)
private val rocketCrossings = perTileOrGlobalSetting(p(RocketCrossingKey), rocketTileParams.size)
private val boomCrossings = perTileOrGlobalSetting(p(BoomCrossingKey), boomTileParams.size)
private val arianeCrossings = perTileOrGlobalSetting(p(ArianeCrossingKey), arianeTileParams.size)
val allTilesInfo = (rocketTileParams ++ boomTileParams) zip (rocketCrossings ++ boomCrossings)
val allTilesInfo = (rocketTileParams ++ boomTileParams ++ arianeTileParams) zip (rocketCrossings ++ boomCrossings ++ arianeCrossings)
// Make a tile and wire its nodes into the system,
// according to the specified type of clock crossing.
@@ -50,22 +54,20 @@ trait HasBoomAndRocketTiles extends HasTiles
// TODO: investigate why
val tiles = allTilesInfo.sortWith(_._1.hartId < _._1.hartId).map {
case (param, crossing) => {
val (tile, rocketLogicalTree) = param match {
val tile = param match {
case r: RocketTileParams => {
val t = LazyModule(new RocketTile(r, crossing, PriorityMuxHartIdFromSeq(rocketTileParams), logicalTreeNode))
(t, t.rocketLogicalTree)
LazyModule(new RocketTile(r, crossing, PriorityMuxHartIdFromSeq(rocketTileParams), logicalTreeNode))
}
case b: BoomTileParams => {
val t = LazyModule(new BoomTile(b, crossing, PriorityMuxHartIdFromSeq(boomTileParams), logicalTreeNode))
(t, t.rocketLogicalTree) // TODO FIX rocketLogicalTree is not a member of the superclass, both child classes define it separately
LazyModule(new BoomTile(b, crossing, PriorityMuxHartIdFromSeq(boomTileParams), logicalTreeNode))
}
case a: ArianeTileParams => {
LazyModule(new ArianeTile(a, crossing, PriorityMuxHartIdFromSeq(arianeTileParams), logicalTreeNode))
}
}
connectMasterPortsToSBus(tile, crossing)
connectSlavePortsToCBus(tile, crossing)
def treeNode: RocketTileLogicalTreeNode = new RocketTileLogicalTreeNode(rocketLogicalTree.getOMInterruptTargets)
LogicalModuleTree.add(logicalTreeNode, rocketLogicalTree)
connectInterrupts(tile, debugOpt, clintOpt, plicOpt)
tile
@@ -79,14 +81,14 @@ trait HasBoomAndRocketTiles extends HasTiles
}.toList
}
trait HasBoomAndRocketTilesModuleImp extends HasTilesModuleImp
trait HasChipyardTilesModuleImp extends HasTilesModuleImp
with HasPeripheryDebugModuleImp
{
val outer: HasBoomAndRocketTiles
val outer: HasChipyardTiles
}
class Subsystem(implicit p: Parameters) extends BaseSubsystem
with HasBoomAndRocketTiles
with HasChipyardTiles
{
override lazy val module = new SubsystemModuleImp(this)
@@ -95,7 +97,7 @@ class Subsystem(implicit p: Parameters) extends BaseSubsystem
class SubsystemModuleImp[+L <: Subsystem](_outer: L) extends BaseSubsystemModuleImp(_outer)
with HasResetVectorWire
with HasBoomAndRocketTilesModuleImp
with HasChipyardTilesModuleImp
{
tile_inputs.zip(outer.hartIdList).foreach { case(wire, i) =>
wire.hartid := i.U
@@ -104,4 +106,8 @@ class SubsystemModuleImp[+L <: Subsystem](_outer: L) extends BaseSubsystemModule
// create file with boom params
ElaborationArtefacts.add("""core.config""", outer.tiles.map(x => x.module.toString).mkString("\n"))
// Generate C header with relevant information for Dromajo
// This is included in the `dromajo_params.h` header file
DromajoHelper.addArtefacts
}

6
generators/utilities/src/main/scala/System.scala → generators/chipyard/src/main/scala/System.scala
View File

@@ -3,7 +3,7 @@
// All Rights Reserved. See LICENSE and LICENSE.SiFive for license details.
//------------------------------------------------------------------------------
package utilities
package chipyard
import chisel3._
@@ -22,7 +22,6 @@ import freechips.rocketchip.util.{DontTouch}
* Base top with periphery devices and ports, and a BOOM + Rocket subsystem
*/
class System(implicit p: Parameters) extends Subsystem
with HasHierarchicalBusTopology
with HasAsyncExtInterrupts
with CanHaveMasterAXI4MemPort
with CanHaveMasterAXI4MMIOPort
@@ -38,8 +37,5 @@ class System(implicit p: Parameters) extends Subsystem
class SystemModule[+L <: System](_outer: L) extends SubsystemModuleImp(_outer)
with HasRTCModuleImp
with HasExtInterruptsModuleImp
with CanHaveMasterAXI4MemPortModuleImp
with CanHaveMasterAXI4MMIOPortModuleImp
with CanHaveSlaveAXI4PortModuleImp
with HasPeripheryBootROMModuleImp
with DontTouch

37
generators/chipyard/src/main/scala/TestHarness.scala Normal file
View File

@@ -0,0 +1,37 @@
package chipyard
import chisel3._
import freechips.rocketchip.diplomacy.{LazyModule}
import freechips.rocketchip.config.{Field, Parameters}
import chipyard.iobinders.{TestHarnessFunction}
import chipyard.config.ConfigValName._
// -------------------------------
// BOOM and/or Rocket Test Harness
// -------------------------------
case object BuildTop extends Field[Parameters => HasTestHarnessFunctions]((p: Parameters) => Module(new ChipTop()(p)))
trait HasTestHarnessFunctions {
val harnessFunctions: Seq[TestHarnessFunction]
}
class TestHarness(implicit val p: Parameters) extends Module {
val io = IO(new Bundle {
val success = Output(Bool())
})
val dut = p(BuildTop)(p)
io.success := false.B
// dutReset assignment can be overridden via a harnessFunction, but by default it is just reset
val dutReset = WireDefault(if (p(GlobalResetSchemeKey).pinIsAsync) reset.asAsyncReset else reset)
dut.harnessFunctions.foreach(_(this))
def success = io.success
def harnessReset = this.reset.asBool
}

184
generators/chipyard/src/main/scala/TestSuites.scala Normal file
View File

@@ -0,0 +1,184 @@
package chipyard
import scala.collection.mutable.{LinkedHashSet}
import freechips.rocketchip.subsystem.{RocketTilesKey}
import freechips.rocketchip.tile.{XLen}
import freechips.rocketchip.config.{Parameters}
import freechips.rocketchip.system.{TestGeneration, RegressionTestSuite, RocketTestSuite}
import boom.common.{BoomTilesKey}
import ariane.{ArianeTilesKey}
/**
* A set of pre-chosen regression tests
*/
object RegressionTestSuites
{
val rv64RegrTestNames = LinkedHashSet(
"rv64ud-v-fcvt",
"rv64ud-p-fdiv",
"rv64ud-v-fadd",
"rv64uf-v-fadd",
"rv64um-v-mul",
"rv64mi-p-breakpoint",
"rv64uc-v-rvc",
"rv64ud-v-structural",
"rv64si-p-wfi",
"rv64um-v-divw",
"rv64ua-v-lrsc",
"rv64ui-v-fence_i",
"rv64ud-v-fcvt_w",
"rv64uf-v-fmin",
"rv64ui-v-sb",
"rv64ua-v-amomax_d",
"rv64ud-v-move",
"rv64ud-v-fclass",
"rv64ua-v-amoand_d",
"rv64ua-v-amoxor_d",
"rv64si-p-sbreak",
"rv64ud-v-fmadd",
"rv64uf-v-ldst",
"rv64um-v-mulh",
"rv64si-p-dirty")
val rv32RegrTestNames = LinkedHashSet(
"rv32mi-p-ma_addr",
"rv32mi-p-csr",
"rv32ui-p-sh",
"rv32ui-p-lh",
"rv32uc-p-rvc",
"rv32mi-p-sbreak",
"rv32ui-p-sll")
}
/**
* Helper functions to add BOOM or Rocket tests
*/
class TestSuiteHelper
{
import freechips.rocketchip.system.DefaultTestSuites._
import RegressionTestSuites._
val suites = collection.mutable.ListMap[String, RocketTestSuite]()
def addSuite(s: RocketTestSuite) { suites += (s.makeTargetName -> s) }
def addSuites(s: Seq[RocketTestSuite]) { s.foreach(addSuite) }
/**
* Add BOOM tests (asm, bmark, regression)
*/
def addBoomTestSuites(implicit p: Parameters) = {
val xlen = p(XLen)
p(BoomTilesKey).find(_.hartId == 0).map { tileParams =>
val coreParams = tileParams.core
val vm = coreParams.useVM
val env = if (vm) List("p","v") else List("p")
coreParams.fpu foreach { case cfg =>
if (xlen == 32) {
addSuites(env.map(rv32uf))
if (cfg.fLen >= 64) {
addSuites(env.map(rv32ud))
}
} else if (cfg.fLen >= 64) {
addSuites(env.map(rv64ud))
addSuites(env.map(rv64uf))
addSuite(rv32udBenchmarks)
}
}
if (coreParams.useAtomics) {
if (tileParams.dcache.flatMap(_.scratch).isEmpty) {
addSuites(env.map(if (xlen == 64) rv64ua else rv32ua))
} else {
addSuites(env.map(if (xlen == 64) rv64uaSansLRSC else rv32uaSansLRSC))
}
}
if (coreParams.useCompressed) addSuites(env.map(if (xlen == 64) rv64uc else rv32uc))
val (rvi, rvu) =
if (xlen == 64) ((if (vm) rv64i else rv64pi), rv64u)
else ((if (vm) rv32i else rv32pi), rv32u)
addSuites(rvi.map(_("p")))
addSuites(rvu.map(_("p")))
addSuites((if (vm) List("v") else List()).flatMap(env => rvu.map(_(env))))
addSuite(benchmarks)
addSuite(new RegressionTestSuite(if (xlen == 64) rv64RegrTestNames else rv32RegrTestNames))
}
}
/**
* Add Rocket tests (asm, bmark, regression)
*/
def addRocketTestSuites(implicit p: Parameters) = {
val xlen = p(XLen)
p(RocketTilesKey).find(_.hartId == 0).map { tileParams =>
val coreParams = tileParams.core
val vm = coreParams.useVM
val env = if (vm) List("p","v") else List("p")
coreParams.fpu foreach { case cfg =>
if (xlen == 32) {
addSuites(env.map(rv32uf))
if (cfg.fLen >= 64)
addSuites(env.map(rv32ud))
} else {
addSuite(rv32udBenchmarks)
addSuites(env.map(rv64uf))
if (cfg.fLen >= 64)
addSuites(env.map(rv64ud))
}
}
if (coreParams.useAtomics) {
if (tileParams.dcache.flatMap(_.scratch).isEmpty)
addSuites(env.map(if (xlen == 64) rv64ua else rv32ua))
else
addSuites(env.map(if (xlen == 64) rv64uaSansLRSC else rv32uaSansLRSC))
}
if (coreParams.useCompressed) addSuites(env.map(if (xlen == 64) rv64uc else rv32uc))
val (rvi, rvu) =
if (xlen == 64) ((if (vm) rv64i else rv64pi), rv64u)
else ((if (vm) rv32i else rv32pi), rv32u)
addSuites(rvi.map(_("p")))
addSuites((if (vm) List("v") else List()).flatMap(env => rvu.map(_(env))))
addSuite(benchmarks)
addSuite(new RegressionTestSuite(if (xlen == 64) rv64RegrTestNames else rv32RegrTestNames))
}
}
/**
* Add Ariane tests (asm, bmark, regression)
*/
def addArianeTestSuites(implicit p: Parameters) = {
val xlen = p(XLen)
p(ArianeTilesKey).find(_.hartId == 0).map { tileParams =>
val coreParams = tileParams.core
val vm = coreParams.useVM
val env = if (vm) List("p","v") else List("p")
coreParams.fpu foreach { case cfg =>
if (xlen == 32) {
addSuites(env.map(rv32uf))
if (cfg.fLen >= 64)
addSuites(env.map(rv32ud))
} else {
addSuite(rv32udBenchmarks)
addSuites(env.map(rv64uf))
if (cfg.fLen >= 64)
addSuites(env.map(rv64ud))
}
}
if (coreParams.useAtomics) {
if (tileParams.dcache.flatMap(_.scratch).isEmpty)
addSuites(env.map(if (xlen == 64) rv64ua else rv32ua))
else
addSuites(env.map(if (xlen == 64) rv64uaSansLRSC else rv32uaSansLRSC))
}
if (coreParams.useCompressed) addSuites(env.map(if (xlen == 64) rv64uc else rv32uc))
val (rvi, rvu) =
if (xlen == 64) ((if (vm) rv64i else rv64pi), rv64u)
else ((if (vm) rv32i else rv32pi), rv32u)
addSuites(rvi.map(_("p")))
addSuites((if (vm) List("v") else List()).flatMap(env => rvu.map(_(env))))
addSuite(benchmarks)
addSuite(new RegressionTestSuite(if (xlen == 64) rv64RegrTestNames else rv32RegrTestNames))
}
}
}

42
generators/chipyard/src/main/scala/config/ArianeConfigs.scala Normal file
View File

@@ -0,0 +1,42 @@
package chipyard
import chisel3._
import freechips.rocketchip.config.{Config}
// ---------------------
// Ariane Configs
// ---------------------
class ArianeConfig extends Config(
new chipyard.iobinders.WithUARTAdapter ++ // display UART with a SimUARTAdapter
new chipyard.iobinders.WithTieOffInterrupts ++ // tie off top-level interrupts
new chipyard.iobinders.WithSimAXIMem ++ // drive the master AXI4 memory with a SimAXIMem
new chipyard.iobinders.WithTiedOffDebug ++ // tie off debug (since we are using SimSerial for testing)
new chipyard.iobinders.WithSimSerial ++ // drive TSI with SimSerial for testing
new testchipip.WithTSI ++ // use testchipip serial offchip link
new chipyard.config.WithBootROM ++ // use default bootrom
new chipyard.config.WithUART ++ // add a UART
new freechips.rocketchip.subsystem.WithNoMMIOPort ++ // no top-level MMIO master port (overrides default set in rocketchip)
new freechips.rocketchip.subsystem.WithNoSlavePort ++ // no top-level MMIO slave port (overrides default set in rocketchip)
new freechips.rocketchip.subsystem.WithInclusiveCache ++ // use Sifive L2 cache
new freechips.rocketchip.subsystem.WithNExtTopInterrupts(0) ++ // no external interrupts
new ariane.WithNArianeCores(1) ++ // single Ariane core
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++ // hierarchical buses including mbus+l2
new freechips.rocketchip.system.BaseConfig) // "base" rocketchip system
class dmiArianeConfig extends Config(
new chipyard.iobinders.WithUARTAdapter ++
new chipyard.iobinders.WithTieOffInterrupts ++
new chipyard.iobinders.WithSimAXIMem ++
new chipyard.iobinders.WithTiedOffSerial ++
new chipyard.iobinders.WithSimDebug ++ // add SimDebug and use it to drive simulation
new chipyard.config.WithBootROM ++
new chipyard.config.WithUART ++
new freechips.rocketchip.subsystem.WithNoMMIOPort ++
new freechips.rocketchip.subsystem.WithNoSlavePort ++
new freechips.rocketchip.subsystem.WithInclusiveCache ++
new freechips.rocketchip.subsystem.WithNExtTopInterrupts(0) ++
new ariane.WithNArianeCores(1) ++
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++
new freechips.rocketchip.system.BaseConfig)

186
generators/chipyard/src/main/scala/config/BoomConfigs.scala Normal file
View File

@@ -0,0 +1,186 @@
package chipyard
import freechips.rocketchip.config.{Config}
// ---------------------
// BOOM Configs
// ---------------------
class SmallBoomConfig extends Config(
new chipyard.iobinders.WithUARTAdapter ++ // display UART with a SimUARTAdapter
new chipyard.iobinders.WithTieOffInterrupts ++ // tie off top-level interrupts
new chipyard.iobinders.WithBlackBoxSimMem ++ // drive the master AXI4 memory with a SimAXIMem
new chipyard.iobinders.WithTiedOffDebug ++ // tie off debug (since we are using SimSerial for testing)
new chipyard.iobinders.WithSimSerial ++ // drive TSI with SimSerial for testing
new testchipip.WithTSI ++ // use testchipip serial offchip link
new chipyard.config.WithBootROM ++ // use default bootrom
new chipyard.config.WithUART ++ // add a UART
new chipyard.config.WithL2TLBs(1024) ++ // use L2 TLBs
new freechips.rocketchip.subsystem.WithNoMMIOPort ++ // no top-level MMIO master port (overrides default set in rocketchip)
new freechips.rocketchip.subsystem.WithNoSlavePort ++ // no top-level MMIO slave port (overrides default set in rocketchip)
new freechips.rocketchip.subsystem.WithInclusiveCache ++ // use Sifive L2 cache
new freechips.rocketchip.subsystem.WithNExtTopInterrupts(0) ++ // no external interrupts
new boom.common.WithSmallBooms ++ // small boom config
new boom.common.WithNBoomCores(1) ++ // single-core boom
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++ // hierarchical buses including mbus+l2
new freechips.rocketchip.system.BaseConfig) // "base" rocketchip system
class MediumBoomConfig extends Config(
new chipyard.iobinders.WithUARTAdapter ++
new chipyard.iobinders.WithTieOffInterrupts ++
new chipyard.iobinders.WithBlackBoxSimMem ++
new chipyard.iobinders.WithTiedOffDebug ++
new chipyard.iobinders.WithSimSerial ++
new testchipip.WithTSI ++
new chipyard.config.WithBootROM ++
new chipyard.config.WithUART ++
new chipyard.config.WithL2TLBs(1024) ++
new freechips.rocketchip.subsystem.WithNoMMIOPort ++
new freechips.rocketchip.subsystem.WithNoSlavePort ++
new freechips.rocketchip.subsystem.WithInclusiveCache ++
new freechips.rocketchip.subsystem.WithNExtTopInterrupts(0) ++
new boom.common.WithMediumBooms ++ // medium boom config
new boom.common.WithNBoomCores(1) ++
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++
new freechips.rocketchip.system.BaseConfig)
class LargeBoomConfig extends Config(
new chipyard.iobinders.WithUARTAdapter ++
new chipyard.iobinders.WithTieOffInterrupts ++
new chipyard.iobinders.WithBlackBoxSimMem ++
new chipyard.iobinders.WithTiedOffDebug ++
new chipyard.iobinders.WithSimSerial ++
new testchipip.WithTSI ++
new chipyard.config.WithBootROM ++
new chipyard.config.WithUART ++
new chipyard.config.WithL2TLBs(1024) ++
new freechips.rocketchip.subsystem.WithNoMMIOPort ++
new freechips.rocketchip.subsystem.WithNoSlavePort ++
new freechips.rocketchip.subsystem.WithInclusiveCache ++
new freechips.rocketchip.subsystem.WithNExtTopInterrupts(0) ++
new boom.common.WithLargeBooms ++ // large boom config
new boom.common.WithNBoomCores(1) ++
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++
new freechips.rocketchip.system.BaseConfig)
class MegaBoomConfig extends Config(
new chipyard.iobinders.WithUARTAdapter ++
new chipyard.iobinders.WithTieOffInterrupts ++
new chipyard.iobinders.WithBlackBoxSimMem ++
new chipyard.iobinders.WithTiedOffDebug ++
new chipyard.iobinders.WithSimSerial ++
new testchipip.WithTSI ++
new chipyard.config.WithBootROM ++
new chipyard.config.WithUART ++
new chipyard.config.WithL2TLBs(1024) ++
new freechips.rocketchip.subsystem.WithNoMMIOPort ++
new freechips.rocketchip.subsystem.WithNoSlavePort ++
new freechips.rocketchip.subsystem.WithInclusiveCache ++
new freechips.rocketchip.subsystem.WithNExtTopInterrupts(0) ++
new boom.common.WithMegaBooms ++ // mega boom config
new boom.common.WithNBoomCores(1) ++
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++
new freechips.rocketchip.system.BaseConfig)
class DualSmallBoomConfig extends Config(
new chipyard.iobinders.WithUARTAdapter ++
new chipyard.iobinders.WithTieOffInterrupts ++
new chipyard.iobinders.WithBlackBoxSimMem ++
new chipyard.iobinders.WithTiedOffDebug ++
new chipyard.iobinders.WithSimSerial ++
new testchipip.WithTSI ++
new chipyard.config.WithBootROM ++
new chipyard.config.WithUART ++
new chipyard.config.WithL2TLBs(1024) ++
new freechips.rocketchip.subsystem.WithNoMMIOPort ++
new freechips.rocketchip.subsystem.WithNoSlavePort ++
new freechips.rocketchip.subsystem.WithInclusiveCache ++
new freechips.rocketchip.subsystem.WithNExtTopInterrupts(0) ++
new boom.common.WithSmallBooms ++
new boom.common.WithNBoomCores(2) ++ // 2 boom cores
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++
new freechips.rocketchip.system.BaseConfig)
class SmallRV32BoomConfig extends Config(
new chipyard.iobinders.WithUARTAdapter ++
new chipyard.iobinders.WithTieOffInterrupts ++
new chipyard.iobinders.WithBlackBoxSimMem ++
new chipyard.iobinders.WithTiedOffDebug ++
new chipyard.iobinders.WithSimSerial ++
new testchipip.WithTSI ++
new chipyard.config.WithBootROM ++
new chipyard.config.WithUART ++
new chipyard.config.WithL2TLBs(1024) ++
new freechips.rocketchip.subsystem.WithNoMMIOPort ++
new freechips.rocketchip.subsystem.WithNoSlavePort ++
new freechips.rocketchip.subsystem.WithInclusiveCache ++
new freechips.rocketchip.subsystem.WithNExtTopInterrupts(0) ++
new boom.common.WithoutBoomFPU ++ // no fp
new boom.common.WithBoomRV32 ++ // rv32 (32bit)
new boom.common.WithSmallBooms ++
new boom.common.WithNBoomCores(1) ++
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++
new freechips.rocketchip.system.BaseConfig)
class HwachaLargeBoomConfig extends Config(
new chipyard.iobinders.WithUARTAdapter ++
new chipyard.iobinders.WithTieOffInterrupts ++
new chipyard.iobinders.WithBlackBoxSimMem ++
new chipyard.iobinders.WithTiedOffDebug ++
new chipyard.iobinders.WithSimSerial ++
new testchipip.WithTSI ++
new chipyard.config.WithBootROM ++
new chipyard.config.WithUART ++
new chipyard.config.WithL2TLBs(1024) ++
new hwacha.DefaultHwachaConfig ++ // use Hwacha vector accelerator
new freechips.rocketchip.subsystem.WithNoMMIOPort ++
new freechips.rocketchip.subsystem.WithNoSlavePort ++
new freechips.rocketchip.subsystem.WithInclusiveCache ++
new freechips.rocketchip.subsystem.WithNExtTopInterrupts(0) ++
new boom.common.WithLargeBooms ++
new boom.common.WithNBoomCores(1) ++
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++
new freechips.rocketchip.system.BaseConfig)
class LoopbackNICLargeBoomConfig extends Config(
new chipyard.iobinders.WithUARTAdapter ++
new chipyard.iobinders.WithTieOffInterrupts ++
new chipyard.iobinders.WithBlackBoxSimMem ++
new chipyard.iobinders.WithTiedOffDebug ++
new chipyard.iobinders.WithSimSerial ++
new chipyard.iobinders.WithLoopbackNIC ++ // drive NIC IOs with loopback
new testchipip.WithTSI ++
new icenet.WithIceNIC ++
new chipyard.config.WithBootROM ++
new chipyard.config.WithUART ++
new chipyard.config.WithL2TLBs(1024) ++
new freechips.rocketchip.subsystem.WithNoMMIOPort ++
new freechips.rocketchip.subsystem.WithNoSlavePort ++
new freechips.rocketchip.subsystem.WithInclusiveCache ++
new freechips.rocketchip.subsystem.WithNExtTopInterrupts(0) ++
new boom.common.WithLargeBooms ++
new boom.common.WithNBoomCores(1) ++
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++
new freechips.rocketchip.system.BaseConfig)
class DromajoBoomConfig extends Config(
new chipyard.iobinders.WithUARTAdapter ++
new chipyard.iobinders.WithTieOffInterrupts ++
new chipyard.iobinders.WithBlackBoxSimMem ++
new chipyard.iobinders.WithTiedOffDebug ++
new chipyard.iobinders.WithSimSerial ++
new chipyard.iobinders.WithSimDromajoBridge ++ // attach Dromajo
new testchipip.WithTSI ++
new chipyard.config.WithTraceIO ++ // enable the traceio
new chipyard.config.WithBootROM ++
new chipyard.config.WithUART ++
new chipyard.config.WithL2TLBs(1024) ++
new freechips.rocketchip.subsystem.WithNoMMIOPort ++
new freechips.rocketchip.subsystem.WithNoSlavePort ++
new freechips.rocketchip.subsystem.WithInclusiveCache ++
new freechips.rocketchip.subsystem.WithNExtTopInterrupts(0) ++
new boom.common.WithSmallBooms ++
new boom.common.WithNBoomCores(1) ++
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++
new freechips.rocketchip.system.BaseConfig)

170
generators/chipyard/src/main/scala/config/HeteroConfigs.scala Normal file
View File

@@ -0,0 +1,170 @@
package chipyard
import freechips.rocketchip.config.{Config}
// ---------------------
// Heterogenous Configs
// ---------------------
class LargeBoomAndRocketConfig extends Config(
new chipyard.iobinders.WithUARTAdapter ++ // display UART with a SimUARTAdapter
new chipyard.iobinders.WithTieOffInterrupts ++ // tie off top-level interrupts
new chipyard.iobinders.WithBlackBoxSimMem ++ // drive the master AXI4 memory with a SimAXIMem
new chipyard.iobinders.WithTiedOffDebug ++ // tie off debug (since we are using SimSerial for testing)
new chipyard.iobinders.WithSimSerial ++ // drive TSI with SimSerial for testing
new testchipip.WithTSI ++ // use testchipip serial offchip link
new chipyard.config.WithBootROM ++ // use default bootrom
new chipyard.config.WithUART ++ // add a UART
new chipyard.config.WithL2TLBs(1024) ++ // use L2 TLBs
new chipyard.config.WithRenumberHarts ++ // avoid hartid overlap
new boom.common.WithLargeBooms ++ // 3-wide boom
new boom.common.WithNBoomCores(1) ++ // single-core boom
new freechips.rocketchip.subsystem.WithNoMMIOPort ++ // no top-level MMIO master port (overrides default set in rocketchip)
new freechips.rocketchip.subsystem.WithNoSlavePort ++ // no top-level MMIO slave port (overrides default set in rocketchip)
new freechips.rocketchip.subsystem.WithInclusiveCache ++ // use Sifive L2 cache
new freechips.rocketchip.subsystem.WithNExtTopInterrupts(0) ++ // no external interrupts
new freechips.rocketchip.subsystem.WithNBigCores(1) ++ // single rocket-core
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++ // hierarchical buses including mbus+l2
new freechips.rocketchip.system.BaseConfig) // "base" rocketchip system
// DOC include start: BoomAndRocketWithHwacha
class HwachaLargeBoomAndHwachaRocketConfig extends Config(
new chipyard.iobinders.WithUARTAdapter ++
new chipyard.iobinders.WithTieOffInterrupts ++
new chipyard.iobinders.WithBlackBoxSimMem ++
new chipyard.iobinders.WithTiedOffDebug ++
new chipyard.iobinders.WithSimSerial ++
new testchipip.WithTSI ++
new chipyard.config.WithBootROM ++
new chipyard.config.WithUART ++
new chipyard.config.WithL2TLBs(1024) ++
new hwacha.DefaultHwachaConfig ++ // add hwacha to all harts
new chipyard.config.WithRenumberHarts ++
new boom.common.WithLargeBooms ++
new boom.common.WithNBoomCores(1) ++
new freechips.rocketchip.subsystem.WithNoMMIOPort ++
new freechips.rocketchip.subsystem.WithNoSlavePort ++
new freechips.rocketchip.subsystem.WithInclusiveCache ++
new freechips.rocketchip.subsystem.WithNExtTopInterrupts(0) ++
new freechips.rocketchip.subsystem.WithNBigCores(1) ++
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++
new freechips.rocketchip.system.BaseConfig)
// DOC include end: BoomAndRocketWithHwacha
class DualLargeBoomAndRocketConfig extends Config(
new chipyard.iobinders.WithUARTAdapter ++
new chipyard.iobinders.WithTieOffInterrupts ++
new chipyard.iobinders.WithBlackBoxSimMem ++
new chipyard.iobinders.WithTiedOffDebug ++
new chipyard.iobinders.WithSimSerial ++
new testchipip.WithTSI ++
new chipyard.config.WithBootROM ++
new chipyard.config.WithUART ++
new chipyard.config.WithL2TLBs(1024) ++
new chipyard.config.WithRenumberHarts ++
new boom.common.WithLargeBooms ++
new boom.common.WithNBoomCores(2) ++ // 2 boom cores
new freechips.rocketchip.subsystem.WithNoMMIOPort ++
new freechips.rocketchip.subsystem.WithNoSlavePort ++
new freechips.rocketchip.subsystem.WithInclusiveCache ++
new freechips.rocketchip.subsystem.WithNExtTopInterrupts(0) ++
new freechips.rocketchip.subsystem.WithNBigCores(1) ++
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++
new freechips.rocketchip.system.BaseConfig)
// DOC include start: DualBoomAndRocketOneHwacha
class LargeBoomAndHwachaRocketConfig extends Config(
new chipyard.iobinders.WithUARTAdapter ++
new chipyard.iobinders.WithTieOffInterrupts ++
new chipyard.iobinders.WithBlackBoxSimMem ++
new chipyard.iobinders.WithTiedOffDebug ++
new chipyard.iobinders.WithSimSerial ++
new testchipip.WithTSI ++
new chipyard.config.WithBootROM ++
new chipyard.config.WithUART ++
new chipyard.config.WithMultiRoCC ++ // support heterogeneous rocc
new chipyard.config.WithMultiRoCCHwacha(1) ++ // put hwacha on hart-2 (rocket)
new chipyard.config.WithL2TLBs(1024) ++
new chipyard.config.WithRenumberHarts ++
new boom.common.WithLargeBooms ++
new boom.common.WithNBoomCores(1) ++
new freechips.rocketchip.subsystem.WithNoMMIOPort ++
new freechips.rocketchip.subsystem.WithNoSlavePort ++
new freechips.rocketchip.subsystem.WithInclusiveCache ++
new freechips.rocketchip.subsystem.WithNExtTopInterrupts(0) ++
new freechips.rocketchip.subsystem.WithNBigCores(1) ++
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++
new freechips.rocketchip.system.BaseConfig)
// DOC include end: DualBoomAndRocketOneHwacha
class LargeBoomAndRV32RocketConfig extends Config(
new chipyard.iobinders.WithUARTAdapter ++
new chipyard.iobinders.WithTieOffInterrupts ++
new chipyard.iobinders.WithBlackBoxSimMem ++
new chipyard.iobinders.WithTiedOffDebug ++
new chipyard.iobinders.WithSimSerial ++
new testchipip.WithTSI ++
new chipyard.config.WithBootROM ++
new chipyard.config.WithUART ++
new chipyard.config.WithL2TLBs(1024) ++
new chipyard.config.WithRenumberHarts ++
new boom.common.WithLargeBooms ++
new boom.common.WithNBoomCores(1) ++
new freechips.rocketchip.subsystem.WithNoMMIOPort ++
new freechips.rocketchip.subsystem.WithNoSlavePort ++
new freechips.rocketchip.subsystem.WithInclusiveCache ++
new freechips.rocketchip.subsystem.WithNExtTopInterrupts(0) ++
new freechips.rocketchip.subsystem.WithRV32 ++ // set RocketTiles to be 32-bit
new freechips.rocketchip.subsystem.WithNBigCores(1) ++
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++
new freechips.rocketchip.system.BaseConfig)
// DOC include start: DualBoomAndRocket
class DualLargeBoomAndDualRocketConfig extends Config(
new chipyard.iobinders.WithUARTAdapter ++
new chipyard.iobinders.WithTieOffInterrupts ++
new chipyard.iobinders.WithBlackBoxSimMem ++
new chipyard.iobinders.WithTiedOffDebug ++
new chipyard.iobinders.WithSimSerial ++
new testchipip.WithTSI ++
new chipyard.config.WithBootROM ++
new chipyard.config.WithUART ++
new chipyard.config.WithL2TLBs(1024) ++
new chipyard.config.WithRenumberHarts ++
new boom.common.WithLargeBooms ++
new boom.common.WithNBoomCores(2) ++ // 2 boom cores
new freechips.rocketchip.subsystem.WithNoMMIOPort ++
new freechips.rocketchip.subsystem.WithNoSlavePort ++
new freechips.rocketchip.subsystem.WithInclusiveCache ++
new freechips.rocketchip.subsystem.WithNExtTopInterrupts(0) ++
new freechips.rocketchip.subsystem.WithNBigCores(2) ++ // 2 rocket cores
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++
new freechips.rocketchip.system.BaseConfig)
// DOC include end: DualBoomAndRocket
class LargeBoomAndRocketWithControlCoreConfig extends Config(
new chipyard.iobinders.WithUARTAdapter ++
new chipyard.iobinders.WithTieOffInterrupts ++
new chipyard.iobinders.WithBlackBoxSimMem ++
new chipyard.iobinders.WithTiedOffDebug ++
new chipyard.iobinders.WithSimSerial ++
new testchipip.WithTSI ++
new chipyard.config.WithBootROM ++
new chipyard.config.WithUART ++
new chipyard.config.WithControlCore ++ // add small control core to last hartid
new chipyard.config.WithL2TLBs(1024) ++
new chipyard.config.WithRenumberHarts ++
new boom.common.WithLargeBooms ++
new boom.common.WithNBoomCores(1) ++
new freechips.rocketchip.subsystem.WithNoMMIOPort ++
new freechips.rocketchip.subsystem.WithNoSlavePort ++
new freechips.rocketchip.subsystem.WithInclusiveCache ++
new freechips.rocketchip.subsystem.WithNExtTopInterrupts(0) ++
new freechips.rocketchip.subsystem.WithNBigCores(1) ++
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++
new freechips.rocketchip.system.BaseConfig)

465
generators/chipyard/src/main/scala/config/RocketConfigs.scala Normal file
View File

@@ -0,0 +1,465 @@
package chipyard
import freechips.rocketchip.config.{Config}
// --------------
// Rocket Configs
// --------------
class RocketConfig extends Config(
new chipyard.iobinders.WithUARTAdapter ++ // display UART with a SimUARTAdapter
new chipyard.iobinders.WithTieOffInterrupts ++ // tie off top-level interrupts
new chipyard.iobinders.WithBlackBoxSimMem ++ // drive the master AXI4 memory with a SimAXIMem
new chipyard.iobinders.WithTiedOffDebug ++ // tie off debug (since we are using SimSerial for testing)
new chipyard.iobinders.WithSimSerial ++ // drive TSI with SimSerial for testing
new testchipip.WithTSI ++ // use testchipip serial offchip link
new chipyard.config.WithBootROM ++ // use default bootrom
new chipyard.config.WithUART ++ // add a UART
new chipyard.config.WithL2TLBs(1024) ++ // use L2 TLBs
new freechips.rocketchip.subsystem.WithNoMMIOPort ++ // no top-level MMIO master port (overrides default set in rocketchip)
new freechips.rocketchip.subsystem.WithNoSlavePort ++ // no top-level MMIO slave port (overrides default set in rocketchip)
new freechips.rocketchip.subsystem.WithInclusiveCache ++ // use Sifive L2 cache
new freechips.rocketchip.subsystem.WithNExtTopInterrupts(0) ++ // no external interrupts
new freechips.rocketchip.subsystem.WithNBigCores(1) ++ // single rocket-core
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++ // hierarchical buses including mbus+l2
new freechips.rocketchip.system.BaseConfig) // "base" rocketchip system
class HwachaRocketConfig extends Config(
new chipyard.iobinders.WithUARTAdapter ++
new chipyard.iobinders.WithTieOffInterrupts ++
new chipyard.iobinders.WithBlackBoxSimMem ++
new chipyard.iobinders.WithTiedOffDebug ++
new chipyard.iobinders.WithSimSerial ++
new testchipip.WithTSI ++
new chipyard.config.WithBootROM ++
new chipyard.config.WithUART ++
new chipyard.config.WithL2TLBs(1024) ++
new hwacha.DefaultHwachaConfig ++ // use Hwacha vector accelerator
new freechips.rocketchip.subsystem.WithNoMMIOPort ++
new freechips.rocketchip.subsystem.WithNoSlavePort ++
new freechips.rocketchip.subsystem.WithInclusiveCache ++
new freechips.rocketchip.subsystem.WithNExtTopInterrupts(0) ++
new freechips.rocketchip.subsystem.WithNBigCores(1) ++
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++
new freechips.rocketchip.system.BaseConfig)
// DOC include start: GemminiRocketConfig
class GemminiRocketConfig extends Config(
new chipyard.iobinders.WithUARTAdapter ++
new chipyard.iobinders.WithTieOffInterrupts ++
new chipyard.iobinders.WithBlackBoxSimMem ++
new chipyard.iobinders.WithTiedOffDebug ++
new chipyard.iobinders.WithSimSerial ++
new testchipip.WithTSI ++
new chipyard.config.WithBootROM ++
new chipyard.config.WithUART ++
new chipyard.config.WithL2TLBs(1024) ++
new gemmini.DefaultGemminiConfig ++ // use Gemmini systolic array GEMM accelerator
new freechips.rocketchip.subsystem.WithNoMMIOPort ++
new freechips.rocketchip.subsystem.WithNoSlavePort ++
new freechips.rocketchip.subsystem.WithInclusiveCache ++
new freechips.rocketchip.subsystem.WithNExtTopInterrupts(0) ++
new freechips.rocketchip.subsystem.WithNBigCores(1) ++
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++
new freechips.rocketchip.system.BaseConfig)
// DOC include end: GemminiRocketConfig
class RoccRocketConfig extends Config(
new chipyard.iobinders.WithUARTAdapter ++
new chipyard.iobinders.WithTieOffInterrupts ++
new chipyard.iobinders.WithBlackBoxSimMem ++
new chipyard.iobinders.WithTiedOffDebug ++
new chipyard.iobinders.WithSimSerial ++
new testchipip.WithTSI ++
new chipyard.config.WithBootROM ++
new chipyard.config.WithUART ++
new chipyard.config.WithL2TLBs(1024) ++
new freechips.rocketchip.subsystem.WithNoMMIOPort ++
new freechips.rocketchip.subsystem.WithNoSlavePort ++
new freechips.rocketchip.subsystem.WithInclusiveCache ++
new freechips.rocketchip.subsystem.WithRoccExample ++ // use example RoCC-based accelerator
new freechips.rocketchip.subsystem.WithNExtTopInterrupts(0) ++
new freechips.rocketchip.subsystem.WithNBigCores(1) ++
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++
new freechips.rocketchip.system.BaseConfig)
// DOC include start: JtagRocket
class jtagRocketConfig extends Config(
new chipyard.iobinders.WithUARTAdapter ++
new chipyard.iobinders.WithTieOffInterrupts ++
new chipyard.iobinders.WithBlackBoxSimMem ++
new chipyard.iobinders.WithSimDebug ++ // add SimJtag and SimSerial, use both to drive sim
new chipyard.iobinders.WithSimSerial ++
new testchipip.WithTSI ++
new chipyard.config.WithBootROM ++
new chipyard.config.WithUART ++
new chipyard.config.WithL2TLBs(1024) ++
new freechips.rocketchip.subsystem.WithJtagDTM ++ // sets DTM communication interface to JTAG
new freechips.rocketchip.subsystem.WithNoMMIOPort ++
new freechips.rocketchip.subsystem.WithNoSlavePort ++
new freechips.rocketchip.subsystem.WithInclusiveCache ++
new freechips.rocketchip.subsystem.WithNExtTopInterrupts(0) ++
new freechips.rocketchip.subsystem.WithNBigCores(1) ++
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++
new freechips.rocketchip.system.BaseConfig)
// DOC include end: JtagRocket
// DOC include start: DmiRocket
class dmiRocketConfig extends Config(
new chipyard.iobinders.WithUARTAdapter ++
new chipyard.iobinders.WithTieOffInterrupts ++
new chipyard.iobinders.WithBlackBoxSimMem ++
new chipyard.iobinders.WithTiedOffSerial ++
new chipyard.iobinders.WithSimDebug ++ // add SimDebug and use it to drive simulation
new chipyard.config.WithBootROM ++
new chipyard.config.WithUART ++
new chipyard.config.WithL2TLBs(1024) ++
new freechips.rocketchip.subsystem.WithNoMMIOPort ++
new freechips.rocketchip.subsystem.WithNoSlavePort ++
new freechips.rocketchip.subsystem.WithInclusiveCache ++
new freechips.rocketchip.subsystem.WithNExtTopInterrupts(0) ++
new freechips.rocketchip.subsystem.WithNBigCores(1) ++
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++
new freechips.rocketchip.system.BaseConfig)
// DOC include end: DmiRocket
// DOC include start: GCDTLRocketConfig
class GCDTLRocketConfig extends Config(
new chipyard.iobinders.WithUARTAdapter ++
new chipyard.iobinders.WithTieOffInterrupts ++
new chipyard.iobinders.WithBlackBoxSimMem ++
new chipyard.iobinders.WithTiedOffDebug ++
new chipyard.iobinders.WithSimSerial ++
new testchipip.WithTSI ++
new chipyard.config.WithUART ++
new chipyard.config.WithBootROM ++
new chipyard.config.WithL2TLBs(1024) ++
new chipyard.example.WithGCD(useAXI4=false, useBlackBox=false) ++ // Use GCD Chisel, connect Tilelink
new freechips.rocketchip.subsystem.WithNoMMIOPort ++
new freechips.rocketchip.subsystem.WithNoSlavePort ++
new freechips.rocketchip.subsystem.WithInclusiveCache ++
new freechips.rocketchip.subsystem.WithNExtTopInterrupts(0) ++
new freechips.rocketchip.subsystem.WithNBigCores(1) ++
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++
new freechips.rocketchip.system.BaseConfig)
// DOC include end: GCDTLRocketConfig
// DOC include start: GCDAXI4BlackBoxRocketConfig
class GCDAXI4BlackBoxRocketConfig extends Config(
new chipyard.iobinders.WithUARTAdapter ++
new chipyard.iobinders.WithTieOffInterrupts ++
new chipyard.iobinders.WithBlackBoxSimMem ++
new chipyard.iobinders.WithTiedOffDebug ++
new chipyard.iobinders.WithSimSerial ++
new testchipip.WithTSI ++
new chipyard.config.WithUART ++
new chipyard.config.WithBootROM ++
new chipyard.config.WithL2TLBs(1024) ++
new chipyard.example.WithGCD(useAXI4=true, useBlackBox=true) ++ // Use GCD blackboxed verilog, connect by AXI4->Tilelink
new freechips.rocketchip.subsystem.WithNoMMIOPort ++
new freechips.rocketchip.subsystem.WithNoSlavePort ++
new freechips.rocketchip.subsystem.WithInclusiveCache ++
new freechips.rocketchip.subsystem.WithNExtTopInterrupts(0) ++
new freechips.rocketchip.subsystem.WithNBigCores(1) ++
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++
new freechips.rocketchip.system.BaseConfig)
// DOC include end: GCDAXI4BlackBoxRocketConfig
class LargeSPIFlashROMRocketConfig extends Config(
new chipyard.iobinders.WithUARTAdapter ++
new chipyard.iobinders.WithTieOffInterrupts ++
new chipyard.iobinders.WithBlackBoxSimMem ++
new chipyard.iobinders.WithTiedOffDebug ++
new chipyard.iobinders.WithSimSerial ++
new chipyard.iobinders.WithSimSPIFlashModel(true) ++ // add the SPI flash model in the harness (read-only)
new testchipip.WithTSI ++
new chipyard.config.WithBootROM ++
new chipyard.config.WithUART ++
new chipyard.config.WithSPIFlash ++ // add the SPI flash controller
new chipyard.config.WithL2TLBs(1024) ++
new freechips.rocketchip.subsystem.WithNoMMIOPort ++
new freechips.rocketchip.subsystem.WithNoSlavePort ++
new freechips.rocketchip.subsystem.WithInclusiveCache ++
new freechips.rocketchip.subsystem.WithNExtTopInterrupts(0) ++
new freechips.rocketchip.subsystem.WithNBigCores(1) ++
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++
new freechips.rocketchip.system.BaseConfig)
class SmallSPIFlashRocketConfig extends Config(
new chipyard.iobinders.WithUARTAdapter ++
new chipyard.iobinders.WithTieOffInterrupts ++
new chipyard.iobinders.WithBlackBoxSimMem ++
new chipyard.iobinders.WithTiedOffDebug ++
new chipyard.iobinders.WithSimSerial ++
new chipyard.iobinders.WithSimSPIFlashModel(false) ++ // add the SPI flash model in the harness (writeable)
new testchipip.WithTSI ++
new chipyard.config.WithBootROM ++
new chipyard.config.WithUART ++
new chipyard.config.WithSPIFlash(0x100000) ++ // add the SPI flash controller (1 MiB)
new chipyard.config.WithL2TLBs(1024) ++
new freechips.rocketchip.subsystem.WithNoMMIOPort ++
new freechips.rocketchip.subsystem.WithNoSlavePort ++
new freechips.rocketchip.subsystem.WithInclusiveCache ++
new freechips.rocketchip.subsystem.WithNExtTopInterrupts(0) ++
new freechips.rocketchip.subsystem.WithNBigCores(1) ++
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++
new freechips.rocketchip.system.BaseConfig)
class SimBlockDeviceRocketConfig extends Config(
new chipyard.iobinders.WithUARTAdapter ++
new chipyard.iobinders.WithTieOffInterrupts ++
new chipyard.iobinders.WithBlackBoxSimMem ++
new chipyard.iobinders.WithTiedOffDebug ++
new chipyard.iobinders.WithSimSerial ++
new chipyard.iobinders.WithSimBlockDevice ++ // drive block-device IOs with SimBlockDevice
new testchipip.WithTSI ++
new testchipip.WithBlockDevice ++ // add block-device module to peripherybus
new chipyard.config.WithBootROM ++
new chipyard.config.WithUART ++
new chipyard.config.WithL2TLBs(1024) ++
new freechips.rocketchip.subsystem.WithNoMMIOPort ++
new freechips.rocketchip.subsystem.WithNoSlavePort ++
new freechips.rocketchip.subsystem.WithInclusiveCache ++
new freechips.rocketchip.subsystem.WithNExtTopInterrupts(0) ++
new freechips.rocketchip.subsystem.WithNBigCores(1) ++
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++
new freechips.rocketchip.system.BaseConfig)
class BlockDeviceModelRocketConfig extends Config(
new chipyard.iobinders.WithUARTAdapter ++
new chipyard.iobinders.WithTieOffInterrupts ++
new chipyard.iobinders.WithBlackBoxSimMem ++
new chipyard.iobinders.WithTiedOffDebug ++
new chipyard.iobinders.WithSimSerial ++
new chipyard.iobinders.WithBlockDeviceModel ++ // drive block-device IOs with a BlockDeviceModel
new testchipip.WithTSI ++
new testchipip.WithBlockDevice ++ // add block-device module to periphery bus
new chipyard.config.WithBootROM ++
new chipyard.config.WithUART ++
new chipyard.config.WithL2TLBs(1024) ++
new freechips.rocketchip.subsystem.WithNoMMIOPort ++
new freechips.rocketchip.subsystem.WithNoSlavePort ++
new freechips.rocketchip.subsystem.WithInclusiveCache ++
new freechips.rocketchip.subsystem.WithNExtTopInterrupts(0) ++
new freechips.rocketchip.subsystem.WithNBigCores(1) ++
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++
new freechips.rocketchip.system.BaseConfig)
// DOC include start: GPIORocketConfig
class GPIORocketConfig extends Config(
new chipyard.iobinders.WithUARTAdapter ++
new chipyard.iobinders.WithTieOffInterrupts ++
new chipyard.iobinders.WithBlackBoxSimMem ++
new chipyard.iobinders.WithTiedOffDebug ++
new chipyard.iobinders.WithSimSerial ++
new chipyard.iobinders.WithGPIOTiedOff ++ // tie off GPIO inputs into the top
new testchipip.WithTSI ++
new chipyard.config.WithGPIO ++ // add GPIOs to the peripherybus
new chipyard.config.WithBootROM ++
new chipyard.config.WithUART ++
new chipyard.config.WithL2TLBs(1024) ++
new freechips.rocketchip.subsystem.WithNoMMIOPort ++
new freechips.rocketchip.subsystem.WithNoSlavePort ++
new freechips.rocketchip.subsystem.WithInclusiveCache ++
new freechips.rocketchip.subsystem.WithNExtTopInterrupts(0) ++
new freechips.rocketchip.subsystem.WithNBigCores(1) ++
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++
new freechips.rocketchip.system.BaseConfig)
// DOC include end: GPIORocketConfig
class QuadRocketConfig extends Config(
new chipyard.iobinders.WithUARTAdapter ++
new chipyard.iobinders.WithTieOffInterrupts ++
new chipyard.iobinders.WithBlackBoxSimMem ++
new chipyard.iobinders.WithTiedOffDebug ++
new chipyard.iobinders.WithSimSerial ++
new testchipip.WithTSI ++
new chipyard.config.WithBootROM ++
new chipyard.config.WithUART ++
new chipyard.config.WithL2TLBs(1024) ++
new freechips.rocketchip.subsystem.WithNoMMIOPort ++
new freechips.rocketchip.subsystem.WithNoSlavePort ++
new freechips.rocketchip.subsystem.WithInclusiveCache ++
new freechips.rocketchip.subsystem.WithNExtTopInterrupts(0) ++
new freechips.rocketchip.subsystem.WithNBigCores(4) ++ // quad-core (4 RocketTiles)
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++
new freechips.rocketchip.system.BaseConfig)
class RV32RocketConfig extends Config(
new chipyard.iobinders.WithUARTAdapter ++
new chipyard.iobinders.WithTieOffInterrupts ++
new chipyard.iobinders.WithBlackBoxSimMem ++
new chipyard.iobinders.WithTiedOffDebug ++
new chipyard.iobinders.WithSimSerial ++
new testchipip.WithTSI ++
new chipyard.config.WithBootROM ++
new chipyard.config.WithUART ++
new freechips.rocketchip.subsystem.WithNoMMIOPort ++
new freechips.rocketchip.subsystem.WithNoSlavePort ++
new freechips.rocketchip.subsystem.WithInclusiveCache ++
new freechips.rocketchip.subsystem.WithRV32 ++ // set RocketTiles to be 32-bit
new freechips.rocketchip.subsystem.WithNExtTopInterrupts(0) ++
new freechips.rocketchip.subsystem.WithNBigCores(1) ++
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++
new freechips.rocketchip.system.BaseConfig)
class GB1MemoryRocketConfig extends Config(
new chipyard.iobinders.WithUARTAdapter ++
new chipyard.iobinders.WithTieOffInterrupts ++
new chipyard.iobinders.WithBlackBoxSimMem ++
new chipyard.iobinders.WithTiedOffDebug ++
new chipyard.iobinders.WithSimSerial ++
new testchipip.WithTSI ++
new chipyard.config.WithBootROM ++
new chipyard.config.WithUART ++
new chipyard.config.WithL2TLBs(1024) ++
new freechips.rocketchip.subsystem.WithExtMemSize((1<<30) * 1L) ++ // use 1GB simulated external memory
new freechips.rocketchip.subsystem.WithNoMMIOPort ++
new freechips.rocketchip.subsystem.WithNoSlavePort ++
new freechips.rocketchip.subsystem.WithInclusiveCache ++
new freechips.rocketchip.subsystem.WithNExtTopInterrupts(0) ++
new freechips.rocketchip.subsystem.WithNBigCores(1) ++
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++
new freechips.rocketchip.system.BaseConfig)
// DOC include start: Sha3Rocket
class Sha3RocketConfig extends Config(
new chipyard.iobinders.WithUARTAdapter ++
new chipyard.iobinders.WithTieOffInterrupts ++
new chipyard.iobinders.WithBlackBoxSimMem ++
new chipyard.iobinders.WithTiedOffDebug ++
new chipyard.iobinders.WithSimSerial ++
new testchipip.WithTSI ++
new chipyard.config.WithBootROM ++
new chipyard.config.WithUART ++
new chipyard.config.WithL2TLBs(1024) ++
new sha3.WithSha3Accel ++ // add SHA3 rocc accelerator
new freechips.rocketchip.subsystem.WithNoMMIOPort ++
new freechips.rocketchip.subsystem.WithNoSlavePort ++
new freechips.rocketchip.subsystem.WithInclusiveCache ++
new freechips.rocketchip.subsystem.WithNExtTopInterrupts(0) ++
new freechips.rocketchip.subsystem.WithNBigCores(1) ++
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++
new freechips.rocketchip.system.BaseConfig)
// DOC include end: Sha3Rocket
// DOC include start: InitZeroRocketConfig
class InitZeroRocketConfig extends Config(
new chipyard.iobinders.WithUARTAdapter ++
new chipyard.iobinders.WithTieOffInterrupts ++
new chipyard.iobinders.WithBlackBoxSimMem ++
new chipyard.iobinders.WithTiedOffDebug ++
new chipyard.iobinders.WithSimSerial ++
new testchipip.WithTSI ++
new chipyard.config.WithBootROM ++
new chipyard.config.WithUART ++
new chipyard.config.WithL2TLBs(1024) ++
new chipyard.example.WithInitZero(0x88000000L, 0x1000L) ++ // add InitZero
new freechips.rocketchip.subsystem.WithNoMMIOPort ++
new freechips.rocketchip.subsystem.WithNoSlavePort ++
new freechips.rocketchip.subsystem.WithInclusiveCache ++
new freechips.rocketchip.subsystem.WithNExtTopInterrupts(0) ++
new freechips.rocketchip.subsystem.WithNBigCores(1) ++
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++
new freechips.rocketchip.system.BaseConfig)
// DOC include end: InitZeroRocketConfig
class LoopbackNICRocketConfig extends Config(
new chipyard.iobinders.WithUARTAdapter ++
new chipyard.iobinders.WithTieOffInterrupts ++
new chipyard.iobinders.WithBlackBoxSimMem ++
new chipyard.iobinders.WithTiedOffDebug ++
new chipyard.iobinders.WithSimSerial ++
new chipyard.iobinders.WithLoopbackNIC ++ // drive NIC IOs with loopback
new testchipip.WithTSI ++
new icenet.WithIceNIC ++ // add an IceNIC
new chipyard.config.WithBootROM ++
new chipyard.config.WithUART ++
new chipyard.config.WithL2TLBs(1024) ++
new freechips.rocketchip.subsystem.WithNoMMIOPort ++
new freechips.rocketchip.subsystem.WithNoSlavePort ++
new freechips.rocketchip.subsystem.WithInclusiveCache ++
new freechips.rocketchip.subsystem.WithNExtTopInterrupts(0) ++
new freechips.rocketchip.subsystem.WithNBigCores(1) ++
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++
new freechips.rocketchip.system.BaseConfig)
// DOC include start: scratchpadrocket
class ScratchpadRocketConfig extends Config(
new chipyard.iobinders.WithUARTAdapter ++
new chipyard.iobinders.WithTieOffInterrupts ++
new chipyard.iobinders.WithTiedOffDebug ++
new chipyard.iobinders.WithSimSerial ++
new testchipip.WithTSI ++
new testchipip.WithBackingScratchpad ++ // add backing scratchpad
new chipyard.config.WithBootROM ++
new chipyard.config.WithUART ++
new chipyard.config.WithL2TLBs(1024) ++
new freechips.rocketchip.subsystem.WithNoMemPort ++ // remove offchip mem port
new freechips.rocketchip.subsystem.WithNoMMIOPort ++
new freechips.rocketchip.subsystem.WithNoSlavePort ++
new freechips.rocketchip.subsystem.WithInclusiveCache ++
new freechips.rocketchip.subsystem.WithNExtTopInterrupts(0) ++
new freechips.rocketchip.subsystem.WithNBigCores(1) ++
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++
new freechips.rocketchip.system.BaseConfig)
// DOC include end: scratchpadrocket
// DOC include start: RingSystemBusRocket
class RingSystemBusRocketConfig extends Config(
new chipyard.iobinders.WithUARTAdapter ++
new chipyard.iobinders.WithTieOffInterrupts ++
new chipyard.iobinders.WithBlackBoxSimMem ++
new chipyard.iobinders.WithTiedOffDebug ++
new chipyard.iobinders.WithSimSerial ++
new testchipip.WithTSI ++
new chipyard.config.WithBootROM ++
new chipyard.config.WithUART ++
new chipyard.config.WithL2TLBs(1024) ++
new testchipip.WithRingSystemBus ++ // Ring-topology system bus
new freechips.rocketchip.subsystem.WithNoMMIOPort ++
new freechips.rocketchip.subsystem.WithNoSlavePort ++
new freechips.rocketchip.subsystem.WithInclusiveCache ++
new freechips.rocketchip.subsystem.WithNExtTopInterrupts(0) ++
new freechips.rocketchip.subsystem.WithNBigCores(1) ++
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++
new freechips.rocketchip.system.BaseConfig)
// DOC include end: RingSystemBusRocket
class SmallNVDLARocketConfig extends Config(
new chipyard.iobinders.WithUARTAdapter ++
new chipyard.iobinders.WithTieOffInterrupts ++
new chipyard.iobinders.WithBlackBoxSimMem ++
new chipyard.iobinders.WithTiedOffDebug ++
new chipyard.iobinders.WithSimSerial ++
new testchipip.WithTSI ++
new chipyard.config.WithBootROM ++
new chipyard.config.WithUART ++
new chipyard.config.WithL2TLBs(1024) ++
new nvidia.blocks.dla.WithNVDLA("small") ++ // add a small NVDLA
new freechips.rocketchip.subsystem.WithNoMMIOPort ++
new freechips.rocketchip.subsystem.WithNoSlavePort ++
new freechips.rocketchip.subsystem.WithInclusiveCache ++
new freechips.rocketchip.subsystem.WithNExtTopInterrupts(0) ++
new freechips.rocketchip.subsystem.WithNBigCores(1) ++
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++
new freechips.rocketchip.system.BaseConfig)
class LargeNVDLARocketConfig extends Config(
new chipyard.iobinders.WithUARTAdapter ++
new chipyard.iobinders.WithTieOffInterrupts ++
new chipyard.iobinders.WithBlackBoxSimMem ++
new chipyard.iobinders.WithTiedOffDebug ++
new chipyard.iobinders.WithSimSerial ++
new testchipip.WithTSI ++
new chipyard.config.WithBootROM ++
new chipyard.config.WithUART ++
new chipyard.config.WithL2TLBs(1024) ++
new nvidia.blocks.dla.WithNVDLA("large", true) ++ // add a large NVDLA with synth. rams
new freechips.rocketchip.subsystem.WithNoMMIOPort ++
new freechips.rocketchip.subsystem.WithNoSlavePort ++
new freechips.rocketchip.subsystem.WithInclusiveCache ++
new freechips.rocketchip.subsystem.WithNExtTopInterrupts(0) ++
new freechips.rocketchip.subsystem.WithNBigCores(1) ++
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++
new freechips.rocketchip.system.BaseConfig)

48
generators/chipyard/src/main/scala/config/TracegenConfigs.scala Normal file
View File

@@ -0,0 +1,48 @@
package chipyard
import freechips.rocketchip.config.{Config}
import freechips.rocketchip.rocket.{DCacheParams}
class TraceGenConfig extends Config(
new chipyard.iobinders.WithBlackBoxSimMem ++
new chipyard.iobinders.WithTraceGenSuccessBinder ++
new chipyard.config.WithTracegenSystem ++
new tracegen.WithTraceGen(List.fill(2) { DCacheParams(nMSHRs = 0, nSets = 16, nWays = 2) }) ++
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++
new freechips.rocketchip.system.BaseConfig)
class NonBlockingTraceGenConfig extends Config(
new chipyard.iobinders.WithBlackBoxSimMem ++
new chipyard.iobinders.WithTraceGenSuccessBinder ++
new chipyard.config.WithTracegenSystem ++
new tracegen.WithTraceGen(List.fill(2) { DCacheParams(nMSHRs = 2, nSets = 16, nWays = 2) }) ++
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++
new freechips.rocketchip.system.BaseConfig)
class BoomTraceGenConfig extends Config(
new chipyard.iobinders.WithBlackBoxSimMem ++
new chipyard.iobinders.WithTraceGenSuccessBinder ++
new chipyard.config.WithTracegenSystem ++
new tracegen.WithBoomTraceGen(List.fill(2) { DCacheParams(nMSHRs = 8, nSets = 16, nWays = 2) }) ++
new freechips.rocketchip.subsystem.WithInclusiveCache ++
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++
new freechips.rocketchip.system.BaseConfig)
class NonBlockingTraceGenL2Config extends Config(
new chipyard.iobinders.WithBlackBoxSimMem ++
new chipyard.iobinders.WithTraceGenSuccessBinder ++
new chipyard.config.WithTracegenSystem ++
new tracegen.WithL2TraceGen(List.fill(2)(DCacheParams(nMSHRs = 2, nSets = 16, nWays = 4))) ++
new freechips.rocketchip.subsystem.WithInclusiveCache ++
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++
new freechips.rocketchip.system.BaseConfig)
class NonBlockingTraceGenL2RingConfig extends Config(
new chipyard.iobinders.WithBlackBoxSimMem ++
new chipyard.iobinders.WithTraceGenSuccessBinder ++
new chipyard.config.WithTracegenSystem ++
new tracegen.WithL2TraceGen(List.fill(2)(DCacheParams(nMSHRs = 2, nSets = 16, nWays = 4))) ++
new testchipip.WithRingSystemBus ++
new freechips.rocketchip.subsystem.WithInclusiveCache ++
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++
new freechips.rocketchip.system.BaseConfig)

138
generators/chipyard/src/main/scala/config/TutorialConfigs.scala Normal file
View File

@@ -0,0 +1,138 @@
package chipyard
import freechips.rocketchip.config.{Config}
// This file is designed to accompany a live tutorial, with slides.
// For each of 4 phases, participants will customize and build a
// small demonstration config.
// This file is designed to be used after running chipyard/scripts/tutorial-setup.sh,
// which removes the SHA3 accelerator RTL, and provides participants
// the experience of integrating external RTL.
// This file was originally developed for the cancelled ASPLOS-2020
// Chipyard tutorial. While the configs here work, the corresponding
// slideware has not yet been created
// NOTE: Configs should be read bottom-up, since they are applied bottom-up
// Tutorial Phase 1: Configure the cores, caches
class TutorialStarterConfig extends Config(
// IOBinders specify how to connect to IOs in our TestHarness
// These config fragments do not affect
new chipyard.iobinders.WithUARTAdapter ++ // Connect a SimUART adapter to display UART on stdout
new chipyard.iobinders.WithBlackBoxSimMem ++ // Connect simulated external memory
new chipyard.iobinders.WithTieOffInterrupts ++ // Do not simulate external interrupts
new chipyard.iobinders.WithTiedOffDebug ++ // Disconnect the debug module, since we use TSI for bring-up
new chipyard.iobinders.WithSimSerial ++ // Connect external SimSerial widget to drive TSI
// Config fragments below this line affect hardware generation
// of the Top
new testchipip.WithTSI ++ // Add a TSI (Test Serial Interface) widget to bring-up the core
new chipyard.config.WithBootROM ++ // Use the Chipyard BootROM
new chipyard.config.WithRenumberHarts ++ // WithRenumberHarts fixes hartids heterogeneous designs, if design is not heterogeneous, this is a no-op
new chipyard.config.WithUART ++ // Add a UART
// CUSTOMIZE THE CORE
// Uncomment out one (or multiple) of the lines below, and choose
// how many cores you want.
// new freechips.rocketchip.subsystem.WithNBigCores(1) ++ // Specify we want some number of Rocket cores
// new boom.common.WithSmallBooms ++ // Specify all BOOM cores should be Small-sized (NOTE: other options are Medium/Large/Mega)
// new boom.common.WithNBoomCores(1) ++ // Specify we want some number of BOOM cores
// CUSTOMIZE the L2
// Uncomment this line, and specify a size if you want to have a L2
// new freechips.rocketchip.subsystem.WithInclusiveCache(nBanks=1, nWays=4, capacityKB=128) ++
// For simpler designs, we want to minimize IOs on
// our Top. These config fragments remove unnecessary
// ports
new freechips.rocketchip.subsystem.WithNoMMIOPort ++
new freechips.rocketchip.subsystem.WithNoSlavePort ++
new freechips.rocketchip.subsystem.WithNExtTopInterrupts(0) ++
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++ // hierarchical buses including mbus+l2
// BaseConfig configures "bare" rocketchip system
new freechips.rocketchip.system.BaseConfig
)
// Tutorial Phase 2: Integrate a TileLink or AXI4 MMIO device
class TutorialMMIOConfig extends Config(
new chipyard.iobinders.WithUARTAdapter ++
new chipyard.iobinders.WithBlackBoxSimMem ++
new chipyard.iobinders.WithTieOffInterrupts ++
new chipyard.iobinders.WithTiedOffDebug ++
new chipyard.iobinders.WithSimSerial ++
new testchipip.WithTSI ++
new chipyard.config.WithBootROM ++
new chipyard.config.WithRenumberHarts ++
new chipyard.config.WithUART ++
// Attach either a TileLink or AXI4 version of GCD
// Uncomment one of the below lines
// new chipyard.example.WithGCD(useAXI4=false) ++ // Use TileLink version
// new chipyard.example.WithGCD(useAXI4=true) ++ // Use AXI4 version
// For this demonstration we assume the base system is a single-core Rocket, for fast elaboration
new freechips.rocketchip.subsystem.WithNBigCores(1) ++
new freechips.rocketchip.subsystem.WithInclusiveCache ++
new freechips.rocketchip.subsystem.WithNoMMIOPort ++
new freechips.rocketchip.subsystem.WithNoSlavePort ++
new freechips.rocketchip.subsystem.WithNExtTopInterrupts(0) ++
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++
new freechips.rocketchip.system.BaseConfig
)
// Tutorial Phase 3: Integrate a SHA3 RoCC accelerator
class TutorialSha3Config extends Config(
new chipyard.iobinders.WithUARTAdapter ++
new chipyard.iobinders.WithBlackBoxSimMem ++
new chipyard.iobinders.WithTieOffInterrupts ++
new chipyard.iobinders.WithTiedOffDebug ++
new chipyard.iobinders.WithSimSerial ++
new testchipip.WithTSI ++
new chipyard.config.WithBootROM ++
new chipyard.config.WithRenumberHarts ++
new chipyard.config.WithUART ++
// Uncomment this line once you added SHA3 to the build.sbt, and cloned the SHA3 repo
// new sha3.WithSha3Accel ++
// For this demonstration we assume the base system is a single-core Rocket, for fast elaboration
new freechips.rocketchip.subsystem.WithNBigCores(1) ++
new freechips.rocketchip.subsystem.WithInclusiveCache ++
new freechips.rocketchip.subsystem.WithNoMMIOPort ++
new freechips.rocketchip.subsystem.WithNoSlavePort ++
new freechips.rocketchip.subsystem.WithNExtTopInterrupts(0) ++
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++
new freechips.rocketchip.system.BaseConfig
)
// Tutorial Phase 4: Integrate a Black-box verilog version of the SHA3 RoCC accelerator
class TutorialSha3BlackBoxConfig extends Config(
new chipyard.iobinders.WithUARTAdapter ++
new chipyard.iobinders.WithBlackBoxSimMem ++
new chipyard.iobinders.WithTieOffInterrupts ++
new chipyard.iobinders.WithTiedOffDebug ++
new chipyard.iobinders.WithSimSerial ++
new testchipip.WithTSI ++
new chipyard.config.WithBootROM ++
new chipyard.config.WithRenumberHarts ++
new chipyard.config.WithUART ++
// Uncomment these lines once SHA3 is integrated
// new sha3.WithSha3BlackBox ++ // Specify we want the Black-box verilog version of Sha3 Ctrl
// new sha3.WithSha3Accel ++
// For this demonstration we assume the base system is a single-core Rocket, for fast elaboration
new freechips.rocketchip.subsystem.WithNBigCores(1) ++
new freechips.rocketchip.subsystem.WithInclusiveCache ++
new freechips.rocketchip.subsystem.WithNoMMIOPort ++
new freechips.rocketchip.subsystem.WithNoSlavePort ++
new freechips.rocketchip.subsystem.WithNExtTopInterrupts(0) ++
new freechips.rocketchip.subsystem.WithCoherentBusTopology ++
new freechips.rocketchip.system.BaseConfig
)

13
generators/example/src/main/scala/GCD.scala → generators/chipyard/src/main/scala/example/GCD.scala
View File

@@ -1,11 +1,11 @@
package example
package chipyard.example
import chisel3._
import chisel3.util._
import chisel3.experimental.{IntParam, BaseModule}
import freechips.rocketchip.amba.axi4._
import freechips.rocketchip.subsystem.BaseSubsystem
import freechips.rocketchip.config.{Parameters, Field}
import freechips.rocketchip.config.{Parameters, Field, Config}
import freechips.rocketchip.diplomacy._
import freechips.rocketchip.regmapper.{HasRegMap, RegField}
import freechips.rocketchip.tilelink._
@@ -125,7 +125,7 @@ trait GCDModule extends HasRegMap {
gcd.valid := impl.io.output_valid
impl.io.output_ready := gcd.ready
status := Cat(impl.io.input_ready, impl.io.output_ready)
status := Cat(impl.io.input_ready, impl.io.output_valid)
io.gcd_busy := impl.io.busy
regmap(
@@ -198,3 +198,10 @@ trait CanHavePeripheryGCDModuleImp extends LazyModuleImp {
}
// DOC include end: GCD imp trait
// DOC include start: GCD config fragment
class WithGCD(useAXI4: Boolean, useBlackBox: Boolean) extends Config((site, here, up) => {
case GCDKey => Some(GCDParams(useAXI4 = useAXI4, useBlackBox = useBlackBox))
})
// DOC include end: GCD config fragment

11
generators/example/src/main/scala/InitZero.scala → generators/chipyard/src/main/scala/example/InitZero.scala
View File

@@ -1,9 +1,9 @@
package example
package chipyard.example
import chisel3._
import chisel3.util._
import freechips.rocketchip.subsystem.{BaseSubsystem, CacheBlockBytes}
import freechips.rocketchip.config.{Parameters, Field}
import freechips.rocketchip.config.{Parameters, Field, Config}
import freechips.rocketchip.diplomacy.{LazyModule, LazyModuleImp, IdRange}
import testchipip.TLHelper
@@ -65,3 +65,10 @@ trait CanHavePeripheryInitZero { this: BaseSubsystem =>
fbus.fromPort(Some("init-zero"))() := initZero.node
}
}
// DOC include start: WithInitZero
class WithInitZero(base: BigInt, size: BigInt) extends Config((site, here, up) => {
case InitZeroKey => Some(InitZeroConfig(base, size))
})
// DOC include end: WithInitZero

2
generators/example/src/main/scala/NodeTypes.scala → generators/chipyard/src/main/scala/example/NodeTypes.scala
View File

@@ -1,4 +1,4 @@
package example
package chipyard.example
import freechips.rocketchip.config.Parameters
import freechips.rocketchip.diplomacy._

0
generators/example/src/main/scala/RegisterNodeExample.scala → generators/chipyard/src/main/scala/example/RegisterNodeExample.scala
View File

25
generators/chipyard/src/main/scala/stage/ChipyardAnnotations.scala Normal file
View File

@@ -0,0 +1,25 @@
// See LICENSE for license details.
// Based on Rocket Chip's stage implementation
package chipyard.stage
import freechips.rocketchip.stage.ConfigsAnnotation
import firrtl.options.{HasShellOptions, ShellOption}
/** This hijacks the existing ConfigAnnotation to accept the legacy _-delimited format */
private[stage] object UnderscoreDelimitedConfigsAnnotation extends HasShellOptions {
override val options = Seq(
new ShellOption[String](
longOption = "legacy-configs",
toAnnotationSeq = a => {
val split = a.split('.')
val packageName = split.init.mkString(".")
val configs = split.last.split("_")
Seq(new ConfigsAnnotation(configs map { config => s"${packageName}.${config}" } ))
},
helpText = "A string of underscore-delimited configs (configs have decreasing precendence from left to right).",
shortOption = Some("LC")
)
)
}

15
generators/chipyard/src/main/scala/stage/ChipyardCli.scala Normal file
View File

@@ -0,0 +1,15 @@
// See LICENSE for license details.
// Based on Rocket Chip's stage implementation
package chipyard.stage
import firrtl.options.Shell
trait ChipyardCli { this: Shell =>
parser.note("Chipyard Generator Options")
Seq(
UnderscoreDelimitedConfigsAnnotation
)
.foreach(_.addOptions(parser))
}

36
generators/chipyard/src/main/scala/stage/ChipyardStage.scala Normal file
View File

@@ -0,0 +1,36 @@
// See LICENSE for license details.
// Based on Rocket Chip's stage implementation
package chipyard.stage
import chisel3.stage.{ChiselCli, ChiselStage}
import firrtl.options.PhaseManager.PhaseDependency
import firrtl.options.{Phase, PreservesAll, Shell}
import firrtl.stage.FirrtlCli
import freechips.rocketchip.stage.RocketChipCli
import freechips.rocketchip.system.RocketChipStage
import firrtl.options.{Phase, PhaseManager, PreservesAll, Shell, Stage, StageError, StageMain, Dependency}
import firrtl.options.phases.DeletedWrapper
class ChipyardStage extends ChiselStage with PreservesAll[Phase] {
override val shell = new Shell("chipyard") with ChipyardCli with RocketChipCli with ChiselCli with FirrtlCli
override val targets: Seq[PhaseDependency] = Seq(
Dependency[freechips.rocketchip.stage.phases.Checks],
Dependency[freechips.rocketchip.stage.phases.TransformAnnotations],
Dependency[freechips.rocketchip.stage.phases.PreElaboration],
Dependency[chisel3.stage.phases.Checks],
Dependency[chisel3.stage.phases.Elaborate],
Dependency[freechips.rocketchip.stage.phases.GenerateROMs],
Dependency[chisel3.stage.phases.AddImplicitOutputFile],
Dependency[chisel3.stage.phases.AddImplicitOutputAnnotationFile],
Dependency[chisel3.stage.phases.MaybeAspectPhase],
Dependency[chisel3.stage.phases.Emitter],
Dependency[chisel3.stage.phases.Convert],
Dependency[freechips.rocketchip.stage.phases.GenerateFirrtlAnnos],
Dependency[freechips.rocketchip.stage.phases.AddDefaultTests],
Dependency[chipyard.stage.phases.AddDefaultTests],
Dependency[chipyard.stage.phases.GenerateTestSuiteMakefrags],
Dependency[freechips.rocketchip.stage.phases.GenerateArtefacts],
)
}

67
generators/chipyard/src/main/scala/stage/phases/AddDefaultTests.scala Normal file
View File

@@ -0,0 +1,67 @@
// See LICENSE for license details.
// Based on Rocket Chip's stage implementation
package chipyard.stage.phases
import scala.util.Try
import scala.collection.mutable
import chipsalliance.rocketchip.config.Parameters
import chisel3.stage.phases.Elaborate
import firrtl.AnnotationSeq
import firrtl.annotations.{Annotation, NoTargetAnnotation}
import firrtl.options.{Phase, PreservesAll, Dependency}
import firrtl.options.Viewer.view
import freechips.rocketchip.stage.RocketChipOptions
import freechips.rocketchip.stage.phases.{RocketTestSuiteAnnotation}
import freechips.rocketchip.system.{RocketTestSuite, TestGeneration}
import freechips.rocketchip.util.HasRocketChipStageUtils
import freechips.rocketchip.tile.XLen
import chipyard.TestSuiteHelper
class AddDefaultTests extends Phase with PreservesAll[Phase] with HasRocketChipStageUtils {
// Make sure we run both after RocketChip's version of this phase, and Rocket Chip's annotation emission phase
// because the RocketTestSuiteAnnotation is not serializable (but is not marked as such).
override val prerequisites = Seq(
Dependency[freechips.rocketchip.stage.phases.GenerateFirrtlAnnos],
Dependency[freechips.rocketchip.stage.phases.AddDefaultTests])
override val dependents = Seq(Dependency[freechips.rocketchip.stage.phases.GenerateTestSuiteMakefrags])
private def addTestSuiteAnnotations(implicit p: Parameters): Seq[Annotation] = {
val annotations = mutable.ArrayBuffer[Annotation]()
val suiteHelper = new TestSuiteHelper
// Use Xlen as a proxy for detecting if we are a processor-like target
// The underlying test suites expect this field to be defined
if (p.lift(XLen).nonEmpty) {
suiteHelper.addRocketTestSuites
suiteHelper.addBoomTestSuites
suiteHelper.addArianeTestSuites
}
// if hwacha parameter exists then generate its tests
// TODO: find a more elegant way to do this. either through
// trying to disambiguate BuildRoCC, having a AccelParamsKey,
// or having the Accelerator/Tile add its own tests
import hwacha.HwachaTestSuites._
if (Try(p(hwacha.HwachaNLanes)).getOrElse(0) > 0) {
suiteHelper.addSuites(rv64uv.map(_("p")))
suiteHelper.addSuites(rv64uv.map(_("vp")))
suiteHelper.addSuite(rv64sv("p"))
suiteHelper.addSuite(hwachaBmarks)
annotations += CustomMakefragSnippet(
"SRC_EXTENSION = $(base_dir)/hwacha/$(src_path)/*.scala" + "\nDISASM_EXTENSION = --extension=hwacha")
}
RocketTestSuiteAnnotation(suiteHelper.suites.values.toSeq) +: annotations
}
override def transform(annotations: AnnotationSeq): AnnotationSeq = {
val (testSuiteAnnos, oAnnos) = annotations.partition {
case RocketTestSuiteAnnotation(_) => true
case o => false
}
implicit val p = getConfig(view[RocketChipOptions](annotations).configNames.get).toInstance
addTestSuiteAnnotations ++ oAnnos
}
}

49
generators/chipyard/src/main/scala/stage/phases/GenerateTestSuiteMakefrags.scala Normal file
View File

@@ -0,0 +1,49 @@
// See LICENSE for license details.
// Based on Rocket Chip's stage implementation
package chipyard.stage.phases
import scala.collection.mutable
import firrtl.AnnotationSeq
import firrtl.annotations.{Annotation, NoTargetAnnotation}
import firrtl.options.{Phase, PreservesAll, StageOptions, Unserializable, Dependency}
import firrtl.options.Viewer.view
import freechips.rocketchip.stage.RocketChipOptions
import freechips.rocketchip.stage.phases.{RocketTestSuiteAnnotation}
import freechips.rocketchip.system.TestGeneration
import freechips.rocketchip.util.HasRocketChipStageUtils
trait MakefragSnippet { self: Annotation =>
def toMakefrag: String
}
case class CustomMakefragSnippet(val toMakefrag: String) extends NoTargetAnnotation with MakefragSnippet with Unserializable
/** Generates a make script to run tests in [[RocketTestSuiteAnnotation]]. */
class GenerateTestSuiteMakefrags extends Phase with PreservesAll[Phase] with HasRocketChipStageUtils {
// Our annotations tend not to be serializable, but are not marked as such.
override val prerequisites = Seq(Dependency[freechips.rocketchip.stage.phases.GenerateFirrtlAnnos],
Dependency[chipyard.stage.phases.AddDefaultTests])
override def transform(annotations: AnnotationSeq): AnnotationSeq = {
val targetDir = view[StageOptions](annotations).targetDir
val fileName = s"${view[RocketChipOptions](annotations).longName.get}.d"
val makefragBuilder = new mutable.StringBuilder()
val outputAnnotations = annotations.flatMap {
case RocketTestSuiteAnnotation(tests) =>
// Unfortunately the gen method of TestGeneration is rocketchip package
// private, so we either have to copy code in or use the stateful form
TestGeneration.addSuites(tests)
None
case a: MakefragSnippet =>
makefragBuilder :+ ("\n" + a.toMakefrag)
None
case a => Some(a)
}
writeOutputFile(targetDir, fileName, TestGeneration.generateMakeFrag ++ makefragBuilder.toString)
outputAnnotations
}
}

9
generators/chipyard/src/main/scala/unittest/TestHarness.scala Normal file
View File

@@ -0,0 +1,9 @@
package chipyard.unittest
import chisel3._
import freechips.rocketchip.config.Parameters
class TestHarness(implicit val p: Parameters) extends Module {
val io = IO(new Bundle { val success = Output(Bool()) })
io.success := Module(new UnitTestSuite).io.finished
}

Some files were not shown because too many files have changed in this diff Show More