Are we done yet?

[ben-marshall]

Cryptography Extension specific checklist spreadsheets:

• Scalar
• Vector

---

This issue tries to pull together all of the todo items we have left. It is based on the RISC-V Task Group "Definition of Done" (DoD) document, and tries to relate each todo item to steps in that document. There is also a supporting "Extension Lifecycle" document.

The four major milestones in the document are:

1. Kickoff - we passed this years ago.
2. Spec freeze - This is what we are working towards right now.
3. Ratification / Approval Ready.
4. Complete.

Presently, we are getting close to the "Spec freeze" step. The rest of this issue lists remaining tasks, or argues for a waiver from that requirement based on dependencies which we cannot control.

Meta Issues

All of the deliverables listed below require interaction with at-least the following task groups and their working repository:

• riscv-compliance.
• configuration-structure.
• Toolchain / Binutils.
• Spike ISA Simulator.
• QEMU ISA Simulator.
• SAIL ISA Specification (will likely move to /riscv org soon).
• Unprivileged ISA Standing Committee.

How best to coordinate these interactions is an open question. Following the example of Bitmanip, one approach would be to ask the repo owners to create a branch where we can do the development work.

Spec Freeze Requirements

Everything we must get done before the spec can be frozen:

Instruction Encodings.

• See issue Instruction encodings. #16 for specific discussion.

Compliance Tests

The DoD requires that we have these ready before the specification freeze.

• RISC-V Compliance Repository.
• Compliance Tests Documentation

Note: It is assumed that all instructions 'borrowed' from Bitmanip will have their compliance tests written by the Bitmanip TG. Our responsibility will be to define in the compliance tests flow which tests are included in a Crypto extension test set.

• Progress for the Scalar instructions: Compliance Tests: Scalar Instructions #27. Approximately ~30 instruction tests.
• Progress for the Vector instructions: Compliance Tests: Vector Instructions #29. Approximately ~45 instruction tests.

Ideally, the person implementing the specification should not be the same one writing tests for the implementation.

Other tests

These are other relevant tests which we should support / have a framework to easily run using the SAIL/Spike/QEMU models.

• NIST test vectors for AES.
  • Scalar RV32
  • Scalar RV64
  • Vector Single Round.
  • Vector All Round.
• NIST test vectors for SHA2.
  • Scalar RV32
  • Scalar RV64
  • Vector Single Round.
  • Vector All Round.

Models

The DoD requires that the SAIL formal model must be completed for an extension in time for the spec freeze. Additionally, either the Spike or QEMU models must be augmented with the proposed extensions.

SAIL Formal Model

The Scalar instructions are all written, baring any code review. See issue #20 for specific discussion. Handling pollentropy is still an open question.

The Vector instruction definitions are still WIP. This includes in-lining the relevant SAIL code into the draft specification.

• Vector AES: Vector AES Mock SAIL code. #24
• Vector SHA2: Vector SHA2 Mock SAIL code. #23
• Vector CLMUL: Vector CLMUL Mock SAIL Code #32
• Vector Rotate: Vector Rotate Mock SAIL Code #33
• Vector GREV: Vector GREV Mock SAIL Code #31

Misc points for the SAIL Formal Model:.

• It is assumed that all instructions borrowed from Bitmanip will be implemented by the Bitmanip TG. It will be our responsibility to augment their work to ensure those instructions are valid when Bitmanip or the Crypto extension is enabled for the current hart.
• There are currently no tests for the scalar SAIL formal models. This gap will be filled by the compliance tests.
• All open questions on the SAIL spec are being tracked in issue SAIL questions #22.
• We can commit to complete Scalar instruction definitions in SAIL. We will need a waiver for complete vector instruction support in SAIL, since the base vector extension is not supported yet. We can still show mock SAIL support, which will hopefully be enough for implementers to work with.

Here follows a short discussion of the exact requirements from the DoD document for SAIL:

Verify that model update changes are consistent and interoperable with existing code - everything should continue to work the same as before the update.

The crypto extension is almost completely orthogonal to the rest of the SAIL model, so risks of breaking changes are low. We will rely on the riscv-compliance tests to verify this.

Verify that the model update changes work with all supported model generators and checkers

Model generators presumably means "does it build" followed by "does it still work". The main model generators are all enumerated in the SAIL repository, including: C-simulator, OCAML-Simulator, SMT, Coq, Isabele. Again, we are reliant on the riscv-compliance tests for this.

Verify that the model supports any new code required by extension/change including discovery as appropriate

This involves making sure we can identify which parts of the Crypto specification are implemented, but we are dependent on other TGs (tech-config?) for this. New code will be implementations of AES/SHA/GCM etc using our instructions.

Spike and QEMU

While momentum seems to be behind adopting QEMU, we have a complete Spike model for the Scalar instructions, and there is draft support for the vector extension which could be built on.

We should pick either Spike or QEMU to develop going forwards to be pragmatic about the workload.

• Pick Spike or QEMU.
• Scalar instruction implementation.
• Vector instruction implementation.

Software support requirements

Software Support Requirements: develop and verify software changes needed for both:

• Support: os handlers, context switch save restore for registers, etc.
• utilization: tool chain, os, hypervisor, boot loader, app infrastructure, apps, etc.

As a TG, we can identify these changes very easily (Support in crypto libraries, OS patches etc) but are not necessarily equipped to implement them.

• List of Crypto Libs/Apps which will benefit from patches to support the extension.
• List of OS patches.

Ratification Requirements

These are tasks which can be completed in the "post freeze" period, once the spec has stabilized.

Proof of Concept

The DoD document gives considerable freedom in this, and it boils down to showing empirically the effects of implementing the extension on an existing core.

• For the Scalar instructions, this should be fairly easy. All of the Scalar instructions have example RTL. Bitmanip instructions we borrow have example RTL in the Bitmanip repository.
• For the Vector instructions, we (currently) lack a base vector extension to build on.
  • A reasonable compromise would be to implement the "core" of the instructions only, and assume that operand delivery and result handling is the boundary of our demonstration RTL.

[ben-marshall]

A spreadsheet for tracking everything, to be used as a template for each TG, can be found here

[ben-marshall]

Cryptography Extension specific checklist spreadsheets:

• Scalar
• Vector

[ben-marshall]

Closing since this issue hasn't been updated in forever.