[DOE] Potential issue, when ENC and DEC are supported

[ludwigatlubis]

We wanted to update on an issue which is not a supported use case but it maybe be enabled in future. As soon as encode and decode mode are activate we think there is an issue within the design. So its a mix of enhancement and bug.

Description

The module produces wrong encrypted and decrypted values when the result_valid signal is asserted after a previous operation with different mode.

Expected Behaviour

What was the expected behaviour?

The module should be able to perform encryption after decryption or decryption after encryption right after each other when the module is back to IDLE.

Received Counterexample

What was the behaviour observed in the counterexample?

The module is initialized with init_cmd with a key to perform key expansion. When the module is IDLE again it received a next_cmd with encdec as low which means a decryption command should take place. When the decyrption is done the module goes back to IDLE and asserts a result_valid. At the same time a new next_cmd is asserted with encdec as high which means an encryption should take place.
Because of that the module's output on the result output has a wrong value when result_valid is asserted. The reason behind that is because the mux that is used is connected to the output of the encryption block due to the encdec being high to perform encryption.
Meaning, when result_valid is high the result has an incorrect value.
Based on a discussion, this behavior shoul

d be allowed and an encryption can happen right after the decryption is done as long as the module is ready. Additionally, this behavior happens when the encryption happens first and then decryption.

Here is the according waveform.
mode_change.fsdb.zip

[mojtaba-bisheh]

I've drafted a back-to-back test with enc/dec mode, and and it has yielded the correct results. you can find it here: https://github.com/chipsalliance/caliptra-rtl/tree/mojtaba-msft-doe

The waveform you provided contains only a single INIT and one NEXT command:

INIT is used to initialized the ley, while NEXT is used to enable the core to perform encryption/decryption. Therefore, in this particular waveform, the design is limited to performing a decryption operation without any back-to-back enc/dec.
Additionally, there is another concern with the waveform: the value of the IV has been altered subsequent to the NEXT command, despite the requirement for it to remain unchanged.

[ayoubatlubis]

Hi @mojtaba-bisheh ,

In the screenshot you provided, the next_cmd is high right at the end of the waveform, please look at the far right of the screenshot.

Additionally, here is a screenshot from the formal tool on the scenario:

As you can see the encdec is set to true at the same cycle the core is ready again, which will gate the result from coming from the decryption block and connect muxed_new_block to enc_new_block.
This will cause the result PO to be connected to the encryption block even though the core just performed a decryption.
I have checked your testbench and you are flipping the mode from decryption to encryption one cycle after the core is ready because of line 343 ((CLK_PERIOD)). However, this case happens only when the mode is flipped right at the same cycle.
About your comment on the IV, the IV PI changes yes, but this doesn’t affect the internal IV registers as you can see in the screenshot.

Regards,
Osama Ayoub