[doc] Fixed links to the getting started section.

Signed-off-by: Hugo McNally <hugo.mcnally@gmail.com>

doc/contributing/bazel_notes.md

@@ -1,7 +1,7 @@
 # Bazel Notes
 
 Both OpenTitan hardware and software is built with Bazel.
-While our [Getting Started](https://opentitan.org/guides/getting_started) guides detail some of the Bazel commands that can be used to build both types of artifacts, below are detailed notes on:
+While our [Getting Started](../../doc/getting_started/README.md) guides detail some of the Bazel commands that can be used to build both types of artifacts, below are detailed notes on:
 * how Bazel is configured for our project, and
 * brief examples of Bazel commands that are useful for:
     * querying,
@@ -24,7 +24,7 @@ The `WORKSPACE` file controls external dependencies such that builds can be made
 Bazel loads specific external dependencies, such as various language toolchains.
 It uses them to build OpenTitan targets (like it does with bazel\_embedded) or to satisfy dependencies (as it does with abseil).
 To produce increasingly stable releases the external dependencies loaded in `WORKSPACE` file attempts to fix a all external `http_archive`s to a specific SHA.
-As we add more dependencies to the workspace, builds and tests will become less sensitive to external updates, and we will vastly simplify the [Getting Started](https://opentitan.org/guides/getting_started) instructions.
+As we add more dependencies to the workspace, builds and tests will become less sensitive to external updates, and we will vastly simplify the [Getting Started](../../doc/getting_started/README.md) instructions.
 
 ## BUILD files
 
@@ -67,11 +67,11 @@ Therefore, it cannot be run with a standalone `bazel ...` invocation.
   ```
   Note: `<device>` will be in {`sim_dv`, `sim_verilator`, `fpga_cw310`}.
 
-See [Building (and Testing) Software](../guides/getting_started/src/build_sw.md#device-artifacts), device software can be built for multiple OpenTitan devices and memories, using OpenTitan-specific Bazel macros.
+See [Building (and Testing) Software](../getting_started/build_sw.md#device-artifacts), device software can be built for multiple OpenTitan devices and memories, using OpenTitan-specific Bazel macros.
 
 ## `opentitan_functest` Artifacts
 
-As described [Building (and Testing) Software](../guides/getting_started/src/build_sw.md#device-artifacts), device software can be built for multiple OpenTitan devices and memories, using OpenTitan-specific Bazel macros.
+As described [Building (and Testing) Software](../getting_started/build_sw.md#device-artifacts), device software can be built for multiple OpenTitan devices and memories, using OpenTitan-specific Bazel macros.
 Since running tests on multiple OpenTitan devices (whether DV or Verilator simulation, or an FPGA) involves building several software images for multiple memories, we provide a Bazel macro for this.
 This macro is called `opentitan_functest`.
 
@@ -99,7 +99,7 @@ This macro is called `opentitan_functest`.
 
 # Building Software
 
-* To build OpenTitan software see [here](../guides/getting_started/src/build_sw.md#building-software-with-bazel), or run
+* To build OpenTitan software see [here](../getting_started/build_sw.md#building-software-with-bazel), or run
   ```console
   bazel build <target>
   ```
@@ -108,7 +108,7 @@ This macro is called `opentitan_functest`.
 
 ## On-Host Tests
 
-* To query-for/run *on-host* software tests see [here](../guides/getting_started/src/build_sw.md#running-tests-with-bazel).
+* To query-for/run *on-host* software tests see [here](../getting_started/build_sw.md#running-tests-with-bazel).
 
 ## On-Device Tests
 
@@ -228,8 +228,8 @@ bazel run //quality:license_check --test_output=streamed
 Note, to run (software) tests on these OpenTitan hardware platforms **does not** require these Bazel commands be invoked before the test commands above.
 Bazel is aware of all dependency relationships, and knows what prerequisites to build to run a test.
 
-- Build FPGA bitstream with (test) ROM, see [here](../guides/getting_started/src/setup_fpga.md#build-an-fpga-bitstream).
-- Build FPGA bitstream with (production) ROM, see [here](../guides/getting_started/src/setup_fpga.md#build-an-fpga-bitstream).
+- Build FPGA bitstream with (test) ROM, see [here](../getting_started/setup_fpga.md#build-an-fpga-bitstream).
+- Build FPGA bitstream with (production) ROM, see [here](../getting_started/setup_fpga.md#build-an-fpga-bitstream).
 - Build Verilator simulation binary:
   ```console
   bazel build //hw:verilator

doc/contributing/dv/methodology/README.md

@@ -63,7 +63,7 @@ The testplan is parsed into a data structure that serves the following purposes:
 *  Annotate the nightly regression results to allow us to track our progress towards executing the testplan and coverage collection
 
 The [testplanner](../../../../util/dvsim/README.md) tool provides some additional information on the Hjson testplan anatomy and some of the features and constructs supported.
-The [build_docs](../../../guides/getting_started/src/build_docs.md) tool works in conjunction with the `testplanner` tool to enable its insertion into the DV document as a table.
+The [build_docs](../../../getting_started/build_docs.md) tool works in conjunction with the `testplanner` tool to enable its insertion into the DV document as a table.
 
 ### DV document
 
@@ -174,7 +174,7 @@ Please see the [Ibex DV documentation](https://ibex-core.readthedocs.io/en/lates
 The chip level DV effort is aimed at ensuring that all of the IPs are integrated correctly into the chip.
 For IPs that are pre-verified sub-modules, we perform [integration testing](#integration-testing).
 These are simple functional tests written in C which are cross-compiled and run natively on the Ibex core.
-The software compilation flow to enable this is explained in further detail in the [Building Software](../../../guides/getting_started/src/build_sw.md) document.
+The software compilation flow to enable this is explained in further detail in the [Building Software](../../../getting_started/build_sw.md) document.
 Further, there is a mechanism for the C test running on the CPU to signal the SystemVerilog testbench the test pass or fail indication based on the observed DUT behavior.
 We also provide an environment knob to 'stub' the CPU and use a TL agent to drive the traffic via the CPU's data channel instead, in cases where more intensive testing is needed.
 <!-- TODO: add link to chip DV document -->
@@ -629,4 +629,4 @@ We use the [OpenTitan GitHub Issue tracker](https://github.com/lowRISC/opentitan
 ## Getting Started with DV
 
 The process for getting started with DV involves many steps, including getting clarity on its purpose, setting up the testbench, documentation, etc.
-These are discussed in the [Getting Started with DV](https://opentitan.org/guides/getting_started/setup_dv.html) document.
+These are discussed in the [Getting Started with DV](../../../../doc/getting_started/setup_dv.md) document.

doc/contributing/fpga/debugging_with_ila.md

@@ -25,11 +25,11 @@ In a nutshell, we will take the following steps:
 ## Requirements
 
 This guide was written for OpenTitan on a [NewAE CW310 board](./get_a_board.md#chipwhisperer-cw310) with a Kintex 7 FPGA on it.
-You further need to have Xilinx Vivado installed; see [Install Vivado](/guides/getting_started/install_vivado) for the currently supported version and installation instructions.
+You further need to have Xilinx Vivado installed; see [Install Vivado](../../getting_started/install_vivado/README.md) for the currently supported version and installation instructions.
 Finally, you need a connection to the JTAG port of the FPGA.
 This guide was written using [Xilinx's Platform Cable USB II](https://www.xilinx.com/products/boards-and-kits/hw-usb-ii-g.html), although the first generation Platform Cable USB or the SmartLynq Data Cable may also work.
 
-[Set up the FPGA board](/guides/getting_started/setup_fpga.html) and connect the JTAG plug of Platform Cable USB II to J18 on the CW310 and its USB plug to your workstation where Vivado is installed.
+[Set up the FPGA board](../../getting_started/setup_fpga.md) and connect the JTAG plug of Platform Cable USB II to J18 on the CW310 and its USB plug to your workstation where Vivado is installed.
 Make sure that the [drivers for Platform Cable USB II are installed](https://support.xilinx.com/s/article/59128?language=en_US) on that workstation.
 
 

doc/contributing/fpga/ref_manual_fpga.md

@@ -2,13 +2,13 @@
 
 This manual provides additional usage details about the FPGA.
 Specifically, it provides instructions on SW development flows and testing procedures.
-Refer to the [FPGA Setup](../../guides/getting_started/src/setup_fpga.md) guide for more information on initial setup.
+Refer to the [FPGA Setup](../../getting_started/setup_fpga.md) guide for more information on initial setup.
 
 ## FPGA SW Development Flow
 
 The FPGA is meant for both boot ROM and general software development.
 The flow for each is different, as the boot ROM is meant to be fairly static while general software can change very frequently.
-However, for both flows, Vivado must be installed, with instructions described [here](../../guides/getting_started/src/install_vivado/README.md).
+However, for both flows, Vivado must be installed, with instructions described [here](../../getting_started/install_vivado/README.md).
 
 ### Boot ROM development
 
@@ -44,7 +44,7 @@ For example, see the `//hw/bitstream:rom` target defined in [hw/bitstream/BUILD]
     $ bazel run //sw/host/opentitantool fpga load-bitstream build/lowrisc_systems_chip_earlgrey_cw310_0.1/synth-vivado/lowrisc_systems_chip_earlgrey_cw310_0.1.bit
     ```
 
-    The script assumes that there is an existing bitfile `build/lowrisc_systems_chip_earlgrey_cw310_0.1/synth-vivado/lowrisc_systems_chip_earlgrey_cw310_0.1.bit` (this is created after following the steps in [FPGA Setup](../../guides/getting_started/src/setup_fpga.md)).
+    The script assumes that there is an existing bitfile `build/lowrisc_systems_chip_earlgrey_cw310_0.1/synth-vivado/lowrisc_systems_chip_earlgrey_cw310_0.1.bit` (this is created after following the steps in [FPGA Setup](../../getting_started/setup_fpga.md)).
 
     The script assumes that there is an existing boot ROM image under `build-bin/sw/device/lib/testing/test_rom` and then creates a new bitfile of the same name at the same location.
     The original input bitfile is moved to `build/lowrisc_systems_chip_earlgrey_cw310_0.1/synth-vivado/lowrisc_systems_chip_earlgrey_cw310_0.1.bit.orig`.

doc/contributing/github_notes.md

@@ -5,7 +5,7 @@ The OpenTitan source tree is maintained on GitHub in a [monolithic repository](h
 These notes are for people who intend to contribute back to OpenTitan (based on
 notes taken by a relatively inexperienced git user). If you don't intend to do
 this you can simply clone the main repository, instructions are in [install
-instructions](../guides/getting_started/src/README.md) and this document can be
+instructions](../getting_started/README.md) and this document can be
 ignored. There is much more to using git; a possible next step is to refer to
 [Resources to learn Git](https://try.github.io/).
 

doc/contributing/hw/methodology.md

@@ -44,7 +44,7 @@ Within the OpenTitan project there are two important tooling components to effic
 
 The first is the [Hugo](https://gohugo.io) tool, which converts an annotated Markdown file into a rendered HTML file (including this document).
 See the linked manual for information about the annotations and how to use it to create enhanced auto-generated additions to standard Markdown files.
-To automate the process a script [build-docs.sh](https://opentitan.org/guides/getting_started/build_docs.html) is provided for generating the documentation.
+To automate the process a script [build-docs.sh](../../getting_started/build_docs.md) is provided for generating the documentation.
 
 The second is the [reggen](../../../util/reggen/README.md) register tool that helps define the methodology and description language for specifying hardware registers.
 These descriptions are used by `build-docs.sh` to ensure that the technical specifications for the IP are accurate and up to date with the hardware being built.
@@ -71,7 +71,7 @@ Running lint is faster than running a simulation.
 
 ### Semantic Linting using Verilator (Open Source)
 
-The Verilator tool is open source, thus enabling all project contributors to conveniently download, install and run the tool locally as described [in the installation instructions](../../guides/getting_started/src/setup_verilator.md), without the need for buying a lint tool license.
+The Verilator tool is open source, thus enabling all project contributors to conveniently download, install and run the tool locally as described [in the installation instructions](../../getting_started/setup_verilator.md), without the need for buying a lint tool license.
 
 For developers of design IP, the recommendation is thus to set up the Verilator lint flow for their IP as described in the [Lint Flow README](../../../hw/lint/README.md).
 Developers should run their code through the Verilator lint tool before creating a design pull request.
@@ -85,7 +85,7 @@ Note that a pull request cannot be merged if it is not lint-clean, since the con
 To complement the Verilator lint explained above, we also leverage the Verible style linter, which captures different aspects of the code and detects style elements that are in violation of our [Verilog Style Guide](https://github.com/lowRISC/style-guides/blob/master/VerilogCodingStyle.md).
 
 The tool is open source and freely available on the [Verible GitHub page](https://github.com/google/verible/).
-Hence, we recommend IP designers install the tool as described [here](../../guides/getting_started/src/README.md#step-6a-install-verible-optional) and in the [Lint Flow README](../../../hw/lint/README.md), and use the flow locally to close the errors and warnings.
+Hence, we recommend IP designers install the tool as described [here](../../getting_started/README.md#step-6a-install-verible-optional) and in the [Lint Flow README](../../../hw/lint/README.md), and use the flow locally to close the errors and warnings.
 
 Developers should run their code through the Verible style lint tool before creating a design pull request.
 Linting errors and warnings can be closed by fixing the code in question (preferred), or waiving the error.
@@ -204,7 +204,7 @@ Note that this formatter is still under development and not entirely production
 However, the tool is mature enough for manual use on individual files (i.e., certain edits may have to be manually amended after using it).
 
 The tool is open source and freely available on the [Verible GitHub page](https://github.com/google/verible/).
-Hence, we encourage IP designers to install the tool as described [here](../../guides/getting_started/src/README.md#step-6a-install-verible-optional), and run their code through the formatter tool before creating a design pull request.
+Hence, we encourage IP designers to install the tool as described [here](../../getting_started/README.md#step-6a-install-verible-optional), and run their code through the formatter tool before creating a design pull request.
 
 The tool can be invoked on specific SystemVerilog files with the following command:
 ```shell
@@ -224,7 +224,7 @@ These are discussed in the [Getting Started Designing Hardware](./design.md) doc
 ## FPGA vs Silicon
 
 One output of the OpenTitan project will be silicon instantiations of hardware functionality described in this open source repository.
-The RTL repository defines design functionality at a level satisfactory to prove the hardware and software functionality in an FPGA (see [user guides](https://opentitan.org/guides/getting_started)).
+The RTL repository defines design functionality at a level satisfactory to prove the hardware and software functionality in an FPGA (see [user guides](../../getting_started/README.md)).
 That level is so-called "tapeout ready".
 Once the project reaches that milestone, the team will work with a vendor or vendors to ensure a trustworthy, industry-quality, fully functional OpenTitan chip is manufactured.
 

doc/introduction.md

@@ -9,7 +9,7 @@ This repository exists to enable collaboration across partners participating in
 
 ## Getting Started
 
-To get started with OpenTitan, see the [Getting Started](https://opentitan.org/guides/getting_started) page.
+To get started with OpenTitan, see the [Getting Started](./getting_started/README.md) page.
 For additional resources when working with OpenTitan, see the [contributor's reference](./contributing/README.md).
 For details on coding styles or how to use our project-specific tooling, see the [reference manuals](../util/README.md).
 Lastly, the [Hardware Dashboard page](../hw/README.md) contains technical documentation on the SoC, the Ibex processor core, and the individual IP blocks.
@@ -32,7 +32,7 @@ For questions about how the project is organized, see the [project](./project_go
 
 ## Development
 
-* [Getting Started](https://opentitan.org/guides/getting_started)
+* [Getting Started](./getting_started/README.md)
 * [Contributor's Reference](./contributing/README.md)
 * [Tool References](../util/README.md)
 * [Style Guides](./contributing/style_guides/README.md)

hw/formal/README.md

@@ -233,7 +233,7 @@ The macro <code>`COVER(name, prop, clk, rst)</code> of [prim_assert.sv](https://
 
 ### Cadence JasperGold
 If you have access to JasperGold from Cadence, you can formally verify your assertions.
-Before running FPV, please make sure the target has been added to one of the [three batch scripts](../../doc/guides/getting_started/src/setup_formal.md#formal-property-verification-fpv).
+Before running FPV, please make sure the target has been added to one of the [three batch scripts](../../doc/getting_started/setup_formal.md#formal-property-verification-fpv).
 
 For example, to run formal property verification (FPV) using JasperGold on the prim module `prim_arbiter_fixed`, type:
 ```

hw/ip/otbn/doc/developing_otbn.md

@@ -18,7 +18,7 @@ through the [GitHub issue tracker](https://github.com/lowRISC/opentitan/issues).
 An assembler, linker and disassembler for OTBN can be found in
 `hw/ip/otbn/util`. These are wrappers around a RISC-V GCC and binutils toolchain
 so one must be available (see the OpenTitan documentation on [obtaining a
-toolchain](https://opentitan.org/guides/getting_started#step-3-install-the-lowrisc-risc-v-toolchain).
+toolchain](../../../../doc/getting_started/README.md#step-3-install-the-lowrisc-risc-v-toolchain).
 For more details about the toolchain, see the [user
 guide](../../../../doc/contributing/sw/otbn_sw.md)).
 

hw/lint/README.md

@@ -13,7 +13,7 @@ The lint flow run scripts and waiver files are available in the GitHub repositor
 However, the _"lowRISC Lint Rules"_ are available as part of the default policies in AscentLint release 2019.A.p3 or newer (as `LRLR-v1.0.policy`).
 This enables designers that have access to this tool to run the lint flow provided locally on their premises.
 
-Our linting flow leverages FuseSoC to resolve dependencies, build file lists and call the linting tools. See [here](https://github.com/olofk/fusesoc) for an introduction to this open source package manager and [here](https://opentitan.org/guides/getting_started) for installation instructions.
+Our linting flow leverages FuseSoC to resolve dependencies, build file lists and call the linting tools. See [here](https://github.com/olofk/fusesoc) for an introduction to this open source package manager and [here](../../doc/getting_started/README.md) for installation instructions.
 
 In order to run lint on a [comportable IP](../../doc/contributing/hw/comportability/README.md) block, the corresponding FuseSoC core file must have a lint target and include (optional) waiver files as shown in the following example taken from the FuseSoC core of the AES comportable IP:
 ```

sw/README.md

@@ -1,7 +1,7 @@
 # Software
 
 This is the landing spot for software documentation within the OpenTitan project.
-More description and information can be found within the [Reference Manual](../util/README.md) and [User Guide](https://opentitan.org/guides/getting_started) areas.
+More description and information can be found within the [Reference Manual](../util/README.md) and [User Guide](../doc/getting_started/README.md) areas.
 
 There are three major parts to the OpenTitan software stack: