OSS cleanup
Cleanup obsolete docs. Add OSS LICENSE and contributing information.
Bug: 306427497
Change-Id: If123eca87881728e618014b059116c5e28cd26ea
diff --git a/BuildRiscVToolchain.md b/BuildRiscVToolchain.md
deleted file mode 100644
index 0f91330..0000000
--- a/BuildRiscVToolchain.md
+++ /dev/null
@@ -1,201 +0,0 @@
-# Build RISC-V Toolchain
-
-This doc lists the common config settings to build the RISC-V toolchain. It
-generally involves two parts of the toolchain: GCC to build the headers and
-libraries, and LLVM to build the compiler, linker, and utility tools.
-
-## Prerequisites
-
-Your host machine needs to have the following packages installed, which are
-already part of the Shodan prerequisite pacakges
-
-* CMake (>= 3.13.4)
-* Ninja
-* Clang
-
-The source code of the toolchain is at
-
-* [riscv-gnu-toolchain](https://github.com/riscv/riscv-gnu-toolchain): Checkout
-the latest release tag, and checkout the submodule `riscv-binutils` at the master
-branch at git://sourceware.org/git/binutils-gdb.git
-* [llvm-project](https://github.com/llvm/llvm-project): Checkout the latest green
-commit
-
-## Build RISC-V Linux toolchain (64-bit)
-
-### Build GCC
-
-```bash
-$ mkdir -p <GCC_BUILD_PATH>
-$ cd <GCC_BUILD_PATH>
-$ <GCC_SRC_PATH>/configure \
- --srcdir=<GCC_SRC_PATH> \
- --prefix=<TOOLCHAIN_OUT_DIR> \
- --with-arch=rv64gc \
- --with-abi=lp64d \
- --with-cmodel=medany
-$ make -C <GCC_BUILD_PATH> linux
-```
-
-Notice Linux requires the full general CPU extension support, i.e., rv64imafdc,
-and the ABI also needs to support hard double-float modules. For 32-bit Linux,
-build the toolchain with the flags of `--with-arch=rv32gc --with-abi=ilp32d`.
-
-### Build LLVM
-
-```bash
-$ cmake -B <LLVM_BUILD_PATH> \
- -DCMAKE_INSTALL_PREFIX=<TOOLCHAIN_OUT_DIR> \
- -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ \
- -DCMAKE_BUILD_TYPE=Release \
- -DLLVM_TARGETS_TO_BUILD="RISCV" \
- -DLLVM_ENABLE_PROJECTS="clang" \
- -DLLVM_DEFAULT_TARGET_TRIPLE="riscv64-unknown-linux-gnu" \
- -DLLVM_INSTALL_TOOLCHAIN_ONLY=On \
- -DDEFAULT_SYSROOT=../sysroot \
- -G Ninja \
- <LLVM_SRC_PATH>/llvm
-$ cmake --build <LLVM_BUILD_PATH> --target install
-```
-
-For 32-bit, change the LLVM target triple to `riscv32-unknown-linux-gnu`.
-
-## Build RISC-V bare-metal toolchain (32-bit)
-
-### Build 32-bit GCC
-
-```bash
-$ mkdir -p <GCC_BUILD_PATH>
-$ cd <GCC_BUILD_PATH>
-$ <GCC_SRC_PATH>/configure \
- --srcdir=<GCC_SRC_PATH> \
- --prefix=<TOOLCHAIN_OUT_DIR> \
- --with-arch=rv32i2p0mf2p0 \
- --with-abi=ilp32 \
- --with-cmodel=medany
-$ make -C <GCC_BUILD_PATH> newlib
-```
-
-Notice for bare-metal newlib there's no hard constraints on CPU feature and ABI
-support. However, LLVM for bare-metal only supports soft-float modules, so the
-GCC ABI setting needs to match that. Also, the ISA version needs to be specified,
-since binuils ISA supports 20191213 spec and LLVM is at v2.2 spec
-
-### Build 32-bit LLVM
-
-```bash
-$ cmake -B <LLVM_BUILD_PATH> \
- -DCMAKE_INSTALL_PREFIX=<TOOLCHAIN_OUT_DIR> \
- -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ \
- -DCMAKE_BUILD_TYPE=Release \
- -DLLVM_TARGETS_TO_BUILD="RISCV" \
- -DLLVM_ENABLE_PROJECTS="clang" \
- -DLLVM_DEFAULT_TARGET_TRIPLE="riscv32-unknown-elf" \
- -DLLVM_INSTALL_TOOLCHAIN_ONLY=On \
- -DDEFAULT_SYSROOT=../riscv32-unknown-elf \
- -G Ninja \
- <LLVM_SRC_PATH>/llvm
-$ cmake --build <LLVM_BUILD_PATH> --target install
-```
-
-#### Build compiler-rt
-
-This should not be necessary for the Shodan usage, but in case the compiler-rt
-builtins is required in the project (instead of using libgcc), it can be built
-with the additional commands:
-
-```bash
-$ export PATH=<TOOLCHAIN_OUT_DIR>/bin:${PATH}
-$ cmake -B <LLVM_BUILD_PATH>/compiler-rt \
- -DCMAKE_INSTALL_PREFIX=$PREFIX \
- -DCMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY \
- -DCMAKE_AR=<TOOLCHAIN_OUT_DIR>/bin/llvm-ar \
- -DCMAKE_NM=<TOOLCHAIN_OUT_DIR>/bin/llvm-nm \
- -DCMAKE_RANLIB=<TOOLCHAIN_OUT_DIR>/bin/llvm-ranlib \
- -DCMAKE_C_FLAGS="-march=rv32i2p0mf2p0v1p0" \
- -DCMAKE_ASM_FLAGS="-march=rv32i2p0mf2p0v1p0" \
- -DCMAKE_C_COMPILER=<TOOLCHAIN_OUT_DIR>/bin/clang \
- -DCMAKE_C_COMPILER_TARGET=riscv32-unknown-elf \
- -DCMAKE_ASM_COMPILER_TARGET=riscv32-unknown-elf \
- -DCOMPILER_RT_OS_DIR="clang/14.0.0/lib" \
- -DCMAKE_EXE_LINKER_FLAGS="-fuse-ld=lld" \
- -DCOMPILER_RT_BUILD_BUILTINS=ON \
- -DCOMPILER_RT_BUILD_SANITIZERS=OFF \
- -DCOMPILER_RT_BUILD_XRAY=OFF \
- -DCOMPILER_RT_BUILD_LIBFUZZER=OFF \
- -DCOMPILER_RT_BUILD_MEMPROF=OFF \
- -DCOMPILER_RT_BUILD_PROFILE=OFF \
- -DCOMPILER_RT_BAREMETAL_BUILD=ON \
- -DCOMPILER_RT_DEFAULT_TARGET_ONLY=ON \
- -DLLVM_CONFIG_PATH=<LLVM_BUILD_PATH>/bin/llvm-config \
- -DCMAKE_C_FLAGS="-march=rv32i2p0mf2p0v1p0 -mno-relax" \
- -DCMAKE_ASM_FLAGS="-march=rv32i2p0mf2p0v1p0 -mno-relax" \
- -G "Ninja" <LLVM_SRC_PATH>/compiler-rt
-$ cmake --build <LLVM_BUILD_PATH>/compiler-rt --target install
-```
-
-### Build newlib
-
-Even with compiler_rt to replace libgcc, we still need to build libc, libm, and
-libgloss as the toolchain prebuilts. They can also be built with clang
-The source code is at <https://github.com/riscv/riscv-newlib>
-
-***NOTE: The GCC utility tools needs to be built first.***
-
-```bash
-$ mkdir -p <NEWLIB_BUILD_PATH>
-$ cd <NEWLIB_BUILD_PATH>
-$ <NEWLIB_SRC_PATH>/configure \
- --target=riscv32-unknown-elf \
- --prefix=<TOOLCHAIN_OUT_DIR> \
- --enable-newlib-io-long-double \
- --enable-newlib-io-long-long \
- --enable-newlib-io-c99-formats \
- --enable-newlib-register-fini \
- CC_FOR_TARGET=clang \
- CXX_FOR_TARGET=clang++ \
- CFLAGS_FOR_TARGET="-march=rv32i2p0mf2p0v1p0 -O2 -D_POSIX_MODE -mno-relax" \
- CXXFLAGS_FOR_TARGET="-march=rv32i2p0mf2p0v1p0 -O2 -D_POSIX_MODE -mno-relax"
-$ make -j32
-$ make install
-```
-
-The newlib nano spec needs to be built separatedly and then merged with newlib.
-GNU top-level Makefile lists the flags to build nano and the merging script.
-
-## Test toolchain
-
-Run
-
-```bash
-<TOOLCHAIN_OUT_DIR>/bin/<arch>-<os>-<abi>-gcc -v
-```
-
-to see the supported ABIs, architectures, library paths, etc.
-
-Try to compile a simple c code (copied from CMake's package content, e.g.,
-`/usr/share/cmake-3.18/Modules/CMakeTestCCompiler.cmake`)
-
-```c
-#ifdef __cplusplus
-# error "The CMAKE_C_COMPILER is set to a C++ compiler"
-#endif
-#if defined(__CLASSIC_C__)
-int main(argc, argv)
- int argc;
- char* argv[];
-#else
-int main(int argc, char* argv[])
-#endif
-{ (void)argv; return argc-1;}
-```
-
-To build (32-bit bare-metal example)
-
-```bash
-$<TOOLCHAIN_OUT_DIR>/bin/clang -c testCCompiler.c -O --target=riscv32
-$<TOOLCHAIN_OUT_DIR>/bin/riscv32-unknown-elf-gcc testCCompiler.o -o testCCompiler -march=rv32gc -mabi=ilp32
-```
-
-You can also use `readelf` to inspect the object file before building the binary
-to see if the architecture and ABI match.
diff --git a/BuildTargetsExplained.md b/BuildTargetsExplained.md
deleted file mode 100644
index 480374e..0000000
--- a/BuildTargetsExplained.md
+++ /dev/null
@@ -1,61 +0,0 @@
-# Build targets in Shodan repository
-
-Here are lists of user-facing targets in Shodan. They are invoked with the
-command of `m [make flags] <target>`.
-
-## Build targets
-
-| Target | Source | Output | Description |
-| :-------------------| :-------------------------------| :----------------------| :----------------------------------------------------|
-| prereqs | | | Install build prerequisites |
-| tools | | cache | Install RISCV compiler and emulator tools, including |
-| | | out/host | Rust, GCC, CLANG, `verilator`, `qemu`, `renode` |
-| kata | kata/ | out/kata | SMC seL4 and user space applications |
-| matcha_tock_release | sw/tock/boards/opentitan-matcha | out/tock-release | The operating system running on the security core, |
-| | sw/libtock-rs | out/libtock-rs | and its Rust library |
-| multihart_boot_rom | sw/multihart_boot_rom | out/shodan_boot_rom | Shodan boot rom |
-| springbok | sw/vec | out/springbok/rvv | Vector core BSP and RVV test code |
-| iree_compiler | | out/host/iree_compiler | IREE host compiler |
-| iree_runtime | toolchain/iree | out/springbok_iree | IREE runtime applications |
-| | sw/vec_iree | | |
-| iree | | | Shorthand for `iree_compiler` and `iree_runtime` |
-| opentitan_sw_all | hw/opentitan | out/opentitan | HW testing binaries |
-| qemu | toolchain/ristv-qemu | out/host/qemu | QEMU emulator |
-| renode | sim/renode | out/host/renode | Renode emulator |
-| spike | toolchain/spike | out/host/spike | RISC-V ISA simulator (Spike) |
-| systemc | sim/systemc | out/host/systemc | libsystemc library |
-| springbok_systemc | hw/springbok/systemc | out/springbok/systemc | Springbok systemc implementation |
-| verilator | sim/verilator | out/host/verilator | System Verilog HW emulator |
-| simulate | | | E2E build and launch renode simulation. |
-| | | | Targets include `matcha_tock_release`, |
-| | | | `kata-bundle-release`, `multihart_boot_rom`, `iree` |
-| debug-simulation | | | Debug version of `simulate` to be used with GDB, |
-| | | | tock target is `matcha_tock_debug`; kata is |
-| | | | `kata-bundle-debug`.
-
-## Clean targets
-
-| Target | Description |
-| :--------------------| :---------------------------------------|
-| clean | Remove the whole out directory |
-| qemu_clean | Remove out/host/qemu |
-| renode_clean | Remove out/host/renode |
-| spike_clean | Remove out/host/spike |
-| verilator_clean | Remove out/host/verilator |
-| toolchain_clean | Remove cache/toolchain |
-| toolchain_llvm_clean | Remove cache/toolchain_iree_rv32imf |
-| opentitan_sw_clean | Remove out/opentitan |
-| tock_clean | Clean out/tock-debug |
-| | and out/tock-release (`make clean`) |
-
-## Optional toolchain targets (Used upon request)
-
-The following targets ***should not*** be called in the typical development.
-They should be called by CI and only upon request, i.e., *NOT* be built
-regularly.
-
-| Target | Description |
-| :--------------------| :--------------------------------------------------|
-| toolchain | Build GCC toolchain for the security core/SMC |
-| toolchain_llvm | Build LLVM toolchain for the vector core |
-| toolchain_vp | (Optional) Build GCC toolchain for the vector core |
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
new file mode 100644
index 0000000..ab993df
--- /dev/null
+++ b/CONTRIBUTING.md
@@ -0,0 +1,28 @@
+# How to Contribute
+
+We'd love to accept your patches and contributions to this project. There are
+just a few small guidelines you need to follow.
+
+## Contributor License Agreement
+
+Contributions to this project must be accompanied by a Contributor License
+Agreement. You (or your employer) retain the copyright to your contribution;
+this simply gives us permission to use and redistribute your contributions as
+part of the project. Head over to <https://cla.developers.google.com/> to see
+your current agreements on file or to sign a new one.
+
+You generally only need to submit a CLA once, so if you've already submitted one
+(even if it was for a different project), you probably don't need to do it
+again.
+
+## Code Reviews
+
+All submissions, including submissions by project members, require review. We
+use Gerrit code review for this purpose. Consult
+[Gerrit User Guide](https://gerrit-documentation.storage.googleapis.com/Documentation/3.8.2/intro-user.html)
+for more information.
+
+## Community Guidelines
+
+This project follows [Google's Open Source Community
+Guidelines](https://opensource.google/conduct/).
diff --git a/CantripGdbUserSpaceDebugging.md b/CantripGdbUserSpaceDebugging.md
index 994637d..5c3bb75 100644
--- a/CantripGdbUserSpaceDebugging.md
+++ b/CantripGdbUserSpaceDebugging.md
@@ -183,7 +183,11 @@
Renode console, not to the GDB cmdline. Note also that using regular GDB
breakpoints will generate complaints about not being able to set the breakpoints
when switching to a different thread. Best to use `sel4 break` in seL4 user
-threads and limit GDB `break` to contexts like the kernel or multihart_boot_rom.
+threads and limit GDB `break` to contexts like the kernel or boot rom.
+
+See [Renode GDB
+seL4 extensions](https://github.com/renode/renode/blob/master/tools/sel4_extensions/README.md)
+for more detail.
## Esoterica
diff --git a/CreateSpringbokVectorUnitTest.md b/CreateSpringbokVectorUnitTest.md
deleted file mode 100644
index 74dccf6..0000000
--- a/CreateSpringbokVectorUnitTest.md
+++ /dev/null
@@ -1,277 +0,0 @@
-# Create Springbok Vector Unit Test
-
-* [Step 0: Repo Sync and Build Prequisites](#step-0:-repo-sync-and-build-prequisites)
-* [Step 1: Select Instruction and Update Tracker](#step-1:-select-instruction-and-update-tracker)
-* [Step 2: Create operation definition in `${ROOTDIR}/sw/vec/softrvv/include`](#step-2:-create-operation-definition-in-`${rootdir}/sw/vec/softrvv/include`)
-* [Step 3: Add the header to softrvv.h](#step-3:-add-the-header-to-softrvv.h)
-* [Step 4: Add main test entry within the CMakeLists.txt](#step-4:-add-main-test-entry-within-the-cmakelists.txt)
-* [Step 5: Create subtest](#step-5:-create-subtest)
- * [Add brief softrvv test](#add-brief-softrvv-test)
- * [Add this smaller test to a 2nd Cmake file](#add-this-smaller-test-to-a-2nd-cmake-file)
-* [Step 6.1: Build and Run Elf with Renode/Qemu](#step-6.1:-build-and-run-elf-with-renode/qemu)
- * [Run Elf with Renode](#run-elf-with-renode)
- * [Run Elf with Qemu](#run-elf-with-qemu)
-* [Step 6.2 (Optional): Debug Elf with Renode/Qemu and gdb](#step-6.2-(optional):-debug-elf-with-renode/qemu-and-gdb)
-* [Step 6.3 (Optional): Object dump with binutils](#step-6.3-(optional):-object-dump-with-binutils)
-* [Step 7: Build and Run CTests](#step-7:-build-and-run-ctests)
-* [Step 8 (optional): view generated code](#step-8-(optional):-view-generated-code)
-* [Step 9: Mark Tests as Passing](#step-9:-mark-tests-as-passing)
-* [Step 10: Git Commit](#step-10:-git-commit)
-
-## Step 0: Repo Sync and Build Prequisites
-
-```sh
-repo sync
-m renode_clean renode
-m qemu_clean qemu
-```
-
-## Step 1: Select Instruction and Update Tracker
-
-Go to the following spreadsheet and write or select one's name under the `DRI - Unit Test`.
-
-[Select Instructions Here](https://docs.google.com/spreadsheets/d/1MVh0eQjdKkPiBOCXysfuLWWkFiL3gWzqvk-xA8-1rNg/edit#gid=1311575874)
-
-Now you've signed up to develop a unit test for this vector instruction :)
-
-
-Side Note: The following pivot table is very useful for quickly scanning through the instructions available:
-[DRI Pivot Table](https://docs.google.com/spreadsheets/d/1MVh0eQjdKkPiBOCXysfuLWWkFiL3gWzqvk-xA8-1rNg/edit#gid=1165644093)
-
-## Step 2: Create operation definition in `${ROOTDIR}/sw/vec/softrvv/include`
-
-Add definition of the operation as a file `softrvv_<op>h.h` in the following folder, where `<op>` is your operation (e.g. `vadd`, `vor`, `vmerge`, etc...):
-
-```sh
-${ROOTDIR}/sw/vec/softrvv/include
-```
-
-This test will contain the definition of the operation (e.g. `vadd` operation below):
-
-```cpp
-template <typename T>
-void vadd_vi(T *dest, T *src1, T src2, int32_t avl) {
- for (int32_t idx = 0; idx < avl; idx++) {
- dest[idx] = src1[idx] + src2;
- }
-}
-
-```
-
-See [softrvv_vadd.h](https://spacebeaker.googlesource.com/shodan/sw/vec/+/refs/heads/master/softrvv/include/softrvv_vadd.h) for a reference.
-
-## Step 3: Add the header to softrvv.h
-
-Add the header file as an includes in the `softrvv.h`:
-
-```cpp
-#include "softrvv_vadd.h"
-```
-
-` softrvv.h ` is in the `${ROOTDIR}/sw/vec/softrvv/include` directory.
-
-
-
-## Step 4: Add main test entry within the CMakeLists.txt
-
-
-`cd` into the following folder, and edit the `CMakeLists.txt` file there
-
-```sh
-${ROOTDIR}/sw/vec/tests/CMakeLists.txt
-```
-
-Add an entry there with the opcode formats relavant to the operation:
-
-```cmake
-vec_cc_generated_test(
- NAME
- vadd
- OPFMT
- OPIVV
- OPIVX
- OPIVI
- LINKOPTS
- -Xlinker --defsym=__itcm_length__=200K
-)
-```
-
-Note: this operation uses OPIVV, OPIVX, and OPIVI formats.
-
-A range of tests will be be autogenerated for each one of the OPFMT's added.
-
-The Mako templates for each OPFMT test can be found at `${ROOTDIR}/sw/vec/tests/templates`.
-
-Note on `__itcm_length__`: keeping this number low for each test helps our overall performance, most tests are good with 128K, some might need a little more memory (`ctest` will let you know if you need to add more here).
-
-## Step 5: Create subtest
-
-Please also add a small manual test the new softvv instruction.
-Steps delineated as follows:
-
-### Add brief softrvv test
-
-```sh
-cd ${ROOTDIR}/sw/vec/softrvv/tests
-```
-
-Then add a test-file named `softrvv_<op>_test.cpp`.
-
-See other files in the same folder as references.
-
-In this test-file you'll define a few simple test cases to run on the defined functions:
-
-See for example this VV test from [softrvv_vadd_test.cpp](https://spacebeaker.googlesource.com/shodan/sw/vec/+/refs/heads/master/softrvv/tests/softrvv_vadd_test.cpp):
-
-```cpp
-uint32_t src1[] = {1, 2, 3, 4, 5};
-uint32_t src2[] = {1, 2, 3, 4, 5};
-
-uint32_t ref_vv[] = {2, 4, 6, 8, 10};
-
-TEST_F(SoftRvvVaddTest, VV) {
- softrvv::vadd_vv<uint32_t>(dest, src1, src2, AVL_CONST);
- ASSERT_EQ(memcmp(dest, ref_vv, sizeof(dest)), 0);
-}
-```
-
-### Add this smaller test to a 2nd Cmake file
-
-Edit another CMakeLists.txt file (path below):
-
-```sh
-${ROOTDIR}/sw/vec/softrvv/tests/CMakeLists.txt
-```
-
-Add the subtest just created:
-
-```cmake
-vec_cc_test(
- NAME
- softrvv_vadd
- SRCS
- softrvv_vadd_test.cpp
- DEPS
- softrvv
- LINKOPTS
- -Xlinker --defsym=__itcm_length__=128K
-```
-
-## Step 6.1: Build and Run Elf with Renode/Qemu
-
-`cd` into the root directory (`cd $ROOTDIR`), and build the elf with:
-
-```sh
-m springbok
-```
-
-### Run Elf with Renode
-
-From the root directory, run `sim_springbok`
-
-```sh
-sim_springbok ./out/springbok/rvv/tests/vadd_test.elf
-```
-
-This will run the single elf, and if there is an error, can give useful
-information, such as the PC and MTVAL associated with any illegal instruction.
-
-### Run Elf with Qemu
-
-From the root directory, run `qemu_sim_springbok`
-
-```sh
-qemu_sim_springbok ./out/springbok/rvv/tests/vadd_test.elf
-```
-
-## Step 6.2 (Optional): Debug Elf with Renode/Qemu and gdb
-
-To debug an elf, open two console sessions in the `$ROOTDIR`, in one run start a simulator
-(either `sim_springbok` or `qemu_sim_springbok`):
-
-Start Renode simulation:
-```sh
-sim_springbok ./out/springbok/rvv/tests/vadd_test.elf debug
-```
-Alternatively, start Qemu simulation:
-
-```sh
-qemu_sim_springbok ./out/springbok/rvv/tests/vadd_test.elf -s -S
-```
-
-Now, in the other console session run the following command to start a gdb session:
-
-```sh
-cache/toolchain/bin/riscv32-unknown-elf-gdb -ex "target remote :3333" out/springbok/rvv/tests/vadd_test.elf
-```
-
-Note: To run GDB with the Qemu simulation, use
-
-```sh
-cache/toolchain/bin/riscv32-unknown-elf-gdb -ex "target remote :1234" out/springbok/rvv/tests/vadd_test.elf
-```
-
-First, in the Renode session, type `start`.
-
-Then, in the gdb session, type the following,
-
-```sh
-layout split
-b main
-```
-
-and step through as usual with GDB.
-
-## Step 6.3 (Optional): Object dump with binutils
-
-Sadly, gdb cannot presently decode RVV machine code into assembly instructions.
-
-However, the objdump __is__ able to decode the RVV machine code into assembly.
-To do this, obtain the program counter for the RVV machine code in question, then perform an objdump.
-
-Run this on the elf (while in the `$ROOTDIR`):
-```sh
-cache/toolchain_iree_rv32imf/bin/riscv32-unknown-elf-objdump -d out/springbok/rvv/tests/vadd_test.elf | less
-```
-
-Then search for the PC for any instruction of interest.
-
-## Step 7: Build and Run CTests
-
-CTests must be run from the `${ROOTDIR}/out/springbok` directory.
-
-`cd ${ROOTDIR}/out/springbok`
-
-Next, using Regex in the quoted section, select Qemu, Renode, and/or other operations
-to include in a test run:
-
-```sh
-m springbok && ctest --verbose -R ".*vadd.*" --gtest_color=yes
-```
-
-## Step 8 (optional): view generated code
-
-Code for the main test was autogenerated, however by `cd`'ing into the following directory, one can inspect the generated code.
-
-```sh
-${ROOTDIR}/out/springbok/rvv/tests/generated/
-```
-
-## Step 9: Mark Tests as Passing
-
-Note: at minimum, one's test should be expected to pass in Qemu. Since Renode vec support is WIP, a unit test failing may indicate problem in the Renode implementation.
-
-On the [unit test tracker](https://docs.google.com/spreadsheets/d/1MVh0eQjdKkPiBOCXysfuLWWkFiL3gWzqvk-xA8-1rNg/edit#gid=1311575874):
-
-1. Mark whether the unit test passes in Qemu
-2. Mark whether the unit test passes in Renode
-3. Mark the instruction "Springbok Unit Test" as "implemented"
-
-## Step 10: Git Commit
-
-At this point there are two commitable chunks:
-
-1. operation definition, softrvv.h change, and CMakeLists.txt entry.
-2. the manual test and its CMakeLists.txt entry
-
-These may be added as either one CL, or two CL's separating these two contributions.
diff --git a/GenerateAndInspectIreeExecutables.md b/GenerateAndInspectIreeExecutables.md
index 066e7c8..cc4c10f 100644
--- a/GenerateAndInspectIreeExecutables.md
+++ b/GenerateAndInspectIreeExecutables.md
@@ -6,24 +6,22 @@
## Generate IREE executables
IREE's main codegen tools are
-[iree-opt](https://github.com/google/iree/blob/main/iree/tools/iree-opt-main.cc)
+[iree-opt](https://github.com/openxla/iree/blob/main/tools/iree-opt-main.cc)
(generate MLIR representations) and
-[iree-translate](https://github.com/google/iree/blob/main/iree/tools/iree-translate-main.cc)
+[iree-compiler](https://github.com/openxla/iree/blob/main/tools/iree-compile-main.cc)
(generate the IREE bytecode modules). IREE codegen flow is based on LLVM and
MLIR, so it utilizes the typical LLVM flags to define the machine targets. For
example, to generate the IREE bytecode module from a vector multiply MLIR:
```bash
-${OUT}/host/iree_compiler/install/bin/iree-translate \
- -iree-input-type=mhlo \
- -iree-mlir-to-vm-bytecode-module \
- -iree-hal-target-backends=dylib-llvm-aot \
- -iree-llvm-target-triple=riscv32-pc-linux-elf \
- -iree-llvm-target-cpu=generic-rv32 \
- -iree-llvm-target-cpu-features="+m,+f" \
- -iree-llvm-target-abi=ilp32 \
- -iree-llvm-embedded-linker-path=${OUT}/host/iree_compiler/install/bin/lld \
- ${ROOTDIR}/toolchain/iree/iree/samples/simple_embedding/simple_embedding_test.mlir \
+${CACHE}/iree_compiler/install/bin/iree-compile \
+ --iree-hal-target-backends=llvm-cpu
+ --iree-llvm-target-triple=riscv32-pc-linux-elf \
+ --iree-llvm-target-cpu=generic-rv32 \
+ --iree-llvm-target-cpu-features="+m,+f" \
+ --iree-llvm-target-abi=ilp32 \
+ --iree-llvm-embedded-linker-path=${CACHE}/iree_compiler/install/bin/lld \
+ ${ROOTDIR}/toolchain/iree/samples/simple_embedding/simple_embedding_test.mlir \
-o /tmp/simple_mul-llvm_aot.vmfb
```
@@ -32,7 +30,7 @@
* iree-hal-target-backends: The HAL device (library + dispatcher) target for
the workload. In Shodan, the supported targets are:
- * dylib-llvm-aot: the dynamic library for LLVM ahead-of-time (AOT) compilation.
+ * llvm-cpu: the library for LLVM ahead-of-time (AOT) compilation.
* vmvx
* iree-llvm-target-triple: The flag is populated to LLVM target triple.
* iree-llvm-target-cpu: The flag populated to LLVM target cpu. It can be
@@ -60,7 +58,7 @@
7z e -aoa -bb0 <vmfb> -y
```
-* riscv-v-vector-bits-min and riscv-v-fixed-length-vector-lmul-max: If the
+* riscv-v-fixed-length-vector-lmul-max: If the
vector extension is enabled in `iree-llvm-target-cpu-features`, the RVV VLS
(vector length specific) code will be generated with the vector length specified
by these two options.
@@ -74,7 +72,7 @@
weights in the ML model.
```bash
-${OUT}/host/iree-compiler/install/bin/iree-dump-module <vmfb file>
+${CACHE}/iree-compiler/install/bin/iree-dump-module <vmfb file>
```
With the linker artifact enabled, The `.so` file contends the dispatch functions
@@ -96,10 +94,10 @@
Use `iree-opt` to check the IR output
```bash
-${OUT}/host/iree-compiler/install/bin/iree-opt \
+${CACHE}/iree-compiler/install/bin/iree-opt \
-print-ir-after-all \
-iree-transformation-pipeline \
- -iree-hal-target-backends=dylib-llvm-aot \
+ -iree-hal-target-backends=llvm-cpu \
-iree-llvm-target-triple=riscv32-pc-linux-elf \
-iree-llvm-target-cpu=generic-rv32 \
-iree-llvm-target-cpu-features="+m,+f" \
diff --git a/GettingStarted.md b/GettingStarted.md
index 80ab3f8..988d9ff 100644
--- a/GettingStarted.md
+++ b/GettingStarted.md
@@ -1,9 +1,7 @@
# What is this?
-This is Project Shodan, a project to research the fusion of novel hardware and
-software architectures to produce a low-power, ambient AI core. For more
-information, see our
-[internal site](https://sites.google.com/corp/google.com/cerebrahardware/projects/current-projects/shodan).
+This is Project Open Se Cura, a project to research the fusion of novel hardware and
+software architectures to produce a low-power, ambient AI core.
## Developing in this Codebase
@@ -14,12 +12,6 @@
by going to [googlesource.com/new-password](https://www.googlesource.com/new-password)
and pasting the provided script into a terminal.
-If you are a Googler using youre @google.com account you also need to run the following command to switch from http to sso:
-
-```bash
-git config --global "url.sso://spacebeaker/.insteadOf" "https://spacebeaker.googlesource.com/" && git config --global --add "url.sso://spacebeaker/.insteadOf" "https://spacebeaker-review.googlesource.com/" && git config --global --add "url.sso://spacebeaker/.insteadOf" "http://spacebeaker.googlesource.com/" && git config --global --add "url.sso://spacebeaker/.insteadOf" "http://spacebeaker-review.googlesource.com/"
-```
-
Now you need to pull down a copy of the `repo`
tool from our public facing sites and add it to your path:
@@ -43,7 +35,7 @@
current release branch.
```bash
-repo init -u https://spacebeaker.googlesource.com/shodan/manifest -g default,internal --no-use-superproject
+repo init -u https://opensecura.googlesource.com/manifest
repo sync -j$(nproc)
```
@@ -58,7 +50,7 @@
source build/setup.sh
```
-For non-gLinux systems: Add the bazel apt repository to your machines sources.
+Add the bazel apt repository to your machines sources.
Instructions @ <https://bazel.build/install/ubuntu#add-dis-uri>
Install the prerequisites:
@@ -73,136 +65,6 @@
m tools -j$(nproc)
```
-## Day-to-day Development Workflow
-
-In general, working with repo is relatively simple:
-
- 1. Create a working topic branch to make changes on with `repo start
- ${TOPICNAME}`
- 2. Make your changes to the files. Add them with `git add -A` and commit with
- `git commit`.
- 3. Upload your changes with `repo upload --re ${REVIEWER} --cc ${CC_LIST}`
- 4. Go to the URL repo spits out to read and reply to comments.
- 5. Eventually your reviewer will give you a +2 LGTM on your change. To submit,
- click the "SUBMIT" button on the change in the web interface.
- 6. Run `repo sync -j$(nproc)` to update.
- 7. Run `repo prune` to remove your topic branch.
-
-For more information on how to use repo and git effectively, take a look at the
-[official documentation](https://source.android.com/setup/create/coding-tasks).
-
-### A Note on Code Review Policies
-
-In the Shodan project, we follow a "sticky +2" policy.
-
-What this means is that you *must* get a +2 Code Review from a peer, or a TL.
-Gerrit will automatically pass any +2 Code Review scores you receive when you
-upload a patchset with minor changes. This policy is in place so that we can
-quickly get through code review and get our code submitted without requiring
-lots of round-trips with your reviewers.
-
-If you change significant parts of the CL post-+2, please ask for additional
-review from your peers in a reply. Note: two +1s does *not* count as a +2!
-
-You can't self-+2 your own CL, no matter the urgency or how simple the
-change is! This policy ensures the code change is peer reviewed, and prevent us
-from getting in trouble with security/compliance. If you don't know who to send
-a CL to, put one of the TLs on the review list, and they'll redirect it
-appropriately, or review your change.
-
-As a reviewer, please use good judgement to help the team keep the good
-momentum: If you provide a +1 score, please note in your comment who should
-provide the +2; if your comments are minor changes about style, format, etc.,
-and not related to the functionality of the code, please provide +2 so the code
-owner can address the comments and submit the code without further review.
-
-### Who are the TLs?
-
-At the time of this writing, the TLs are:
-
-Cindy Liu <hcindyl@>
-June Tate-Gans <jtgans@>
-Bangfei Pan <pbf@>
-Steve Xu <stevexu@>
-
-Finally, if you can't get one of the above people, please put Kai Yick
-<kingkai@> on the review line.
-
-*Special note if you're listed above*: you still must get your +2 from someone
-else -- we need the TLs to lead by example and demonstrate the appropriate
-behavior.
-
-### How to sync my local copy with latest?
-
-```bash
-repo sync -j$(nproc)
-```
-
-Then if you have any outstanding branches, a `repo rebase` will help.
-
-### How to send code for review?
-
-To upload a branch to gerrit for review, do this:
-
-```bash
-repo upload --re reviewer1,reviewer2 --cc email@host.com,email2@host2.com
-```
-
-Reviewers can be specified as usernames or full email addresses, likewise for
-`--cc`.
-
-Repo will then output a URL for you to visit that allows you to make comments
-and abandon and merge the changes into the repository. To make changes during
-the review process, make your changes to the files, then:
-
-```bash
-git add -A # To add the files you've changed
-git commit --amend # To update the previous change
-repo upload -t --re ${REVIEWER} --cc ${CC_LIST} # To upload the change to Gerrit for review
-```
-
-### How to download CLs of a Gerrit topic?
-
-If you are reviewing a bunch of CLs from different projects, that are grouped
-under a single topic in Gerrit, you can download the latest CL of each project
-(replace `TOPIC` with the topic you are reviewing):
-
-```bash
-download-gerrit-topic.py TOPIC
-```
-
-By default, the new branches under which the CLs will be downloaded are named
-`TOPIC`. See `download-gerrit-topic.py --help` for more details.
-
-### Help! I'm on a limited-bandwidth connection, and need to stop downloading tooling
-
-There's an environment variable you can set called `PIN_TOOLCHAINS` to prevent
-download attempts for various toolchains in the system. The format is a
-space-delimited list of words that includes which toolchains you wish to prevent
-downloading automatically during a build.
-
-At the moment, this environment variable can be set to any of the following
-words:
-
- `renode` - prevents downloading of the latest Renode binary build.
-
- `iree` - prevents downloading of the latest IREE compiler toolchain.
-
-Ie:
-
-```bash
-export PIN_TOOLCHAINS="renode iree"
-```
-
-*Note well*: if you set this variable, the output or behavior of any of the
-preceding toolchains may be bad or incorrect. Please do not file bugs against
-these components if you have this variable set!
-
-### Help! IREE, Renode, or another toolchain is misbehaving
-
-Did you set `PIN_TOOLCHAINS`? If so, please unset this environment variable and
-retry your build.
-
## Repository Layout
Our layout is pretty simple:
@@ -218,10 +80,6 @@
The cached cross-compilation toolchain, including rust and RISC-V GCC/LLVM
toolchain.
-### cicd/
-
-Contains continuous integration scripts and tooling for Jenkins, our CI/CD tool.
-
### docs/
Lots of extra documentation (we hope) about how the repo is laid out, how the
@@ -232,18 +90,23 @@
Contains all of the source code and RTL required to build the Shodan
hardware, as well as simulate it in Verilator.
-#### opentitan
+#### ip
-Security core.
-
-#### ibex
-
-System management controller (SMC).
+External contributor's HW IPs.
#### kelvin(HW)
RTL of the ML core for ML acceleration.
+#### matcha
+
+Top-Level integrated HW platform of the multi-core system.
+
+#### opentitan-upstream
+
+[Opentitan](https://github.com/lowRISC/opentitan) repository as a library to leverage
+its IP for the security core and peripheral IP design.
+
### cantrip/
Operating system software for the SMC; including seL4 kernel & CAmkES framework,
@@ -277,17 +140,11 @@
#### matcha
-The platform and application SW running on the secured core.
-
-#### multihart_boot_rom
-
-Bootstrap for System Management Controller, Security Core, and Vector Core. This
-is the first software to run after reset; it does low-level hardware setup and
-starts TockOs (SC) and seL4 (SMC).
+The platform and application SW running on the security core.
#### pigweed
-pigweed frameworks. Currently it is used for vector core functional tests.
+pigweed frameworks. Currently it is used for springbok core functional tests.
#### tflite-micro
@@ -298,9 +155,9 @@
The operating system running on the Security Core.
-#### vec (deprecated)
+#### vec
-Springbok ML core BSP, as well as the RVV instruction functional tests.
+Springbok (RVV) ML core BSP, as well as the RVV instruction functional tests.
#### vec_iree
@@ -309,17 +166,17 @@
### toolchain/
-Contains the src to build the RISCV QEMU emulator, and
-[IREE](https://github/com/google/iree) toolchain for ML models.
+Contains[IREE](https://github/com/openxla/iree) toolchain for ML models.
## Build and Test ML Artifacts
-The ML executable is built with [IREE](https://github.com/google/iree) workflow,
+The ML executable is built with [IREE](https://github.com/openxla/iree) workflow,
targeted to RISCV 32-bit bare-metal config.
To build the IREE targets:
```bash
+set-platform nexus
m iree
```
@@ -351,6 +208,7 @@
To run the full system simulation, build the default target:
```bash
+set-platform shodan
m
```
@@ -437,7 +295,6 @@
## More Information
-For more available Shodan build targets, please see [Build target lists](./BuildTargetsExplained.md),
-or use the in-project command of `hmm` and `hmm <target name>`.
+For more available Shodan build targets, please use the in-project command of `hmm` and `hmm <target name>`.
-Also, [Information on how to use repo](https://go/repo)
+Also, [Information on how to use repo](https://source.android.com/docs/setup/create/repo)
diff --git a/LICENSE b/LICENSE
new file mode 100644
index 0000000..d645695
--- /dev/null
+++ b/LICENSE
@@ -0,0 +1,202 @@
+
+ Apache License
+ Version 2.0, January 2004
+ http://www.apache.org/licenses/
+
+ TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+ 1. Definitions.
+
+ "License" shall mean the terms and conditions for use, reproduction,
+ and distribution as defined by Sections 1 through 9 of this document.
+
+ "Licensor" shall mean the copyright owner or entity authorized by
+ the copyright owner that is granting the License.
+
+ "Legal Entity" shall mean the union of the acting entity and all
+ other entities that control, are controlled by, or are under common
+ control with that entity. For the purposes of this definition,
+ "control" means (i) the power, direct or indirect, to cause the
+ direction or management of such entity, whether by contract or
+ otherwise, or (ii) ownership of fifty percent (50%) or more of the
+ outstanding shares, or (iii) beneficial ownership of such entity.
+
+ "You" (or "Your") shall mean an individual or Legal Entity
+ exercising permissions granted by this License.
+
+ "Source" form shall mean the preferred form for making modifications,
+ including but not limited to software source code, documentation
+ source, and configuration files.
+
+ "Object" form shall mean any form resulting from mechanical
+ transformation or translation of a Source form, including but
+ not limited to compiled object code, generated documentation,
+ and conversions to other media types.
+
+ "Work" shall mean the work of authorship, whether in Source or
+ Object form, made available under the License, as indicated by a
+ copyright notice that is included in or attached to the work
+ (an example is provided in the Appendix below).
+
+ "Derivative Works" shall mean any work, whether in Source or Object
+ form, that is based on (or derived from) the Work and for which the
+ editorial revisions, annotations, elaborations, or other modifications
+ represent, as a whole, an original work of authorship. For the purposes
+ of this License, Derivative Works shall not include works that remain
+ separable from, or merely link (or bind by name) to the interfaces of,
+ the Work and Derivative Works thereof.
+
+ "Contribution" shall mean any work of authorship, including
+ the original version of the Work and any modifications or additions
+ to that Work or Derivative Works thereof, that is intentionally
+ submitted to Licensor for inclusion in the Work by the copyright owner
+ or by an individual or Legal Entity authorized to submit on behalf of
+ the copyright owner. For the purposes of this definition, "submitted"
+ means any form of electronic, verbal, or written communication sent
+ to the Licensor or its representatives, including but not limited to
+ communication on electronic mailing lists, source code control systems,
+ and issue tracking systems that are managed by, or on behalf of, the
+ Licensor for the purpose of discussing and improving the Work, but
+ excluding communication that is conspicuously marked or otherwise
+ designated in writing by the copyright owner as "Not a Contribution."
+
+ "Contributor" shall mean Licensor and any individual or Legal Entity
+ on behalf of whom a Contribution has been received by Licensor and
+ subsequently incorporated within the Work.
+
+ 2. Grant of Copyright License. Subject to the terms and conditions of
+ this License, each Contributor hereby grants to You a perpetual,
+ worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+ copyright license to reproduce, prepare Derivative Works of,
+ publicly display, publicly perform, sublicense, and distribute the
+ Work and such Derivative Works in Source or Object form.
+
+ 3. Grant of Patent License. Subject to the terms and conditions of
+ this License, each Contributor hereby grants to You a perpetual,
+ worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+ (except as stated in this section) patent license to make, have made,
+ use, offer to sell, sell, import, and otherwise transfer the Work,
+ where such license applies only to those patent claims licensable
+ by such Contributor that are necessarily infringed by their
+ Contribution(s) alone or by combination of their Contribution(s)
+ with the Work to which such Contribution(s) was submitted. If You
+ institute patent litigation against any entity (including a
+ cross-claim or counterclaim in a lawsuit) alleging that the Work
+ or a Contribution incorporated within the Work constitutes direct
+ or contributory patent infringement, then any patent licenses
+ granted to You under this License for that Work shall terminate
+ as of the date such litigation is filed.
+
+ 4. Redistribution. You may reproduce and distribute copies of the
+ Work or Derivative Works thereof in any medium, with or without
+ modifications, and in Source or Object form, provided that You
+ meet the following conditions:
+
+ (a) You must give any other recipients of the Work or
+ Derivative Works a copy of this License; and
+
+ (b) You must cause any modified files to carry prominent notices
+ stating that You changed the files; and
+
+ (c) You must retain, in the Source form of any Derivative Works
+ that You distribute, all copyright, patent, trademark, and
+ attribution notices from the Source form of the Work,
+ excluding those notices that do not pertain to any part of
+ the Derivative Works; and
+
+ (d) If the Work includes a "NOTICE" text file as part of its
+ distribution, then any Derivative Works that You distribute must
+ include a readable copy of the attribution notices contained
+ within such NOTICE file, excluding those notices that do not
+ pertain to any part of the Derivative Works, in at least one
+ of the following places: within a NOTICE text file distributed
+ as part of the Derivative Works; within the Source form or
+ documentation, if provided along with the Derivative Works; or,
+ within a display generated by the Derivative Works, if and
+ wherever such third-party notices normally appear. The contents
+ of the NOTICE file are for informational purposes only and
+ do not modify the License. You may add Your own attribution
+ notices within Derivative Works that You distribute, alongside
+ or as an addendum to the NOTICE text from the Work, provided
+ that such additional attribution notices cannot be construed
+ as modifying the License.
+
+ You may add Your own copyright statement to Your modifications and
+ may provide additional or different license terms and conditions
+ for use, reproduction, or distribution of Your modifications, or
+ for any such Derivative Works as a whole, provided Your use,
+ reproduction, and distribution of the Work otherwise complies with
+ the conditions stated in this License.
+
+ 5. Submission of Contributions. Unless You explicitly state otherwise,
+ any Contribution intentionally submitted for inclusion in the Work
+ by You to the Licensor shall be under the terms and conditions of
+ this License, without any additional terms or conditions.
+ Notwithstanding the above, nothing herein shall supersede or modify
+ the terms of any separate license agreement you may have executed
+ with Licensor regarding such Contributions.
+
+ 6. Trademarks. This License does not grant permission to use the trade
+ names, trademarks, service marks, or product names of the Licensor,
+ except as required for reasonable and customary use in describing the
+ origin of the Work and reproducing the content of the NOTICE file.
+
+ 7. Disclaimer of Warranty. Unless required by applicable law or
+ agreed to in writing, Licensor provides the Work (and each
+ Contributor provides its Contributions) on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+ implied, including, without limitation, any warranties or conditions
+ of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+ PARTICULAR PURPOSE. You are solely responsible for determining the
+ appropriateness of using or redistributing the Work and assume any
+ risks associated with Your exercise of permissions under this License.
+
+ 8. Limitation of Liability. In no event and under no legal theory,
+ whether in tort (including negligence), contract, or otherwise,
+ unless required by applicable law (such as deliberate and grossly
+ negligent acts) or agreed to in writing, shall any Contributor be
+ liable to You for damages, including any direct, indirect, special,
+ incidental, or consequential damages of any character arising as a
+ result of this License or out of the use or inability to use the
+ Work (including but not limited to damages for loss of goodwill,
+ work stoppage, computer failure or malfunction, or any and all
+ other commercial damages or losses), even if such Contributor
+ has been advised of the possibility of such damages.
+
+ 9. Accepting Warranty or Additional Liability. While redistributing
+ the Work or Derivative Works thereof, You may choose to offer,
+ and charge a fee for, acceptance of support, warranty, indemnity,
+ or other liability obligations and/or rights consistent with this
+ License. However, in accepting such obligations, You may act only
+ on Your own behalf and on Your sole responsibility, not on behalf
+ of any other Contributor, and only if You agree to indemnify,
+ defend, and hold each Contributor harmless for any liability
+ incurred by, or claims asserted against, such Contributor by reason
+ of your accepting any such warranty or additional liability.
+
+ END OF TERMS AND CONDITIONS
+
+ APPENDIX: How to apply the Apache License to your work.
+
+ To apply the Apache License to your work, attach the following
+ boilerplate notice, with the fields enclosed by brackets "[]"
+ replaced with your own identifying information. (Don't include
+ the brackets!) The text should be enclosed in the appropriate
+ comment syntax for the file format. We also recommend that a
+ file or class name and description of purpose be included on the
+ same "printed page" as the copyright notice for easier
+ identification within third-party archives.
+
+ Copyright [yyyy] [name of copyright owner]
+
+ Licensed under the Apache License, Version 2.0 (the "License");
+ you may not use this file except in compliance with the License.
+ You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+ Unless required by applicable law or agreed to in writing, software
+ distributed under the License is distributed on an "AS IS" BASIS,
+ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ See the License for the specific language governing permissions and
+ limitations under the License.
diff --git a/QemuVectorTestingAndDebugging.md b/QemuVectorTestingAndDebugging.md
deleted file mode 100644
index 620f411..0000000
--- a/QemuVectorTestingAndDebugging.md
+++ /dev/null
@@ -1,118 +0,0 @@
-# Qemu Vector Testing and Debugging
-
-1. [Qemu Setup](#qemu-setup)
- 1. [Build steps:](#build-steps)
- 2. [Start Qemu](#start-qemu)
- 3. [Exiting Qemu](#exiting-qemu)
-2. [Running GDB](#running-gdb)
- 1. [Use the following command to run GDB](#use-the-following-command-to-run-gdb)
-3. [GDBGUI Setup](#gdbgui-setup)
- 1. [Installing gdbgui](#installing-gdbgui)
- 2. [Running gdbgui](#running-gdbgui)
- 3. [gdbgui window](#gdbgui-window)
-4. [GDB Usage](#gdb-usage)
- 1. [Some Useful GDB instructions](#some-useful-gdb-instructions)
-5. [Aliases for convenience](#aliases-for-convenience)
-6. [Advanced Usage](#advanced-usage)
- 1. [Debugging Qemu](#debugging-qemu)
-
-## Qemu Setup
-
-### Build steps:
-
-```
-source build/setup.sh
-m tools
-m qemu
-```
-
-### Start Qemu
-
-Use the following command to start qemu with debugging:
-
-```
-qemu-system-riscv32 -M opentitan -kernel $ROOTDIR/out/shodan/build-out/sw_shodan/device/examples/hello_vector/hello_vector_sim_verilator.elf -bios $ROOTDIR/out/shodan/build-bin/sw/device/boot_rom/boot_rom_fpga_nexysvideo.elf -nographic -cpu rv32,x-v=true,vlen=512,vext_spec=v1.0 -s -S
-```
-
-Notes on above command:
-
-- `-s` - starts the gdb server
-- `-S` - waits on execution for a client to connect
-
-The above commands can be omitted to run qemu without starting a gdb server.
-
-### Exiting Qemu
-
-To exit qemu, in the same teriminal, press `Ctrl-a` then `Ctrl-x`.
-
-## Running GDB
-
-### Use the following command to run GDB
-
-Run GDB to create a gdb session in the CLI:
-
-```
-$ROOTDIR/cache/toolchain_vp/bin/riscv32-unknown-elf-gdb $ROOTDIR/out/shodan/build-bin/sw/device/examples/hello_vector/hello_vector_sim_verilator.elf --eval-command "target remote :1234"
-```
-
-## GDBGUI Setup
-
-### Installing gdbgui
-
-`python3 -m pip install gdbgui`
-
-### Running gdbgui
-
-Use the following command to begin gdbgui:
-
-```
-export PURE_PYTHON=1; gdbgui -g "$ROOTDIR/out/host/toolchain_vp/bin/riscv32-unknown-elf-gdb $ROOTDIR/out/shodan/build-bin/sw/device/examples/hello_vector/hello_vector_sim_verilator.elf --eval-command \"target remote :1234\""
-```
-
-### gdbgui window
-
-lower left window takes conventional gdb commands.
-
-To start, set up a breakpoint (e.g. `b main`), then hit continue (`c`)
-
-
-
-## GDB Usage
-
-With one of the gdb methods working, you can now step through and check
-register contents.
-
-### Some Useful GDB instructions
-
-- `break main` (or `b main` for short) - makes a breakpoint at the main, more
- info [here](https://ftp.gnu.org/old-gnu/Manuals/gdb/html_node/gdb_27.html)
-- `continue` (or `c` for short) - runs until breakpoint
-- `step` (or `s` for short) - runs one more line, will "step into" subroutines
-- `next` (or `n` for short) - runs one more line, will "step over" subroutines
-- `info reg` - print all registers
-- `info reg a1` - print scalar register a1
-- `info vector` - print all vector registers and vector csr's
-
-## Aliases for convenience
-
-First source `build/setup.sh` to set up the enviroment in the respective
-terminal, and then these aliases can speed up the workflow:
-
-```
-alias run_gdb="$ROOTDIR/cache/toolchain_vp/bin/riscv32-unknown-elf-gdb $ROOTDIR/out/shodan/build-bin/sw/device/examples/hello_vector/hello_vector_sim_verilator.elf --eval-command \"target remote :1234\""
-alias run_gdb_gui="export PURE_PYTHON=1; gdbgui -g '$ROOTDIR/cache/toolchain_vp/bin/riscv32-unknown-elf-gdb $ROOTDIR/out/shodan/build-bin/sw/device/examples/hello_vector/hello_vector_sim_verilator.elf --eval-command \"target remote :1234\"'"
-alias run_qemu="qemu-system-riscv32 -M opentitan -kernel $ROOTDIR/out/shodan/build-out/sw_shodan/device/examples/hello_vector/hello_vector_sim_verilator.elf -bios $ROOTDIR/out/shodan/build-bin/sw/device/boot_rom/boot_rom_fpga_nexysvideo.elf -nographic -cpu rv32,x-v=true,vlen=512,vext_spec=v1.0 -s -S"
-```
-
-## Advanced Usage
-
-### Debugging Qemu
-
-```
-gdb --eval-command "b helper_vsetvl" --eval-command "run" --args qemu-system-riscv32 -s -S -nographic -cpu rv32,x-v=true,vlen=512,vext_spec=v1.0,s=true,mmu=true -M opentitan -kernel out/shodan/build-out/sw_shodan/device/examples/hello_vector/hello_vector_sim_verilator.elf -bios out/shodan/build-bin/sw/device/boot_rom/boot_rom_fpga_nexysvideo.elf -nographic
-```
-
-Above starts up qemu with the debugger and breaks the simulator on the
-`vsetvl` instruction so that you can check the state of the cpu.
-
-This may be useful when debugging qemu itself.
diff --git a/README.md b/README.md
new file mode 120000
index 0000000..8953704
--- /dev/null
+++ b/README.md
@@ -0,0 +1 @@
+GettingStarted.md
\ No newline at end of file
diff --git a/RenodeTlibWorkflowDocumentation.md b/RenodeTlibWorkflowDocumentation.md
deleted file mode 100644
index bb43227..0000000
--- a/RenodeTlibWorkflowDocumentation.md
+++ /dev/null
@@ -1,114 +0,0 @@
-# Renode TLib Workflow (Placeholder)
-
-Commands here are subject to change.
-
-* [Building](#building)
-* [Running Qemu without debugging](#running-qemu-without-debugging)
-* [Running Qemu with debugging](#running-qemu-with-debugging)
-* [Running gdb for Qemu](#running-gdb-for-qemu)
- * [Run gdb on the target elf](#run-gdb-on-the-target-elf)
-* [Running gdb for Renode](#running-gdb-for-renode)
- * [Setup .gdbinit file](#setup-.gdbinit-file)
-* [Running Renode](#running-renode)
-
-## Building
-
-```
-m springbok
-m qemu_clean qemu
-m renode_clean renode
-```
-
-Note: as we continually make changes to renode, will have to `m renode_clean renode` to apply updates:
-
-`m renode_clean renode`
-
-
-## Running Qemu without debugging
-
-```
-qemu_sim_springbok ./out/springbok/test_vsetvl/test_vsetvl.elf
-```
-
-## Running Qemu with debugging
-
-```
-qemu_sim_springbok ./out/springbok/test_vsetvl/test_vsetvl.elf -s -S
-```
-
-## Running gdb for Qemu
-
-### Run gdb on the target elf
-
-Note, same as for Renode but with `target remote :1234`
-
-```sh
-riscv32-unknown-elf-gdb out/springbok/test_vsetvl/test_vsetvl.elf \
- -ex "target remote :1234" \
- -ex "layout split" \
- -ex "b main" \
- -ex "c"
-```
-## Running gdb for Renode
-
-```sh
-riscv32-unknown-elf-gdb out/springbok/test_vsetvl/test_vsetvl.elf \
- -ex "target remote :3333" \
- -ex "monitor start" \
- -ex "sysbus.cpu2 IsHalted False" \
- -ex "layout split" \
- -ex "b main" \
- -ex "c"
-```
-### Setup .gdbinit file
-
-Save the following to `${HOME}/.gdbinit`:
-
-```
-set auto-load safe-path /
-handle SIGXCPU SIG33 SIG35 SIG36 SIG37 SIG38 SIGPWR nostop noprint
-
-define mono_backtrace
- select-frame 0
- set $i = 0
- while ($i < $arg0)
- set $foo = (char*) mono_pmip ($pc)
- if ($foo)
- printf "#%d %p in %s\n", $i, $pc, $foo
- else
- frame
- end
- up-silently
- set $i = $i + 1
- end
-end
-
-define mono_stack
- set $mono_thread = mono_thread_current ()
- if ($mono_thread == 0x00)
- printf "No mono thread associated with this thread\n"
- else
- set $ucp = malloc (sizeof (ucontext_t))
- call (void) getcontext ($ucp)
- call (void) mono_print_thread_dump ($ucp)
- call (void) free ($ucp)
- end
-end
-```
-
-
-## Running Renode
-
-```sh
-gdb -ex "set breakpoint pending on" \
- -ex "set pagination off" \
- -ex "b helper_vsetvl" \
- -ex "layout split" \
- -ex "r" \
- --args mono \
- --debug out/host/renode/Renode.exe \
- -e "\$bin=@out/springbok/test_vsetvl/test_vsetvl.elf; i @sim/config/springbok.resc;" \
- --disable-xwt \
- --console
-```
-
diff --git a/RiscVVectorSpecDoc.md b/RiscVVectorSpecDoc.md
deleted file mode 100644
index a7485b5..0000000
--- a/RiscVVectorSpecDoc.md
+++ /dev/null
@@ -1,6 +0,0 @@
-# RISC-V Vector Extension Specifications
-
-* Specification Doc: [v1.0 PDF Frozen for Public Review](https://storage.googleapis.com/shodan-public-artifacts/RVV-Specification-Docs/riscv-v-spec-1.0-frozen-for-public-review.pdf)
-* Specification Doc: [v1.0-rc2 PDF](https://storage.googleapis.com/shodan-public-artifacts/RVV-Specification-Docs/riscv-v-spec-1.0-rc2.pdf)
-* Specification Doc: [v1.0-rc1 PDF](https://github.com/riscv/riscv-v-spec/releases/download/v1.0-rc1/riscv-v-spec-1.0-rc1.pdf)
-* [Source](https://github.com/riscv/riscv-v-spec)
diff --git a/RunningInstructionSetSimulation.md b/RunningInstructionSetSimulation.md
deleted file mode 100644
index c787fe4..0000000
--- a/RunningInstructionSetSimulation.md
+++ /dev/null
@@ -1,50 +0,0 @@
-# Full System Instruction Set Simulation
-
-And instruction set simulation (ISS) is a high-level simulation
-intended to capture the behavior of the full system.
-It is useful for testing software and ideas before
-running a complete cycle-accurate simulator which
-can have low host performance and before actual hardware is
-available for testing. Since it can exist before hardware
-is implemented in an RTL it also allows hardware/software
-co-development, taking what can be a serial process into
-a parallel workflow.
-
-# Shodan ISS Environment
-
-Shodan ISS is developed in Renode. Renode provides the ability to
-simulate a full system including custom peripherals and a heterogenous
-core configuration as is present in the Shodan SoC design.
-
-# Simulating the Secure Core
-
-Before beginning a simulation make sure to setup your workstation environment
-as described in the Getting Started document.
-
-The scripts set up an alias to launch renode:
-
-```
-renode
-```
-
-This will launch the renode console.
-To launch a simulation of the shodan secure core run the following
-command in the Renode console:
-
-```
-i @sim/config/shodan_secure.resc
-```
-
-Execute the simualtion with that following command:
-
-```
-start
-```
-
-
-It is possible to debug the running program with the following command at the console:
-
-```
-riscv64-unknown-elf-gdb --command=sim/config/gdbinit out/opentitan/build-bin/sw/device/boot_rom/boot_rom_sim_verilator.elf
-```
-
diff --git a/TraceGeneration.md b/TraceGeneration.md
deleted file mode 100644
index c5d9f46..0000000
--- a/TraceGeneration.md
+++ /dev/null
@@ -1,172 +0,0 @@
-# Trace Generation
-
-Methods available in the Shodan repo for generating traces from Spike,
-and Renode.
-
-[TOC]
-
-## Trace Generation with Wrapper Script
-
-The `test_runner.py` script currently supports both trace generation in both **Spike** and **Renode**.
-
-### Spike trace generation with `test_runner.py`
-
-1. cd to the root shodan directory and run:
-
-```sh
-source build/setup.sh
-```
-
-2. (optionally) run `m springbok` to create potential elf targets
-
-3. Run trace with the `test_runner.py` script and save trace to file:
-
-```sh
-TEST_RUNNER="${ROOTDIR}/sw/vec/scripts/test_runner.py"
-ELF_FILE="${ROOTDIR}/out/springbok/rvv/softrvv/tests/softrvv_vxor_test.elf"
-SPIKE_PATH="${ROOTDIR}/out/host/spike/bin/spike"
-OUTPUT_FILE="spike_trace_output.txt"
-
-"${TEST_RUNNER}" "spike" \
- "${ELF_FILE}" \
- "--spike-path" "${SPIKE_PATH}" \
- "--timeout=30" \
- "--trace-output" "${OUTPUT_FILE}"
-```
-
-### Renode trace generation with `test_runner.py`
-
-```sh
-TEST_RUNNER="${ROOTDIR}/sw/vec/scripts/test_runner.py"
-ELF_FILE="${ROOTDIR}/out/springbok/rvv/softrvv/tests/softrvv_vxor_test.elf"
-RENODE_PATH="${ROOTDIR}/out/host/renode/renode"
-OUTPUT_FILE="renode_trace_output.txt"
-
-"${TEST_RUNNER}" "renode" \
- "${ELF_FILE}" \
- "--renode-path" "${RENODE_PATH}" \
- "--quick_test" \
- "--timeout=30" \
- "--trace-output" "${OUTPUT_FILE}"
-```
-
-
-## Direct Trace Generation
-
-This section provides examples for setting up trace generation, and
-command line options for **Spike** and **Renode**.
-
-### Direct Spike Trace Generation
-
-#### Quickly Get Spike Trace With Springbok Defaults
-
-To run a direct spike trace with the defaults for springbok, run:
-
-```sh
-ELF_FILE="${ROOTDIR}/out/springbok/rvv/softrvv/tests/softrvv_vxor_test.elf"
-
-spike_sim_springbok "${ELF_FILE}"
-```
-
-Trace file will be saved to /tmp/spike_trace.txt
-
-#### Granular Direct Spike Trace Generation
-
-This section describes flags in depth for more granular trace generation.
-
-The following example shows trace generation for a softrvv vxor test script,
-and how to adjust each of the flag values:
-
-```sh
-ELF_FILE="${ROOTDIR}/out/springbok/rvv/softrvv/tests/softrvv_vxor_test.elf"
-LOG_FILE="spike_trace_output.txt"
-
-"${OUT}/host/spike/bin/spike" \
- -m0x34000000:0x1000000 \
- --pc=0x34000000 \
- --log="${LOG_FILE}" \
- -l \
- "${ELF_FILE}"
-```
-
-Sample output:
-
-```sh
-core 0: 0x00001000 (0x00000297) auipc t0, 0x0
-core 0: 0x00001004 (0x02028593) addi a1, t0, 32
-core 0: 0x00001008 (0xf1402573) csrr a0, mhartid
-core 0: 0x0000100c (0x0182a283) lw t0, 24(t0)
-core 0: 0x00001010 (0x00028067) jr t0
-core 0: >>>> _boot_address
-core 0: 0x32000000 (0x0080006f) j pc + 0x8
-core 0: >>>> _start
-core 0: 0x32000008 (0x02400117) auipc sp, 0x2400
-core 0: 0x3200000c (0xfb810113) addi sp, sp, -72
-```
-
-*Notes on Spike Flags:*
-
-- The elf-file __must__ be the last argument
-- Omitting the `--log` flag but keeping the `-l` flag sends trace to console's stderr instead of to a file.
-- add `-d` to to interactively run the trace
-- add `--log-commits` to add register value changes woven between the trace:
-
-Sample output (recall that `t0` is register `x5`, and `a1` is `x11`):
-
-```sh
-core 0: 0x00001000 (0x00000297) auipc t0, 0x0
-core 0: 3 0x00001000 (0x00000297) x 5 0x00001000
-core 0: 0x00001004 (0x02028593) addi a1, t0, 32
-core 0: 3 0x00001004 (0x02028593) x11 0x00001020
-```
-
-- we use the `-m` flag as `-m<TCM>:<TCM LENGTH>` or more generally from the spike documentation:
-
-```
- -m<a:m,b:n,...> Provide memory regions of size m and n bytes
- at base addresses a and b (with 4 KiB alignment)
-```
-
-## Trace Analysis
-
-### Number of Instructions
-
-These commands assume the TCM starts at 0x34000000, may need to s/0x34/0x80/ for 0x8000000 TCM Starting address.
-
-#### Spike
-
-```sh
-cat spike_trace_output.txt | awk '/_start/,/_finish/' | grep "0: 0x34" | wc -l
-```
-
-#### Renode
-
-```sh
-renode_trace_output.txt | wc -l
-```
-
-### PC for Trace Analysis
-
-SystemC trace output contains the 8 digit PC in hex (without the '0x' prefix).
-
-These commands reformat the raw output trace from Spike and Renode for
-comparison with the SystemC output trace, located at:
-
-```sh
-$ROOTDIR/out/springbok/systemc/sim/simulations/trace.dat
-```
-
-
-#### Spike
-
-```sh
-cat spike_trace.txt | awk '/_start/,/_finish/' | sed 's/.*: 0x\([0-9a-fA-F]\{8\}\).*/\1/g' | egrep "^34" > spike_trace_pc.txt
-```
-
-#### Renode
-
-
-```sh
-cat renode_trace.txt | awk -F":" '{print $1}' | tr "[:upper:]" "[:lower:]" > renode_trace_pc.txt
-```
-
diff --git a/gdbgui.png b/gdbgui.png
deleted file mode 100644
index 3ae8c07..0000000
--- a/gdbgui.png
+++ /dev/null
Binary files differ
