OTP drops the read request if address = 0x1000 (4096). OTP does not return a read response (SLVERR, OKAY, etc).

[JimmyKHChan]

OTP drops the read request if address = 0x1000 (4096). OTP does not return a read response (SLVERR)

[bharatpillilli]

What's your fuse map? How many regions? How many bytes per region? What's your address structure of the fuse? What is the property of the fuse partition that is sitting at that address?

[JimmyKHChan]

Our AXI address map allocates 64KB (0x0000:0xFFFF) for OTP. We are trying to toggle the invalid addresses within OTP address space.

[bharatpillilli]

what is your real fuse map? Is it from 0x0 to 0xFFF?

[bharatpillilli]

SLVERR is expected Caliptra SS behavior for any addresses that are not implemented for a given module. If your true fuse addressing falls outside of it, then it is a FW bug or your test bug.

Simply stated - you are not allowed to access invalid addresses - additional security hardening to weed out a buggy/compromised FW polling into unimplemented addresses and extract unexpected information.

[JimmyKHChan]

what is your real fuse map? Is it from 0x0 to 0xFFF?

Our fuse map is 0x0000 to 0x4fff

[bharatpillilli]

For AXI addressing, the only valid range is your base address + valid final FC AXI address; As an example, if you access outside of this definition of fuse controller, SLVERR is expected behavior -> https://github.com/chipsalliance/caliptra-ss/blob/3350c70a296bf897abe8c02e5ec0da69cc83ee16/src/integration/rtl/soc_address_map/soc_address_map.h#L10271

In other words, you should NOT go out of this space and I explained the hardening reasons above.

[nimellis]

"SLVERR is expected Caliptra SS behavior for any addresses that are not implemented for a given module"
This is the behavior we are trying to verify, but instead of PLSVERR we are seeing a hang.

Our valid OTP range ends at "base offset + 0x124" for CSR7, the equivalent of which would be 0x700001c0 in your address map.

We then do an access beyond that range at "base offset + 0x1000" with the expectation that we would see a PSLVERR. But instead of PSLVERR the transaction is dropped in OTP and the fabric hangs.

[ekarabu]

Hi,

The fuse controller register addresses are dynamic — they change based on the fuse macro configuration. Our current configuration uses the maximum partition count, which gives the largest possible register address space: 0x0 to 0x1C0.

For addresses from 0x1C4 to 0x1FF, the CSR decode logic returns SLVERR. This is intentional — we deliberately do not tolerate accesses to unimplemented register addresses as a security hardening measure, as Bharat described. Incorrect or compromised firmware must not be able to probe unimplemented address ranges. The fuse controller is not an ordinary logic, it literally controls the security storage of Caliptra.

For addresses beyond 0x1FF, this is an SoC address mapping responsibility. The CaliptraSSIntegrationSpecification document defines the fuse controller address range as 0x0 to 0x1FF (512 bytes). Integrators must configure their AXI fabric to match this documented allocation. Any access outside this range should never reach the fuse controller — the AXI interconnect must reject it.

[nimellis]

@ekarabu "The CaliptraSSIntegrationSpecification document defines the fuse controller address range as 0x0 to 0x1FF (512 bytes). Integrators must configure their AXI fabric to match this documented allocation" I think this is the part we are missing. Do you mind pointing me to where this is specified in the CSS Integration Spec (2.0.2)?

Our fabric allocates more space to the fuse controller, in fact I don't believe I can do a window smaller than 4k in our generator.

Best Regards,
Nicolas

[ekarabu]

Hi @nimellis,

See:

https://github.com/chipsalliance/caliptra-ss/blob/patch_ss_v1p0/docs/CaliptraSSIntegrationSpecification.md#:~:text=64%27-,h7000_0000,-64%27h7000_01FF

[nimellis]

@ekarabu You cut this off in your snippet, but as bolded in the sentence above that table is a "suggested addressmap":

You mentioned "Integrators must configure their AXI fabric to match this documented allocation", so i'm looking for a requirement that states so, not a recommendation.

[nimellis]

In fact one line higher even says "reference only"

[ekarabu]

@nimellis. You're right that the table is labeled as a suggested reference, and allocating a larger window is certainly an option. That said, when the integration deviates from the suggested and documented address range, it's important to verify and ensure that any addresses outside the module's implemented space are properly handled at the integration level.

The subsystem provides IP blocks, and any additional address space introduced by the fabric configuration falls under the integrator's verification scope. In subsystem documentation, the language sometimes is not sharp, on a purpose, in order to provide a flexibility to an integrator. If we use "must", there will be no solution like yours. We want a broader adoption. If an integrator wants to do something that document suggests otherwise, the integrator needs to ensure that the change is functionally supported and does not violate the security rules that the subsystem mandates.