Clarification on how to drive trng data in external and internal trng mode

[ayanavachakraborty]

Hi,
I'm trying to understand the trng flow and mechanism by which the SoC should handle driving the Caliptra Trng data in external as well as internal mode.

In External TRNG mode:
The document mentions the following

Steps that SoC is executing:

1. When the etrng_req goes high I see the reflection on 0th bit of 0x300300ac register as well (data_req).
2. At this moment SoC starts driving the 384bits of trng data to register 0x30030078-0x300300a7.
3. Next SoC sets the data_wr_done which is the 1st bit of 0x300300ac register. Now, this is a 4byte register so SoC drives the value as 0x2. So, SoC is setting the data_wr_done bit high and data_req low.
4. From this point read to the register 0x300300ac returns the value as 0x2 which means the data_wr_done is high and data_req is low but the etrng_req output signal still remains high.
5. Now, the SoC keeps waiting for the ready_for_fw signal to go high. But I don't see that happening instead I see the fatal error going high.

Questions:

1. Is there anything that I'm doing wrong or missing while driving the trng data?
2. Is there any timing requirement, latest within some x amount of time the SoC should start driving the trng data once the etrng goes high in external trng mode?
3. Does SoC need to drive the registers 0x30030070 (CPTRA_TRNG_VALID_PAUSER), 0x30030074 (CPTRA_TRNG_PAUSER_LOCK) and 0x300300a8 (CPTRA_TRNG_CTRL) from SoC as well inn the process?
4. After driving the register 0x300300ac as 0x2 from SoC is it not true that etrng_req output signal will go low?
5. Why is the data_req not reflecting the output port etrng_req after driving the register 0x300300ac as 0x2?
6. Is the trng driving mechanism same for fake rom and the actual rom flow?

In Internal TRNG mode:
Steps that SoC is executing:

1. When the etrng_req goes high from SoC the HW starts driving the trng_data and trng_valid port on every clock.
2. After sometime the Caliptra asserts the ready_for_fw signal but the trng_req still stays asserted and the SoC continues driving the trng_data and trng_valid port.

Questions:

1. Once the etrng_req goes high, total how many bits of data is expected from SoC to be driven via the itrng_data[4:0] and itrng_valid?
2. How can SoC be sure of that Caliptra has received enough amount of entropy data and that it can stop driving trng data port now? Does the trng_req go low once the Caliptra has received enough entropy?
3. If Caliptra design samples trng_data and trng_valid on every clock of the frequency that it is running at then what's the relation of 50Khz? Is it from the time when the Caliptra sets etrng_req output high the SoC has 20us to start driving the trng data?
4. Once SoC satisfies the Caliptra's trng requirement for entropy source can Caliptra set the trng_req signal high again requesting for more entropy source at some later point?
5. Is it true that if SoC is not able to satisfy and qualify the trng health check the ready_for_fw won't be asserted from Caliptra?
6. Is the trng driving mechanism same for fake rom and the actual rom flow?

I will really appreciate if those questions can be addressed asap. Thanks in advance!

[varuns-nvidia]

@howardtr @akash-singh-NV could you take a look?

[bharatpillilli]

seems like Luke is already communicating over email as he validated this flow. He assigned himself as the owner

[jlmahowa-amd]

Through some offline work we found that the ETRNG flow was correct, but the SOC did not service the second ETRNG data request.

ETRNG questions:

1. Is there anything that I'm doing wrong or missing while driving the trng data?
   A: The issue here was that after the first etrng data request was serviced, Caliptra FW requested more data that was not provided.
2. Is there any timing requirement, latest within some x amount of time the SoC should start driving the trng data once the etrng goes high in external trng mode?
   A: Each time that Caliptra FW requests ETRNG data it polls for data_wr_done 250000 times. If the SOC has not written that bit the FW will issue a DRIVER_TRNG_EXT_TIMEOUT error.
3. Does SoC need to drive the registers 0x30030070 (CPTRA_TRNG_VALID_PAUSER), 0x30030074 (CPTRA_TRNG_PAUSER_LOCK) and 0x300300a8 (CPTRA_TRNG_CTRL) from SoC as well inn the process?
   A: It does not need to for the purposes of ETRNG enabling, however SOC should consider setting it to ensure only the correct entity can provide TRNG data.
   CPTRA_TRNG_CTRL is RO for SOC.
4. After driving the register 0x300300ac as 0x2 from SoC is it not true that etrng_req output signal will go low?
   A: When FW sees that SOC wrote data_wr_done, the FW will clear the data_req bit which also clears data_wr_done to get cleared by hw. The data_req bit is RO for SOC so only the data_wr_done gets updated on this SOC write.
5. Why is the data_req not reflecting the output port etrng_req after driving the register 0x300300ac as 0x2?
   A: Offline we found that FW did see data_wr_done get set, and issued a new request that left etrng_req high.
6. Is the trng driving mechanism same for fake rom and the actual rom flow?
   A: Yes, there is no difference.

ITRNG questions:

1. Once the etrng_req goes high, total how many bits of data is expected from SoC to be driven via the itrng_data[4:0] and itrng_valid?
   A: SOC is expected to drive entropy data 4 bits at a time as long as etrng_req is high (which is forever). I am not certain what would happen if the SOC stops providing data after Caliptra boot finishes and is idle.
2. How can SoC be sure of that Caliptra has received enough amount of entropy data and that it can stop driving trng data port now? Does the trng_req go low once the Caliptra has received enough entropy?
   A: Currently etrng_req will never go low again. Itrng_data rate and entropy Src IP enable problem when using internal TRNG #538 questions this behavior.
3. If Caliptra design samples trng_data and trng_valid on every clock of the frequency that it is running at then what's the relation of 50Khz? Is it from the time when the Caliptra sets etrng_req output high the SoC has 20us to start driving the trng data?
   A: Caliptra will sample trng_data when trng_valid is high. trng_valid is expected to be asserted when trng_data is valid. 50MHz is an outdated guideline, and a faster trng_data rate of ~1MHz dramatically improves boot time. On the other end a slower itrng entropy data rate will slow down boot performance but I don't think will have much effect otherwise.
4. Once SoC satisfies the Caliptra's trng requirement for entropy source can Caliptra set the trng_req signal high again requesting for more entropy source at some later point?
   A: Currently trng_req stays high forever after being set.
5. Is it true that if SoC is not able to satisfy and qualify the trng health check the ready_for_fw won't be asserted from Caliptra?
   If entropy data is not provided to the ITRNG, then health checks will not complete and hang the ROM. I have not attempted to see what happens if bad data is provided instead. The health check would fail and it may result in a different error instead of a hang.
6. Is the trng driving mechanism same for fake rom and the actual rom flow?
   Yes, there is no difference.

[ayanavachakraborty]

Hi Luke,
Thanks for the info after driviing the trng data multiple times I do see the ready_for_fw going high now. Appreciate the support.

There were couple of questoins that I had out of curiosity:

1. What's the reason that Caliptra requests for multiple eTRNG request and what is the maximum etrng request that SoC might see Caliptra requesting for, in external TRNG mode? Would like to know the answer to estimate the worst case boot time scenario of Caliptra.
2. What's the purpose of sending continuous noise source to Caliptra once its fully up in internal TRNG mode or atleast what's the expected behavior if the SoC stops driving the trng data once Caliptra is totally up?

I think it might be helpful for the user to know the expected output of this 2 scenario inorder to integrate Caliptra effecient into there system.

Thanks,
Ayanava

[jlmahowa-amd]

1. Caliptra makes multiple eTRNG requests because it has multiple operations that depend on random data.
   CFI takes 3 calls, ECDSA and HMAC KATs, and ECDSA signing operations all use random data. To get to Caliptra RT I think there are around 32 calls for random data. Assuming that the number of times Caliptra FW will ask for eTRNG data is fixed is a mistake.
2. Experimentally it seems like giving iTRNG entropy data very slowly (as an easy way to emulate the noise source stopping) will delay operations that rely on random data. I did not encounter any cases where the CSRNG threw an error.
   If discontinuing providing iTRNG is desired, you should probably make a caliptra-sw feature request for FW to disable it when idle.
   We use the entropy source developed for OpenTitan, documentation here: https://opentitan.org/book/hw/ip/entropy_src/doc/theory_of_operation.html
   "The ENTROPY_SRC block will then start to collect entropy bits indefinitely until disabled."

[atif-hussain-wdc]

Are there any updates on how the Caliptra hardware will handshake to the SOC for the Integrated TRNG vs Physical Noise source?

1. If the etrng_req is used by the SoC to start drive itrng_valid and itrng_data[4:0], when does the SoC stop driving itrng_valid and itrng_data[4:0].

1a) Does SoC stop driving itrng_valid and itrng_data[4:0] after it has given Caliptra a total of 384 bits?

2. It doesn't make sense that "etrng_req never goes low". If it never goes low, that means it can't go hi again for the next noise request. And if it never goes hi a 2nd or 3rd time, then how would SoC know to start providing more noise to Caliptra?