Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[aes, pre-dv] Pre-dv Verilator testbench for AES #11

Merged
merged 1 commit into from
Nov 28, 2024

Conversation

andrea-caforio
Copy link
Collaborator

@andrea-caforio andrea-caforio commented Nov 26, 2024

This commit contains a comprehensive pre-dv testbench for the AES IP block, invoking all the possible modes of operations (+GCM) with different key and inputs sizes. By default, the communication with the IP happens over the TLUL bus, but if a TLUL/shim adapter is configured, messages can be relayed through the shim first.

There are two generic modules tlul_adapter and tlul_delayer that are agnostic to the actual testbench and can be reused in other testbenches that require a robust TLUL handler.

This testbench mimics already existing pre-dv suites for Ascon and KMAC.

I'm opening this PR here instead of upstream due to the GCM dependency

@andrea-caforio andrea-caforio force-pushed the aes-pre-dv-tb branch 3 times, most recently from 26b1dd7 to ca13f34 Compare November 26, 2024 14:32
@andrea-caforio andrea-caforio self-assigned this Nov 26, 2024
@andrea-caforio andrea-caforio marked this pull request as ready for review November 26, 2024 14:51
Copy link
Owner

@vogelpi vogelpi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @andrea-caforio for your PR. I have some comments and questions but it's all minor. This looks nice!


`include "prim_assert.sv"

module tlul_adapter
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not fully happy with the name here but I don't have a better one. Basically this is just the thing to convert the generic TB requests to TLUL. And the other one converts valid-hold protocol requests to TLUL. I wouldn't rename the other one but maybe this one here should just be a tlul_adapter_tb_reqs or aes_tb_reqs_tlul_adapter? I don't really know. What is your view on this?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I changed it to tlul_adapter_tb_reqs. With this name it still reflects the generic nature of the requests which are not necessarily tied to AES.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, this is reaosnable

logic pending_d, pending_q;
logic req_ack, resp_ack;

assign req_ack = tlul_en_i & tl_i.a_ready & tl_o.a_valid;
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The whole logic in here is very similar to the tlul_adapter_shim but that's probably because the TB requests have been designed with the tlul_adapter_shim in mind. I think this is okay and still appreciate having this very simple option available, too.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed, it's lifted from the shim adapter. It's a consequence of having written the shim before the new tlul_adapter_tb_reqs. I didn't want to change the shim RTL, so this new adapter follows the design of the shim even if it introduces some code duplication.

.id_i ( '0 )
);
end else begin : gen_tlul_adapter
tlul_adapter #(
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Question: what happens for the final read_caliptra(CALIPTRA_NAME_0_OFFSET), calls in case the shim is not there?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First, I thought the AES register file would signal an error for a read with an invalid address but it seems to accept it and just return 0 instead. I added a comment about this on the docstring of the read_caliptra function.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the clarification!

@andrea-caforio andrea-caforio force-pushed the aes-pre-dv-tb branch 2 times, most recently from fdbdf19 to 241d89b Compare November 27, 2024 15:02
@andrea-caforio
Copy link
Collaborator Author

Thank you @vogelpi for the review. :-)

Copy link
Owner

@vogelpi vogelpi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @andrea-caforio !

LGTM except for one unresolved comment, there was a misunderstanding regarding the line breaks in MarkDown files. It should be 1 sentence per line.

This commit contains a comprehensive pre-dv testbench for the AES IP
block, invoking all the possible modes of operations (+GCM) with
different key and inputs sizes. By default, the communication with the
IP happens over the TLUL bus, but if a TLUL/shim adapter is
configured, messages can be relayed through the shim first.

There are two generic modules `tlul_adapter` and `tlul_delayer` that
are agnostic to the actual testbench and can be reused in other
testbenches that require a robust TLUL handler.

This testbench mimics already existing pre-dv suites for Ascon and
KMAC.

Signed-off-by: Andrea Caforio <[email protected]>
@vogelpi vogelpi merged commit 97dd83a into vogelpi:aes-gcm-review Nov 28, 2024
8 of 9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants