Itrng_data rate and entropy Src IP enable problem when using internal TRNG

[Jiyeon915]

Hi , Im jiyeon Song from Samsung Electronics . I have a question during integration to use Caliptra as DPE in current project. The questions are about itrng_valid & itrng_data rate and entropy_src IP operation.

In Caliptra Spec , Physical true random noise source signal descriptions section it is mentioned itrng_valid | input | Valid is asserted high for one cycle when data is valid. The expected valid output rate is about 50KHz.

1. What happens if itrng_data & itrng_valid signals come in later than 50Khz?

2. What happens if itrng_data is not received when entropy source IP is enabled? will the entropy source wait indefinitely for itrng_valid & itrng_data? or they cause interrupt to Caliptra core?

3. When I check the Caliptra ROM code, there is no disable operation after Entropy_Src IP enable at the beginning of the ROM code. If itrng_data must be delivered indefinitely while Entropy_src is enabled, the IP to be used as the physical nosie source of Caliptra must always operate during run time. In general, the use of physical noise generator IP is less than 1% of the product usage cycle. Running the physical noise generator IP indefinitely, such as the currently issued Caliptra FW code implementation, may not guarantee the reliability of the IP itself. In addition, even though Caliptra does not actually need any random value, continuing to drive the physical noise generator IP to deliver itrng_data results in unnecessary power consumption. Therefore, it would be nice to change the Caliptra FW (ROM, FMC, RT) code so that Entropy_src IP and csrng are Enable only when Caliptra needs Random Value to ensure the reliability of physical noise generator IP and prevent unnecessary power consumption.

Thanks jiyeon.

[Jiyeon915]

Hi,  There is an additional explanation for the previous question 3. First of all, for convenience, Physical Random Generator IP will be specified as TRNG H/M(Hard Macro).

In the application of conventional semiconductor chips, TRNG H/M is used less than 1% in the entire chip life cycle. For example, in the current security system of our controller chip, if pesudo random number is required, TRNG H/M is operated only once during the power-on cycle to create a physical random variable, and the corresponding random variable is used as a seed to create pesudo random number several times as needed. In addition, TRNG H/M IP designers design IP to meet reliability assurance levels determined based on conventional applications(operating less than 1% of entire chip life cycle) . 

In conclusion, Caliptra's physical random value requirements require excessive use of TRNG H/M than conventional semiconductor chip applications, which can lead to excessive aging of TRNG H/M IP. Therefore, please consider changing the Caliptra operation by enabling the Entropy_Src IP only when the Random Value is required and requesting the Physical Random Value transmitted from the TRNG H/M IP and disabling it. 

Thanks. Jiyeon

[varuns-nvidia]

I transferred this issue from main spec to RTL module. @bharatpillilli does the HW need continuous entropy?

[bharatpillilli]

@howardtr - any update on this?

[Sakul-Gupta]

Thank you All,

There was another point by Luke, "1. What happens if itrng_data & itrng_valid signals come in later than 50Khz? It will slow down Caliptra boot. I'm not sure if it would slow down later Caliptra operations. We have had some discussion about 50Khz because even that rate is slow enough to significantly delay boot. I believe we settled on something closer to 1MHz being more reasonable.

2. What happens if itrng_data is not received when entropy source IP is enabled? will the entropy source wait indefinitely for itrng_valid & itrng_data? or they cause interrupt to Caliptra core? I tried this out on FPGA and it hung until the test timed out. I can't really comment on the rest, my understanding is the same that Caliptra will never deassert the request. Will need attention from the RTL folks on the GitHub issue."

So, question here is it the case that firmware needs to implement a timeout loop while waiting for itrng_valid & itrng_data. What is the recommended timeout expected for this? Is there reference timeout loop implementation available in Caliptra ROM code / firmware for the same?

Much appreciated, Regards, Sakul