[sw/silicon_creator] Rename mask_rom to rom

Signed-off-by: Alphan Ulusoy <alphan@google.com>

azure-pipelines.yml

@@ -181,14 +181,14 @@ jobs:
   - bash: |
       set -x -e
       . util/build_consts.sh
-      # copy the mask rom to a specific location
-      MASK_ROM_TARGET=${BIN_DIR}/sw/device/silicon_creator/mask_rom
-      mkdir -p ${MASK_ROM_TARGET}
-      MASK_ROM=$(ci/scripts/target-location.sh //sw/device/silicon_creator/mask_rom:mask_rom_fpga_cw310_scr_vmem)
-      cp $MASK_ROM $MASK_ROM_TARGET/mask_rom_fpga_cw310.scr.39.vmem
-      MASK_ROM_DIR=$(dirname $MASK_ROM)
-      cp $MASK_ROM_DIR/mask_rom_fpga_cw310.elf $MASK_ROM_TARGET/mask_rom_fpga_cw310.elf
-      cp $MASK_ROM_DIR/mask_rom_fpga_cw310.bin $MASK_ROM_TARGET/mask_rom_fpga_cw310.bin
+      # copy the rom to a specific location
+      ROM_TARGET=${BIN_DIR}/sw/device/silicon_creator/rom
+      mkdir -p ${ROM_TARGET}
+      ROM=$(ci/scripts/target-location.sh //sw/device/silicon_creator/rom:rom_fpga_cw310_scr_vmem)
+      cp $ROM $ROM_TARGET/rom_fpga_cw310.scr.39.vmem
+      ROM_DIR=$(dirname $ROM)
+      cp $ROM_DIR/rom_fpga_cw310.elf $ROM_TARGET/rom_fpga_cw310.elf
+      cp $ROM_DIR/rom_fpga_cw310.bin $ROM_TARGET/rom_fpga_cw310.bin
   - template: ci/upload-artifacts-template.yml
     parameters:
       includePatterns:
@@ -384,8 +384,8 @@ jobs:
     displayName: Upload artifacts for CW310
     condition: failed()
 
-- job: chip_earlgrey_cw310_splice_mask_rom
-  displayName: Splice Mask ROM into CW310 bitstream
+- job: chip_earlgrey_cw310_splice_rom
+  displayName: Splice ROM into CW310 bitstream
   dependsOn:
     - chip_earlgrey_cw310
     - sw_build
@@ -427,7 +427,7 @@ jobs:
         gcpKeyFile: "gcpkey.json"
         bucketURI: "gs://opentitan-bitstreams/master"
   - publish: "$(Build.ArtifactStagingDirectory)"
-    artifact: chip_earlgrey_cw310-splice-mask-rom-build-out
+    artifact: chip_earlgrey_cw310-splice-rom-build-out
     displayName: Upload artifacts for CW310
     condition: failed()
 
@@ -461,14 +461,14 @@ jobs:
   timeoutInMinutes: 30
   dependsOn:
     - chip_earlgrey_cw310
-    - chip_earlgrey_cw310_splice_mask_rom
+    - chip_earlgrey_cw310_splice_rom
     - sw_build
   steps:
   - template: ci/install-package-dependencies.yml
   - template: ci/download-artifacts-template.yml
     parameters:
       downloadPartialBuildBinFrom:
-        - chip_earlgrey_cw310_splice_mask_rom
+        - chip_earlgrey_cw310_splice_rom
         - sw_build
   - bash: |
       set -e

ci/scripts/run-verilator-tests.sh

@@ -29,4 +29,4 @@ xargs ci/bazelisk.sh test \
     //sw/device/silicon_creator/lib/drivers:alert_functest_sim_verilator \
     //sw/device/silicon_creator/lib/drivers:watchdog_functest_sim_verilator \
     //sw/device/silicon_creator/lib:irq_asm_functest_sim_verilator \
-    //sw/device/silicon_creator/mask_rom:mask_rom_epmp_test_sim_verilator
+    //sw/device/silicon_creator/rom:rom_epmp_test_sim_verilator

doc/getting_started/build_sw.md

@@ -90,12 +90,12 @@ There are two categories of OpenTitan tests Bazel can build and run:
 On-host tests are compiled and run on the host machine, while on-device tests are compiled and run on (simulated/emulated) OpenTitan hardware.
 
 Examples of on-host tests are:
-* unit tests for device software, such as [DIF]({{< relref "/sw/device/lib/dif" >}}) and [mask ROM]({{< relref "/sw/device/silicon_creator/mask_rom/docs/" >}}) unit tests.
+* unit tests for device software, such as [DIF]({{< relref "/sw/device/lib/dif" >}}) and [ROM]({{< relref "/sw/device/silicon_creator/rom/docs/" >}}) unit tests.
 * any test for host software, such as `opentitan{lib,tool}`.
 
 Examples of on-device tests are:
 * [chip-level tests]({{< relref "/sw/device/tests/index.md" >}}).
-* [mask ROM functional tests]({{< relref "/sw/device/silicon_creator/mask_rom/docs/" >}})
+* [ROM functional tests]({{< relref "/sw/device/silicon_creator/rom/docs/" >}})
 
 The remainder of this document will focus on building and running **on-host** tests with Bazel.
 To learn about running **on-device** tests with Bazel, please continue back to the main [Getting Started]({{< relref "getting_started" >}}) instructions, and proceed with the [Verilator]({{< relref "setup_verilator" >}}) and/or [FPGA]({{< relref "setup_fpga" >}}) setup instructions.
@@ -121,12 +121,12 @@ For example, building and testing the UART DIF library's unit tests:
 bazel test //sw/device/lib/dif:uart_unittest
 ```
 
-### Running on-host Mask ROM Tests
+### Running on-host ROM Tests
 
-Similar to the DIF libraries, you can query, build, and run all the [mask ROM]({{< relref "/sw/device/silicon_creator/mask_rom/docs/" >}}) unit tests (which also run on the host) with Bazel.
+Similar to the DIF libraries, you can query, build, and run all the [ROM]({{< relref "/sw/device/silicon_creator/rom/docs/" >}}) unit tests (which also run on the host) with Bazel.
 
 #### Querying which (on-host) tests are available
-Note, the mask ROM has both on-host and on-device tests.
+Note, the ROM has both on-host and on-device tests.
 This query filters tests by their kind, i.e., only on-host tests.
 ```console
 bazel query 'kind(cc_.*, tests(//sw/device/silicon_creator/lib/...))'
@@ -138,7 +138,7 @@ bazel test --test_tag_filters=-cw310,-dv,-verilator //sw/device/silicon_creator/
 ```
 
 #### Building and running a **single** (on-host) test
-For example, building and testing the mask ROM UART driver unit tests:
+For example, building and testing the ROM UART driver unit tests:
 ```console
 bazel test //sw/device/silicon_creator/lib/drivers:uart_unittest
 ```

doc/getting_started/setup_fpga.md

@@ -40,28 +40,28 @@ tar -xvf bitstream-latest.tar.gz
 ```
 
 By default, the bitstream is built with a version of the boot ROM used for testing (called the _test ROM_; pulled from `sw/device/lib/testing/test_rom`).
-There is also a version of the boot ROM used in production (called the _mask ROM_; pulled from `sw/device/silicon_creator/mask_rom`).
+There is also a version of the boot ROM used in production (called the _ROM_; pulled from `sw/device/silicon_creator/rom`).
 This can be spliced into the bitstream to overwrite the testing boot ROM as described in the [FPGA Reference Manual]({{< relref "ref_manual_fpga.md#boot-rom-development" >}}).
-However, if you do not want to do the splicing yourself, both versions of the bitstream are available in the download as `*.bit.orig` and `*.bit.splice` (containing the test ROM and the mask ROM respectively).
+However, if you do not want to do the splicing yourself, both versions of the bitstream are available in the download as `*.bit.orig` and `*.bit.splice` (containing the test ROM and the ROM respectively).
 The metadata for the latest bitstream (the approximate creation time and the associated commit hash) is also available as a text file and can be [downloaded separately](https://storage.googleapis.com/opentitan-bitstreams/master/latest/latest.txt).
 
 ### Build an FPGA bitstream
 
 Synthesizing a design for an FPGA board is simple with Bazel.
 While Bazel is the entry point for kicking off the FPGA sythesis, under the hood, it invokes FuseSoC, the hardware package manager / build system supported by OpenTitan.
 During the build process, the boot ROM is baked into the bitstream.
-As mentioned above, we maintain two boot ROM programs, one for testing (_test ROM_), and one for production (_mask ROM_).
+As mentioned above, we maintain two boot ROM programs, one for testing (_test ROM_), and one for production (_ROM_).
 
 To build an FPGA bitstream with the _test ROM_, use:
 ```console
 cd $REPO_TOP
 bazel build //hw/bitstream/vivado:fpga_cw310_test_rom
 ```
 
-To build an FPGA bitstream with the _mask ROM_, use:
+To build an FPGA bitstream with the _ROM_, use:
 ```console
 cd $REPO_TOP
-bazel build //hw/bitstream/vivado:fpga_cw310_mask_rom
+bazel build //hw/bitstream/vivado:fpga_cw310_rom
 ```
 
 #### Dealing with FPGA Congestion Issues

doc/rm/ref_manual_fpga.md

@@ -23,7 +23,7 @@ Then, you can flash the new bitstream onto the FPGA with `opentitantool`.
 There are two ways to splice content into a bitstream.
 
 1. Define a Bazel target (or use an existing one).
-For example, see the `//hw/bitstream:mask_rom` target defined in [hw/bitstream/BUILD](https://github.com/lowRISC/opentitan/blob/master/hw/bitstream/BUILD).
+For example, see the `//hw/bitstream:rom` target defined in [hw/bitstream/BUILD](https://github.com/lowRISC/opentitan/blob/master/hw/bitstream/BUILD).
 
 2. Use the [`splice_rom.sh`](https://github.com/lowRISC/opentitan/blob/master/util/fpga/splice_rom.sh) script.
 
@@ -103,7 +103,7 @@ Specifically, this job runs `ci/scripts/build-bitstream-vivado.sh` and produces
 * `rom.mmi`
 * `otp.mmi`
 
-The `chip_earlgrey_cw310_splice_mask_rom` job receives those files and splices the Mask ROM into the bitstream.
+The `chip_earlgrey_cw310_splice_rom` job receives those files and splices the ROM into the bitstream.
 
 If CI is working on the `master` branch, it puts selected build artifacts into a tarball, which it then uploads to the GCS bucket. The latest tarball is available here: https://storage.googleapis.com/opentitan-bitstreams/master/bitstream-latest.tar.gz
 

doc/security/specs/_index.md

@@ -27,9 +27,9 @@ device ownership state. A device that has been personalized with a unique
 
 ## [Secure Boot][secure_boot]
 
-OpenTitan supports a secure boot implementation anchored in the silicon mask
-ROM. The mask ROM contains a set of public keys used to verify the first boot
-stage stored in flash.  
+OpenTitan supports a secure boot implementation anchored in the silicon ROM.
+The ROM contains a set of public keys used to verify the first boot stage
+stored in flash.
 
 Each boot stage is in charge of verifying the signature of the next stage and
 locking out portions of the chip that are not required by later stages. Once the

doc/security/specs/attestation/_index.md

@@ -33,7 +33,7 @@ attestation can be verified against the Silicon Owners' PKI of choice.
 
 Boot stages:
 
-*   `ROM`: Metal mask ROM, sometimes known as Boot ROM.
+*   `ROM`: Metal ROM, sometimes known as Boot ROM.
 *   `ROM_EXT`: ROM Extension. Stored in flash and signed by the Silicon Creator.
 *   Owner boot stages. This document uses two stages as an example. The Silicon
     Owner is free to choose other boot configurations.

doc/security/specs/device_provisioning/index.md

@@ -222,7 +222,7 @@ Steps:
 
 ### Secure Boot
 
-Secure boot is always enforced by the mask ROM and cannot be disabled.
+Secure boot is always enforced by the ROM and cannot be disabled.
 Personalization and factory software payloads are signed, and boot verification
 is used to anchor the mechanism in which the device authenticates the
 provisioning appliance during personalization.

doc/security/specs/identities_and_root_keys/_index.md

@@ -25,7 +25,7 @@ DICE compatible identity flow:
 
 Boot stages:
 
-*   `ROM`: Metal mask ROM, sometimes known as Boot ROM.
+*   `ROM`: Metal ROM, sometimes known as Boot ROM.
 *   `ROM_EXT`: ROM Extension. Stored in flash and signed by the Silicon
     Creator[^1].
 *   `BL0`: Bootloader. Signed by the Silicon Owner.
@@ -98,7 +98,7 @@ as an example.
 ## Creator Root Key (`CreatorRootKey`) {#creator-root-key}
 
 The following sequence describes the creation of the `CreatorRootKey`. All
-inputs into the key manager can be locked down during mask ROM execution.
+inputs into the key manager can be locked down during ROM execution.
 
 The size of the inputs is dependent on the security strength and masking
 configuration of the implementation. Depending on the KM\_DERIVE intrinsic

doc/security/specs/ownership_transfer/_index.md

@@ -68,7 +68,7 @@ There are three modes of ownership transfer supported:
 
 Boot stages:
 
-*   `ROM`: Metal mask ROM, sometimes known as Boot ROM.
+*   `ROM`: Metal ROM, sometimes known as Boot ROM.
 *   `ROM_EXT`: ROM Extension. Stored in flash and signed by the Silicon Creator.
 *   Owner boot stages. This document uses two stages as an example. The Silicon
     Owner is free to choose other boot configurations.
@@ -156,7 +156,7 @@ Definitions:
   <tr>
     <td>
     <!--
-    svgs are made in google docs, and can be found here: 
+    svgs are made in google docs, and can be found here:
     https://docs.google.com/drawings/d/1hnC2EgkYpkxhVJ6I0prxdoQbglstqfwxvBYh_JIt8TA/edit?usp=sharing
     -->
       <img src="ownership_transfer_fig1.svg" width="900" alt="fig1">