[doc] Prefer relative links in Markdown Relative links make it easier to relocate files, prefer using them where possible. Signed-off-by: Philipp Wagner <phw@lowrisc.org>
diff --git a/hw/ip/aes/doc/dv/index.md b/hw/ip/aes/doc/dv/index.md index f9a1a29..f5f168c 100644 --- a/hw/ip/aes/doc/dv/index.md +++ b/hw/ip/aes/doc/dv/index.md
@@ -15,7 +15,7 @@ * [Simulation results](https://reports.opentitan.org/hw/ip/aes/dv/latest/results.html) ## Design features -For detailed information on AES design features, please see the [AES HWIP Technical Specification]({{< relref "hw/ip/aes/doc" >}}). +For detailed information on AES design features, please see the [AES HWIP Technical Specification]({{< relref ".." >}}). ## Testbench architecture AES testbench has been constructed based on the [CIP testbench architecture]({{< relref "hw/dv/sv/cip_lib/doc" >}}).
diff --git a/hw/ip/alert_handler/doc/dv/index.md b/hw/ip/alert_handler/doc/dv/index.md index 4911b42..1af097c 100644 --- a/hw/ip/alert_handler/doc/dv/index.md +++ b/hw/ip/alert_handler/doc/dv/index.md
@@ -17,7 +17,7 @@ * [Simulation results](https://reports.opentitan.org/hw/ip/alert_handler/dv/latest/results.html) ## Design features -For detailed information on ALERT_HANDLER design features, please see the [ALERT_HANDLER HWIP technical specification]({{< relref "hw/ip/alert_handler/doc" >}}). +For detailed information on ALERT_HANDLER design features, please see the [ALERT_HANDLER HWIP technical specification]({{< relref ".." >}}). ## Testbench architecture ALERT_HANDLER testbench has been constructed based on the [CIP testbench architecture]({{< relref "hw/dv/sv/cip_lib/doc" >}}).
diff --git a/hw/ip/aon_timer/doc/dv/index.md b/hw/ip/aon_timer/doc/dv/index.md index aa9d20b..b759cd9 100644 --- a/hw/ip/aon_timer/doc/dv/index.md +++ b/hw/ip/aon_timer/doc/dv/index.md
@@ -15,7 +15,7 @@ * [Simulation results](https://reports.opentitan.org/hw/ip/aon_timer/dv/latest/results.html) ## Design features -For detailed information on AON_TIMER design features, please see the [AON_TIMER HWIP technical specification]({{< relref "hw/ip/aon_timer/doc" >}}). +For detailed information on AON_TIMER design features, please see the [AON_TIMER HWIP technical specification]({{< relref ".." >}}). ## Testbench architecture AON_TIMER testbench has been constructed based on the [CIP testbench architecture]({{< relref "hw/dv/sv/cip_lib/doc" >}}).
diff --git a/hw/ip/csrng/doc/dv/index.md b/hw/ip/csrng/doc/dv/index.md index e1455ce..7bc79ef 100644 --- a/hw/ip/csrng/doc/dv/index.md +++ b/hw/ip/csrng/doc/dv/index.md
@@ -15,7 +15,7 @@ * [Simulation results](https://reports.opentitan.org/hw/ip/csrng/dv/latest/results.html) ## Design features -For detailed information on CSRNG design features, please see the [CSRNG HWIP technical specification]({{< relref "hw/ip/csrng/doc" >}}). +For detailed information on CSRNG design features, please see the [CSRNG HWIP technical specification]({{< relref ".." >}}). ## Testbench architecture CSRNG testbench has been constructed based on the [CIP testbench architecture]({{< relref "hw/dv/sv/cip_lib/doc" >}}).
diff --git a/hw/ip/edn/doc/dv/index.md b/hw/ip/edn/doc/dv/index.md index b22625f..dc07c2d 100644 --- a/hw/ip/edn/doc/dv/index.md +++ b/hw/ip/edn/doc/dv/index.md
@@ -15,7 +15,7 @@ * [Simulation results](https://reports.opentitan.org/hw/ip/edn/dv/latest/results.html) ## Design features -For detailed information on EDN design features, please see the [EDN HWIP technical specification]({{< relref "hw/ip/edn/doc" >}}). +For detailed information on EDN design features, please see the [EDN HWIP technical specification]({{< relref ".." >}}). ## Testbench architecture EDN testbench has been constructed based on the [CIP testbench architecture]({{< relref "hw/dv/sv/cip_lib/doc" >}}).
diff --git a/hw/ip/entropy_src/doc/dv/index.md b/hw/ip/entropy_src/doc/dv/index.md index 84a6c82..66a5725 100644 --- a/hw/ip/entropy_src/doc/dv/index.md +++ b/hw/ip/entropy_src/doc/dv/index.md
@@ -15,7 +15,7 @@ * [Simulation results](https://reports.opentitan.org/hw/ip/entropy_src/dv/latest/results.html) ## Design features -For detailed information on ENTROPY_SRC design features, please see the [ENTROPY_SRC HWIP technical specification]({{< relref "hw/ip/entropy_src/doc" >}}). +For detailed information on ENTROPY_SRC design features, please see the [ENTROPY_SRC HWIP technical specification]({{< relref ".." >}}). ## Testbench architecture ENTROPY_SRC testbench has been constructed based on the [CIP testbench architecture]({{< relref "hw/dv/sv/cip_lib/doc" >}}).
diff --git a/hw/ip/flash_ctrl/doc/dv/index.md b/hw/ip/flash_ctrl/doc/dv/index.md index cf654ef..28cf412 100644 --- a/hw/ip/flash_ctrl/doc/dv/index.md +++ b/hw/ip/flash_ctrl/doc/dv/index.md
@@ -15,7 +15,7 @@ * [Simulation results](https://reports.opentitan.org/hw/ip/flash_ctrl/dv/latest/results.html) ## Design features -For detailed information on `flash_ctrl` design features, please see the [`flash_ctrl` HWIP technical specification]({{< relref "hw/ip/flash_ctrl/doc" >}}). +For detailed information on `flash_ctrl` design features, please see the [`flash_ctrl` HWIP technical specification]({{< relref ".." >}}). The design-under-test (DUT) wraps the `flash_ctrl` IP, `flash_phy` and the TLUL SRAM adapter that converts the incoming TL accesses from the from host (CPU) interface into flash requests. These modules are instantiated and connected to each other and to the rest of the design at the top level. For the IP level DV, we replicate the instantiations and connections in `flash_ctrl_wrapper` module mainained in DV, located at `hw/ip/flash_ctrl/dv/tb/flash_ctrl_wrapper.sv`.
diff --git a/hw/ip/gpio/doc/checklist.md b/hw/ip/gpio/doc/checklist.md index e156ba8..9a28ec4 100644 --- a/hw/ip/gpio/doc/checklist.md +++ b/hw/ip/gpio/doc/checklist.md
@@ -137,7 +137,7 @@ Review | [STD_TEST_CATEGORIES_PLANNED][] | Done | Exception (Security, Power, Debug) Review | [V2_CHECKLIST_SCOPED][] | Done | -[gpio_dv_doc]: {{<relref "/dv/index.md">}} +[gpio_dv_doc]: {{<relref "dv/index.md">}} [DV_DOC_DRAFT_COMPLETED]: {{<relref "/doc/project/checklist.md#dv_doc_draft_completed" >}} [DV_PLAN_COMPLETED]: {{<relref "/doc/project/checklist.md#dv_plan_completed" >}}
diff --git a/hw/ip/gpio/doc/dv/index.md b/hw/ip/gpio/doc/dv/index.md index 17f6f40..9c9c2cc 100644 --- a/hw/ip/gpio/doc/dv/index.md +++ b/hw/ip/gpio/doc/dv/index.md
@@ -15,7 +15,7 @@ * [Simulation results](https://reports.opentitan.org/hw/ip/gpio/dv/latest/results.html) ## Design features -For detailed information on GPIO design features, please see the [GPIO design specification]({{< relref "hw/ip/gpio/doc" >}}). +For detailed information on GPIO design features, please see the [GPIO design specification]({{< relref ".." >}}). ## Testbench architecture GPIO testbench has been constructed based on the [CIP testbench architecture]({{< relref "hw/dv/sv/cip_lib/doc" >}}).
diff --git a/hw/ip/hmac/doc/checklist.md b/hw/ip/hmac/doc/checklist.md index 8614bb8..f0e6e2f 100644 --- a/hw/ip/hmac/doc/checklist.md +++ b/hw/ip/hmac/doc/checklist.md
@@ -21,7 +21,7 @@ RTL | [ASSERT_KNOWN_ADDED][] | Done | Code Quality | [LINT_SETUP][] | Done | -[HMAC Spec]: {{<relref "/.">}} +[HMAC Spec]: {{<relref ".">}} [SPEC_COMPLETE]: {{<relref "/doc/project/checklist.md#spec_complete" >}} [CSR_DEFINED]: {{<relref "/doc/project/checklist.md#csr_defined" >}}
diff --git a/hw/ip/hmac/doc/dv/index.md b/hw/ip/hmac/doc/dv/index.md index 356bc28..7cd8505 100644 --- a/hw/ip/hmac/doc/dv/index.md +++ b/hw/ip/hmac/doc/dv/index.md
@@ -16,7 +16,7 @@ ## Design features For detailed information on HMAC design features, please see the -[HMAC design specification]({{< relref "hw/ip/hmac/doc" >}}). +[HMAC design specification]({{< relref ".." >}}). ## Testbench architecture HMAC testbench has been constructed based on the
diff --git a/hw/ip/i2c/doc/dv/index.md b/hw/ip/i2c/doc/dv/index.md index d9fde5f..fb073c4 100644 --- a/hw/ip/i2c/doc/dv/index.md +++ b/hw/ip/i2c/doc/dv/index.md
@@ -16,7 +16,7 @@ ## Design features For detailed information on I2C design features, please see the -[I2C design specification]({{< relref "hw/ip/i2c/doc" >}}). +[I2C design specification]({{< relref ".." >}}). ## Testbench architecture I2C testbench has been constructed based on the
diff --git a/hw/ip/kmac/doc/dv/index.md b/hw/ip/kmac/doc/dv/index.md index 27c30cc..1cf432f 100644 --- a/hw/ip/kmac/doc/dv/index.md +++ b/hw/ip/kmac/doc/dv/index.md
@@ -15,7 +15,7 @@ * [Simulation results](https://reports.opentitan.org/hw/ip/kmac/dv/latest/results.html) ## Design features -For detailed information on KMAC design features, please see the [KMAC HWIP technical specification]({{< relref "hw/ip/kmac/doc" >}}). +For detailed information on KMAC design features, please see the [KMAC HWIP technical specification]({{< relref ".." >}}). ## Testbench architecture KMAC testbench has been constructed based on the [CIP testbench architecture]({{< relref "hw/dv/sv/cip_lib/doc" >}}).
diff --git a/hw/ip/lc_ctrl/doc/_index.md b/hw/ip/lc_ctrl/doc/_index.md index e6ca181..c8e03ba 100644 --- a/hw/ip/lc_ctrl/doc/_index.md +++ b/hw/ip/lc_ctrl/doc/_index.md
@@ -153,7 +153,7 @@ The individual signals summarized in the table below are described in the following subsections. -{{< snippet "hw/ip/lc_ctrl/doc/lc_ctrl_function_signals_table.md" >}} +{{< snippet "lc_ctrl_function_signals_table.md" >}} Signals marked with an asterisk (Y\*) are only asserted under certain conditions as explained in detail below. @@ -228,7 +228,7 @@ The individual signals summarized in the table below are described in the following subsections. -{{< snippet "hw/ip/lc_ctrl/doc/lc_ctrl_access_signals_table.md" >}} +{{< snippet "lc_ctrl_access_signals_table.md" >}} Signals marked with an asterisk (Y\*) are only asserted under certain conditions as explained in detail below. @@ -263,7 +263,7 @@ Most collateral also contain associated metadata to indicate when the collateral is restricted from further software access, see [accessibility summary]({{< relref "#otp-accessibility-summary-and-impact-of-provision_en" >}}) for more details. Since not all collateral is consumed by the life cycle controller, the consuming agent is also shown. -{{< snippet "hw/ip/lc_ctrl/doc/lc_ctrl_otp_collateral.md" >}} +{{< snippet "lc_ctrl_otp_collateral.md" >}} The TOKENs and KEYS are considered secret data and are stored in [wrapped format]({{< relref "#conditional-transitions">}}). Before use, the secrets are unwrapped. @@ -309,7 +309,7 @@ The table below summarizes the software accessibility of all life cycle collateral. -{{< snippet "hw/ip/lc_ctrl/doc/lc_ctrl_otp_accessibility.md" >}} +{{< snippet "lc_ctrl_otp_accessibility.md" >}} Note that CREATOR_SEED_SW_RW_EN is set to OFF if SECRET2_DIGEST has a nonzero value in PROD, PROD_END and DEV states. SEED_HW_RD_EN only becomes active if SECRET2_DIGEST has a nonzero value in DEV, PROD, PROD_END and RMA states. @@ -321,11 +321,11 @@ They are enumerated in the table below. Just as with OTP, the consumer and usage of each is also described. -{{< snippet "hw/ip/lc_ctrl/doc/lc_ctrl_flash_collateral.md" >}} +{{< snippet "lc_ctrl_flash_collateral.md" >}} Each collateral belongs to a separate flash partition, the table below enumerates the partition and whether the partition is memory mapped. -{{< snippet "hw/ip/lc_ctrl/doc/lc_ctrl_flash_partitions.md" >}} +{{< snippet "lc_ctrl_flash_partitions.md" >}} The general flash partition refers to any software managed storage in flash, and is not a specific carve out in the non-memory mapped area. @@ -338,7 +338,7 @@ The CREATOR_DATA partitions however, are further qualified based on the personalization state of the device. Just as with OTP, the table below enumerates accessibility of flash collateral. -{{< snippet "hw/ip/lc_ctrl/doc/lc_ctrl_flash_accessibility.md" >}} +{{< snippet "lc_ctrl_flash_accessibility.md" >}} Note that CREATOR_SEED_SW_RW_EN is set to OFF if SECRET2_DIGEST has a nonzero value in PROD, PROD_END and DEV states. SEED_HW_RD_EN only becomes active if SECRET2_DIGEST has a nonzero value in DEV, PROD, PROD_END and RMA states. @@ -490,7 +490,7 @@ The encoding of the life-cycle state is used both for OTP storage and as part of the FSM state in the life cycle controller. In other words the state stored within OTP is not re-encoded before it is consumed as part of the life cycle controller FSM state. -{{< snippet "hw/ip/lc_ctrl/doc/lc_ctrl_encoding_table.md" >}} +{{< snippet "lc_ctrl_encoding_table.md" >}} Any decoding that does not fall into the table above is considered **INVALID**. @@ -524,7 +524,7 @@ The life cycle transition counter has 16 strokes where each stroke maps to one 16bit OTP word. The strokes are similarly encoded as the life cycle state in the sense that upon the first transition attempt, all words are initialized with unique Cx values that can later be overwritten with unique Dx values without producing an ECC error. -{{< snippet "hw/ip/lc_ctrl/doc/lc_ctrl_counter_table.md" >}} +{{< snippet "lc_ctrl_counter_table.md" >}} Upon each life cycle transition attempt, the life cycle controller **FIRST** increments the transition counter before initiating any token hashing and comparison operations.
diff --git a/hw/ip/lc_ctrl/doc/dv/index.md b/hw/ip/lc_ctrl/doc/dv/index.md index df85f25..95cf2ef 100644 --- a/hw/ip/lc_ctrl/doc/dv/index.md +++ b/hw/ip/lc_ctrl/doc/dv/index.md
@@ -15,7 +15,7 @@ * [Simulation results](https://reports.opentitan.org/hw/ip/lc_ctrl/dv/latest/results.html) ## Design features -For detailed information on LC_CTRL design features, please see the [LC_CTRL HWIP technical specification]({{< relref "hw/ip/lc_ctrl/doc" >}}). +For detailed information on LC_CTRL design features, please see the [LC_CTRL HWIP technical specification]({{< relref ".." >}}). ## Testbench architecture LC_CTRL testbench has been constructed based on the [CIP testbench architecture]({{< relref "hw/dv/sv/cip_lib/doc" >}}).
diff --git a/hw/ip/otbn/doc/_index.md b/hw/ip/otbn/doc/_index.md index 5a1085c..6a8e37a 100644 --- a/hw/ip/otbn/doc/_index.md +++ b/hw/ip/otbn/doc/_index.md
@@ -48,7 +48,7 @@ # Instruction Set OTBN is a processor with a custom instruction set. -The full ISA description can be found in our [ISA manual]({{< relref "hw/ip/otbn/doc/isa" >}}). +The full ISA description can be found in our [ISA manual]({{< relref "isa" >}}). The instruction set is split into two groups: * The **base instruction subset** operates on the 32b General Purpose Registers (GPRs). @@ -94,7 +94,7 @@ OTBN has an in-built call stack which is accessed through the `x1` GPR. This is intended to be used as a return address stack, containing return addresses for the current stack of function calls. -See the documentation for [`JAL`]({{< relref "hw/ip/otbn/doc/isa#jal" >}}) and [`JALR`]({{< relref "hw/ip/otbn/doc/isa#jalr" >}}) for a description of how to use it for this purpose. +See the documentation for [`JAL`]({{< relref "isa#jal" >}}) and [`JALR`]({{< relref "isa#jalr" >}}) for a description of how to use it for this purpose. The call stack has a maximum depth of 8 elements. Each instruction that reads from `x1` pops a single element from the stack. @@ -291,7 +291,7 @@ OTBN has 256b Wide Special purpose Registers (WSRs). These are analogous to the 32b CSRs, but are used by big number instructions. -They can be accessed with the [`BN.WSRRS`]({{< relref "hw/ip/otbn/doc/isa#bnwsrrs" >}}) and [`BN.WSRRW`]({{< relref "hw/ip/otbn/doc/isa#bnwsrrw" >}}) instructions. +They can be accessed with the [`BN.WSRRS`]({{< relref "isa#bnwsrrs" >}}) and [`BN.WSRRW`]({{< relref "isa#bnwsrrw" >}}) instructions. <table> <thead> @@ -309,7 +309,7 @@ <td>RW</td> <td> -The modulus used by the [`BN.ADDM`]({{< relref "hw/ip/otbn/doc/isa#bnaddm" >}}) and [`BN.SUBM`]({{< relref "hw/ip/otbn/doc/isa#bnsubm" >}}) instructions. +The modulus used by the [`BN.ADDM`]({{< relref "isa#bnaddm" >}}) and [`BN.SUBM`]({{< relref "isa#bnsubm" >}}) instructions. This WSR is also visible as CSRs `MOD0` through to `MOD7`. </td> @@ -356,7 +356,7 @@ ### Loop Stack -OTBN has two instructions for hardware-assisted loops: [`LOOP`]({{< relref "hw/ip/otbn/doc/isa#loop" >}}) and [`LOOPI`]({{< relref "hw/ip/otbn/doc/isa#loopi" >}}). +OTBN has two instructions for hardware-assisted loops: [`LOOP`]({{< relref "isa#loop" >}}) and [`LOOPI`]({{< relref "isa#loopi" >}}). Both use the same state for tracking control flow. This is a stack of tuples containing a loop count, start address and end address. The stack has a maximum depth of eight and the top of the stack is the current loop. @@ -468,7 +468,7 @@ Whenever OTBN observes an error, it will generate an alert. This gets sent to the alert manager. -The alert will either be fatal or recoverable, depending on the class of error: see [Alerts]({{< relref "hw/ip/otbn/doc#alerts" >}}) and {{< regref "ERR_BITS" >}} below for details. +The alert will either be fatal or recoverable, depending on the class of error: see [Alerts]({{< relref "#alerts" >}}) and {{< regref "ERR_BITS" >}} below for details. If OTBN was running when the alert occurred (this is true whenever {{< regref "STATUS.busy" >}} is high), it will also: - Immediately stop fetching and executing instructions. @@ -480,7 +480,7 @@ In this case, the {{< regref "ERR_BITS" >}} register will not change. This avoids race conditions with the host processor's error handling software. However, every error that OTBN detects when it isn't running causes a fatal alert. -This means that the cause will be reflected in {{< regref "FATAL_ALERT_CAUSE" >}}, as described below in [Alerts]({{< relref "hw/ip/otbn/doc#alerts" >}}). +This means that the cause will be reflected in {{< regref "FATAL_ALERT_CAUSE" >}}, as described below in [Alerts]({{< relref "#alerts" >}}). This way, no alert is generated without setting an error code somewhere. <div class="bd-callout bd-callout-warning"> @@ -556,7 +556,7 @@ # Writing OTBN applications {#writing-otbn-applications} OTBN applications are (small) pieces of software written in OTBN assembly. -The full instruction set is described in the [ISA manual]({{< relref "hw/ip/otbn/doc/isa" >}}), and example software is available in the `sw/otbn` directory of the OpenTitan source tree. +The full instruction set is described in the [ISA manual]({{< relref "isa" >}}), and example software is available in the `sw/otbn` directory of the OpenTitan source tree. A hands-on user guide to develop OTBN software can be found in the section [Writing and building software for OTBN]({{<relref "doc/ug/otbn_sw.md" >}}). @@ -580,7 +580,7 @@ ## Returning from an application -The software running on OTBN signals completion by executing the [`ECALL`]({{< relref "hw/ip/otbn/doc/isa#ecall" >}}) instruction. +The software running on OTBN signals completion by executing the [`ECALL`]({{< relref "isa#ecall" >}}) instruction. When it executes this instruction, OTBN: - Stops fetching and executing instructions.
diff --git a/hw/ip/otbn/doc/dv/index.md b/hw/ip/otbn/doc/dv/index.md index 2e15455..d1b7159 100644 --- a/hw/ip/otbn/doc/dv/index.md +++ b/hw/ip/otbn/doc/dv/index.md
@@ -18,7 +18,7 @@ ## Design features OTBN, the OpenTitan Big Number accelerator, is a cryptographic accelerator. -For detailed information on OTBN design features, see the [OTBN HWIP technical specification]({{< relref "hw/ip/otbn/doc" >}}). +For detailed information on OTBN design features, see the [OTBN HWIP technical specification]({{< relref ".." >}}). ## Testbench architecture
diff --git a/hw/ip/otbn/doc/isa.md b/hw/ip/otbn/doc/isa.md index 9d18d1d..0c267e2 100644 --- a/hw/ip/otbn/doc/isa.md +++ b/hw/ip/otbn/doc/isa.md
@@ -3,7 +3,7 @@ --- This document describes the instruction set for OTBN. -For more details about the processor itself, see the [OTBN Technical Specification]({{< relref "hw/ip/otbn/doc" >}}). +For more details about the processor itself, see the [OTBN Technical Specification]({{< relref "." >}}). In particular, this document assumes knowledge of the *Processor State* section from that guide. The instruction set is split into *base* and *big number* subsets.
diff --git a/hw/ip/otp_ctrl/doc/_index.md b/hw/ip/otp_ctrl/doc/_index.md index d839b89..e3bc67f 100644 --- a/hw/ip/otp_ctrl/doc/_index.md +++ b/hw/ip/otp_ctrl/doc/_index.md
@@ -105,7 +105,7 @@ The OTP controller for OpenTitan contains the seven logical partitions shown below. -{{< snippet "hw/ip/otp_ctrl/doc/otp_ctrl_partitions.md" >}} +{{< snippet "otp_ctrl_partitions.md" >}} Generally speaking, the production life cycle of a device is split into 5 stages "Manufacturing" -> "Calibration and Testing" -> "Provisioning" -> "Mission" -> "RMA". OTP values are usually programmed during "Calibration and Testing", "Provisioning" and "RMA" stages, as explained below. @@ -927,14 +927,14 @@ Sizes below are specified in multiples of 32bit words. -{{< snippet "hw/ip/otp_ctrl/doc/otp_ctrl_mmap.md" >}} +{{< snippet "otp_ctrl_mmap.md" >}} Note that since the content in the SECRET* partitions are scrambled using a 64bit PRESENT cipher, read and write access through the DAI needs to occur at a 64bit granularity. Also, all digests (no matter whether they are SW or HW digests) have an access granule of 64bit. The table below lists digests locations, and the corresponding locked partitions. -{{< snippet "hw/ip/otp_ctrl/doc/otp_ctrl_digests.md" >}} +{{< snippet "otp_ctrl_digests.md" >}} Write access to the affected partition will be locked if the digest has a nonzero value.
diff --git a/hw/ip/otp_ctrl/doc/dv/index.md b/hw/ip/otp_ctrl/doc/dv/index.md index 0d215d7..5ac7d99 100644 --- a/hw/ip/otp_ctrl/doc/dv/index.md +++ b/hw/ip/otp_ctrl/doc/dv/index.md
@@ -15,7 +15,7 @@ * [Simulation results](https://reports.opentitan.org/hw/ip/otp_ctrl/dv/latest/results.html) ## Design features -For detailed information on OTP_CTRL design features, please see the [OTP_CTRL HWIP technical specification]({{< relref "hw/ip/otp_ctrl/doc" >}}). +For detailed information on OTP_CTRL design features, please see the [OTP_CTRL HWIP technical specification]({{< relref ".." >}}). ## Testbench architecture OTP_CTRL testbench has been constructed based on the [CIP testbench architecture]({{< relref "hw/dv/sv/cip_lib/doc" >}}).
diff --git a/hw/ip/pattgen/doc/dv/index.md b/hw/ip/pattgen/doc/dv/index.md index 851198e..f3c1544 100644 --- a/hw/ip/pattgen/doc/dv/index.md +++ b/hw/ip/pattgen/doc/dv/index.md
@@ -16,7 +16,7 @@ ## Design features For detailed information on PATTGEN design features, please see the -[PATTGEN design specification]({{< relref "hw/ip/pattgen/doc" >}}). +[PATTGEN design specification]({{< relref ".." >}}). ## Testbench architecture PATTGEN testbench has been constructed based on the
diff --git a/hw/ip/pinmux/doc/dv/index.md b/hw/ip/pinmux/doc/dv/index.md index 37b8dc4..07ba240 100644 --- a/hw/ip/pinmux/doc/dv/index.md +++ b/hw/ip/pinmux/doc/dv/index.md
@@ -17,7 +17,7 @@ ## Design features For detailed information on PINMUX design features, please see the -[PINMUX design specification]({{< relref "hw/ip/pinmux/doc" >}}). +[PINMUX design specification]({{< relref ".." >}}). ## Testbench architecture PINMUX FPV testbench has been constructed based on the [formal architecture]({{< relref "hw/formal/README.md" >}}).
diff --git a/hw/ip/pinmux/doc/padctrl.md b/hw/ip/pinmux/doc/padctrl.md index 21a1c9a..71b3f27 100644 --- a/hw/ip/pinmux/doc/padctrl.md +++ b/hw/ip/pinmux/doc/padctrl.md
@@ -40,7 +40,7 @@ The chip level `padctrl` module provides two sets of parametric IO arrays prefixed with `mio*` and `dio*`. Both sets are functionally equivalent, but are meant to be used with either multiplexed or dedicated IOs as the naming suggests. -I.e., the `mio*` pads can be connected to the `pinmux` module ([see spec]({{< relref "hw/ip/pinmux/doc" >}})) in order to provide as much IO flexibility as possible to the software running on the device. +I.e., the `mio*` pads can be connected to the `pinmux` module ([see spec]({{< relref "." >}})) in order to provide as much IO flexibility as possible to the software running on the device. The `dio*` pads on the other hand are to be connected to peripherals that require dedicated ownership of the pads. Examples that fall into the latter category are a high-speed SPI peripherals or a UART device that should always be connected for debugging purposes.
diff --git a/hw/ip/rv_timer/doc/dv/index.md b/hw/ip/rv_timer/doc/dv/index.md index c98ca82..2bffe41 100644 --- a/hw/ip/rv_timer/doc/dv/index.md +++ b/hw/ip/rv_timer/doc/dv/index.md
@@ -15,7 +15,7 @@ * [Simulation results](https://reports.opentitan.org/hw/ip/rv_timer/dv/latest/results.html) ## Design features -For detailed information on RV_TIMER design features, please see the [RV_TIMER design specification]({{< relref "hw/ip/rv_timer/doc" >}}). +For detailed information on RV_TIMER design features, please see the [RV_TIMER design specification]({{< relref ".." >}}). ## Testbench architecture RV_TIMER testbench has been constructed based on the [CIP testbench architecture]({{< relref "hw/dv/sv/cip_lib/doc" >}}).
diff --git a/hw/ip/spi_device/doc/dv/index.md b/hw/ip/spi_device/doc/dv/index.md index 5c1a690..3f4e5d9 100644 --- a/hw/ip/spi_device/doc/dv/index.md +++ b/hw/ip/spi_device/doc/dv/index.md
@@ -16,7 +16,7 @@ * [Simulation results](https://reports.opentitan.org/hw/ip/spi_device/dv/latest/results.html) ## Design features -For detailed information on SPI Device design features, please see the [SPI_device design specification]({{< relref "hw/ip/spi_device/doc" >}}). +For detailed information on SPI Device design features, please see the [SPI_device design specification]({{< relref ".." >}}). ## Testbench architecture SPI Device testbench has been constructed based on the
diff --git a/hw/ip/sram_ctrl/doc/dv/index.md b/hw/ip/sram_ctrl/doc/dv/index.md index bf208c6..13757f8 100644 --- a/hw/ip/sram_ctrl/doc/dv/index.md +++ b/hw/ip/sram_ctrl/doc/dv/index.md
@@ -15,7 +15,7 @@ * [Simulation results](https://reports.opentitan.org/hw/ip/sram_ctrl/dv/latest/results.html) ## Design features -For detailed information on SRAM_CTRL design features, please see the [SRAM_CTRL HWIP technical specification]({{< relref "hw/ip/sram_ctrl/doc" >}}). +For detailed information on SRAM_CTRL design features, please see the [SRAM_CTRL HWIP technical specification]({{< relref ".." >}}). ## Testbench architecture SRAM_CTRL testbench has been constructed based on the [CIP testbench architecture]({{< relref "hw/dv/sv/cip_lib/doc" >}}).
diff --git a/hw/ip/tlul/doc/dv/index.md b/hw/ip/tlul/doc/dv/index.md index bb0cab3..94da5fb 100644 --- a/hw/ip/tlul/doc/dv/index.md +++ b/hw/ip/tlul/doc/dv/index.md
@@ -16,7 +16,7 @@ * DV regression results dashboard (link TBD) ## Design features -For detailed information on TLUL design features, please see the [TLUL design specification]({{< relref "hw/ip/tlul/doc" >}}). +For detailed information on TLUL design features, please see the [TLUL design specification]({{< relref ".." >}}). ## Testbench architecture XBAR testbench has been constructed based on the `hw/dv/sv/dv_lib`
diff --git a/hw/ip/uart/doc/dv/index.md b/hw/ip/uart/doc/dv/index.md index c71956d..72f7572 100644 --- a/hw/ip/uart/doc/dv/index.md +++ b/hw/ip/uart/doc/dv/index.md
@@ -16,7 +16,7 @@ * [Simulation results](https://reports.opentitan.org/hw/ip/uart/dv/latest/results.html) ## Design features -For detailed information on UART design features, please see the [UART design specification]({{< relref "hw/ip/uart/doc" >}}). +For detailed information on UART design features, please see the [UART design specification]({{< relref ".." >}}). ## Testbench architecture UART testbench has been constructed based on the
diff --git a/hw/ip/usbdev/doc/dv/index.md b/hw/ip/usbdev/doc/dv/index.md index 6db290a..4477ceb 100644 --- a/hw/ip/usbdev/doc/dv/index.md +++ b/hw/ip/usbdev/doc/dv/index.md
@@ -17,7 +17,7 @@ * [Simulation results](https://reports.opentitan.org/hw/ip/usbdev/dv/latest/results.html) ## Design features -For detailed information on USBDEV design features, please see the [USBDEV HWIP technical specification]({{< relref "hw/ip/usbdev/doc" >}}). +For detailed information on USBDEV design features, please see the [USBDEV HWIP technical specification]({{< relref ".." >}}). ## Testbench architecture USBDEV testbench has been constructed based on the [CIP testbench architecture]({{< relref "hw/dv/sv/cip_lib/doc" >}}).