diff --git a/hw/ip/rom_ctrl/doc/interfaces.md b/hw/ip/rom_ctrl/doc/interfaces.md
index 705bf66428a86..99fb1d7b2581a 100644
--- a/hw/ip/rom_ctrl/doc/interfaces.md
+++ b/hw/ip/rom_ctrl/doc/interfaces.md
@@ -60,7 +60,7 @@ The parameters that have an effect on the generated block are:
Parameter | Default (Max) | Top Earlgrey | Description
------------------|-------------------------------|----------------------------------------------------|---------------
`AlertAsyncOn` | True | True | This is passed to the single `prim_alert_sender` instance and causes it to generate synchronization logic to support alert rx and tx being on different clocks.
-`RndCnstRomNonce` | `RND_CNST_SCR_NONCE` (define) | `top_earlgrey_rnd_cnst_pkg::RndCnstRomCtrlScrNonce`| Compile-time random default constant for scrambling nonce (used in `prim_prince` block and the two S&P blocks).
+`RndCnstRomNonce` | `RND_CNST_SCR_NONCE` (define) | `top_earlgrey_rnd_cnst_pkg::RndCnstRomCtrlScrNonce`| Compile-time random default constant for scrambling nonce (used in `prim_prince` block and the S&P block).
`RndCnstRomKey` | `RND_CNST_SCR_KEY` (define) | `top_earlgrey_rnd_cnst_pkg::RndCnstRomCtrlScrKey` | 128-bit compile-time random default constant for scrambling key (used in `prim_prince` block).
`MemSizeRom` | 64kB | 32kB | The size of the ROM itself
diff --git a/hw/ip/rom_ctrl/doc/programmers_guide.md b/hw/ip/rom_ctrl/doc/programmers_guide.md
index c9997799efda5..97cb11a4c9653 100644
--- a/hw/ip/rom_ctrl/doc/programmers_guide.md
+++ b/hw/ip/rom_ctrl/doc/programmers_guide.md
@@ -9,8 +9,8 @@ The [`FATAL_ALERT_CAUSE`](registers.md#fatal_alert_cause) register might change
To get the computed ROM digest, software can read [`DIGEST_0`](registers.md#digest) through [`DIGEST_7`](registers.md#digest).
The ROM also contains an expected ROM digest.
-Unlike the rest of the contents of ROM, this isn't scrambled.
-As such, software can't read it through the standard ROM interface (which would try to unscramble it again, resulting in rubbish data that would cause a failed ECC check).
+Unlike the rest of the contents of ROM, the address of this digest isn't scrambled.
+As such, software can't read it through the standard ROM interface (since the address isn't very predictable).
In case software needs access to this value, it can be read at [`EXP_DIGEST_0`](registers.md#exp_digest) through [`EXP_DIGEST_7`](registers.md#exp_digest).
## Device Interface Functions (DIFs)
diff --git a/hw/ip/rom_ctrl/doc/rom_ctrl_blockdiag.svg b/hw/ip/rom_ctrl/doc/rom_ctrl_blockdiag.svg
index f4069c8d40ec1..f5a4ffc3d00a9 100644
--- a/hw/ip/rom_ctrl/doc/rom_ctrl_blockdiag.svg
+++ b/hw/ip/rom_ctrl/doc/rom_ctrl_blockdiag.svg
@@ -8,7 +8,7 @@
stroke-miterlimit="10"
id="svg2849"
sodipodi:docname="rom_ctrl_blockdiag.svg"
- inkscape:version="1.1.2 (0a00cf5339, 2022-02-04)"
+ inkscape:version="1.2.2 (b0a8486541, 2022-12-01)"
width="1350"
height="779.99994"
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
@@ -985,18 +985,18 @@
xml:space="preserve"
style="font-size:16px;line-height:12px;font-family:'Liberation Sans';-inkscape-font-specification:'Liberation Sans';text-align:center;text-decoration:none;text-decoration-line:none;text-decoration-color:#000000;letter-spacing:0px;word-spacing:0px;text-anchor:middle;fill:#000000;stroke:#000000;stroke-width:0.999999px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;stop-color:#000000"
x="1132.3362"
- y="339.32898"
+ y="343.32898"
id="text1023">scrambledencryptedrdata + ECC
+ id="tspan896">rdata + ECC
rdata + ECC
+ style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-family:'Liberation Mono';-inkscape-font-specification:'Liberation Mono';text-align:end;text-anchor:end">cleartext rdata + ECC
rdata
+ y="360">rdata + ECC
diff --git a/hw/ip/rom_ctrl/doc/theory_of_operation.md b/hw/ip/rom_ctrl/doc/theory_of_operation.md
index e573672bf2b8b..468c056bb69c7 100644
--- a/hw/ip/rom_ctrl/doc/theory_of_operation.md
+++ b/hw/ip/rom_ctrl/doc/theory_of_operation.md
@@ -16,16 +16,16 @@ It runs exactly once, and releases the green multiplexer when it is done.
## ROM access when chip is in operation
Once the chip has booted, ROM accesses are requested over the system TL-UL bus.
-These come in through the TL-UL SRAM adapter (top-left of block diagram).
+These arrive through the TL-UL SRAM adapter (top-left of block diagram).
In normal operation, the green multiplexer will give access to these TL reads.
-The address is scrambled at the first substitution-permutation network (marked S&P in the diagram).
+The address is scrambled by a substitution-permutation network (marked S&P in the diagram).
In parallel with the ROM access, a reduced `prim_prince` primitive (7 rounds with latency 1; equivalent to the cipher used for SRAM) computes a 39-bit truncated keystream for the block.
-On the following cycle, the scrambled data from ROM goes through a substitution-permutation network and is then XOR'd with the keystream.
+On the following cycle, the data returned from ROM is XOR'd with the keystream.
This scheme is the same as that used by the [SRAM controller](../../sram_ctrl/README.md), but is much simplified because the ROM doesn't have to deal with writes, byte accesses or key changes.
-The output from the XOR is the unscrambled 32-bit data, plus seven ECC bits.
-This data is passed straight through the TL-UL SRAM adapter; the ECC bits are used as a signal integrity check by the system bus.
+The output from the XOR has a 32-bit data word plus seven ECC bits.
+This data word is passed straight through the TL-UL SRAM adapter; the ECC bits are used as a signal integrity check by the system bus.
The following diagram shows the timing of the different signals.
The time from the `req` output from the `tlul_adapter_sram` to the response that appears on its `rvalid` input is one cycle.
@@ -40,9 +40,9 @@ The unscrambled ROM data for (logical) address 12 is denoted `d12`.
{name: 'req', wave: '0.1...0...'},
{name: 'addr', wave: 'x.3.4.x...', data: ['12', '34']},
{name: 'scrambled addr', wave: 'x.3.4.x...', data: ['21', '43']},
- {name: 'scrambled rdata + ecc', wave: 'x...3.4.x.', data: ['w21', 'w43']},
+ {name: 'encrypted rdata + ecc', wave: 'x...3.4.x.', data: ['w21', 'w43']},
{name: 'keystream', wave: 'x...3.4.x.', data: ['k12', 'k34']},
- {name: 'rdata + ecc', wave: 'x...3.4.x.', data: ['d12', 'd34']},
+ {name: 'cleartext rdata + ecc', wave: 'x...3.4.x.', data: ['d12', 'd34']},
{name: 'rvalid', wave: '0...1...0.'},
]}
```
@@ -66,7 +66,6 @@ The checker FSM loops through almost all the words in ROM (from bottom to top),
Once the last word has been sent, the FSM releases the multiplexer; this now switches over permanently to allow access through the TL-UL SRAM adapter.
The top eight words in ROM (by logical address) are interpreted as a 256-bit expected hash.
-Unlike the rest of ROM, their data is not stored scrambled, so the expected hash can be read directly.
This is taken by the checker FSM (ignoring ECC bits) and will be compared with the digest that is read back from the KMAC block.
Once it comes back, the digest is forwarded directly to the [Key Manager](../../keymgr/README.md).