[quote user="Matthijs van Duin"]When I have a bit more time I will post some further explanation on the various config parameters, and how to operate the quality-monitoring/alarm mechanism of the RNG.[/quote]
As promised, a bit more info:
The RNG apparently consists of 24 free-running oscillators (FROs) as primary source of entropy (randomness). When the RNG is active, their output is sampled and mixed into an entropy pool. When enough entropy has been collected, 64 bits are extracted to an output register and the ready-flag (bit 0 of status register) is set. Since this "consumes" 64 bits of entropy of the pool, sampling continues for a while to refill it after which the RNG shuts down to conserve power:
Image may be NSFW.
Clik here to view.
Now when software needs random bits, it reads the output register and then clears the ready-flag. Since the entropy pool is still full, the RNG immediately outputs 64 bits and sets the ready-flag again. If software immediately reads these too and desires even more bits, it will now have to wait until the RNG has refilled its entropy pool and is ready to output again. Example showing 4 consecutive reads (256 bits total):
Image may be NSFW.
Clik here to view.
These timings are determined by four parameters which need to be configured before enabling the RNG:
- the sample clock divider: number of cycles (of the module clock) per sample
- the number of startup samples, to initially fill the entropy pool
- the minimum number of refill samples to provide the next output
- the maximum number of refill samples before shutting down to conserve power
As shown in my register map, the startup and max-refill parameters are 16-bit fields in units of 256 samples, while the min-refill parameter is an 8-bit field in units of 64 samples. The value zero in all cases encodes the maximum possible: 224 samples for startup and max-refill, and max-refill for min-refill.
The sample clock divider (range 1-16, encoded as 0-15) is used in case the module clock is higher than useful for sampling the FROs. The keystone security accelerator user guide offers some guidance on this:
"This field must be set to a value such that the slowest FRO (even under worst-case conditions) has a cycle time less than twice the sample period."
The usefulness of this advice is limited by the fact they don't mention any way to determine the cycle times of the FROs, which is probably silicon-dependent. It is however possible to view the raw samples of a single FRO by the following procedure:
- set the max-refill to zero or some large value to make sure the RNG doesn't shut down during the test
- set min-refill to 1 (64 samples)
- set only a single bit of the "FROs enabled" register to select the FRO you wish to inspect
- set bits 1, 2, and 10 of the control register to enable the RNG in test-mode with feedback disabled.
- read a batch of values from the RNG
This gives me this kind of output:
1011010101011010101101010101101010110101011010101010101001010101
1010101101010101010101101010101010110101010101111010101010010101
1010101101010100101010010101011010100101010010101101010110101001
1101010110101101010010101101010010100101011011001100011100011100
0001110011100011100011100111000111000111001110011100011000111000
0011100011100011100011110001111000011110000111110000111100001111
1110000011111000011111000001111100000111110000011110000111000011
0011110001111000111100011110001111000011110001111000011110001111
1111000011110000011111000001111110000001111110000111100011110001
0001110001111000111000011100011100011110001110001110001110001100
1100110011001100110011100110011001100111001100110001100110011100
0111001100111001100111001100100110110010010010011011011011011011
1001001101101101101100100100110110110110010011011011011001001101
1100100110011011001100110110011001100100110010011011011011011011
0010010010010010010010110100101001010110101001010110101011010100
This is on a dm814x whose security subsystem is clocked at a high rate (200 MHz), and the output above shows this is clearly too high as sampling rate since the FRO period is 10 samples at its slowest while at its fastest it seems about 1-2 samples (the short string of consecutive ones on the second line shows that it briefly approaches 1 sample period). Setting the sample divider to 6 indeed yields output without any obvious long-range oscillatory patterns.
To be continued...