Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Latest Draft Scalar Crypto Specification (v0.9.0)
  • Stable
  • What's next:
    • Needs translation into ASCIIDOC
    • Incorporate results of OpCode consistency review, once available
  • Roadmap:
    • Next version will include any feedback from opcode consistency review, plus any small cleanups and editorial work.
      • aes32* and sm4* encodings will change to remove the `rt` field.
      • Change aes64ks1i "rcon" immediate to "rnum"Exact encodings may be changed for the better.
    • v1.0.0 will be the public review version.

...

  • OpCode and Consistency Review page
  • What's next:  Respond to OpCode and Consistency Review comments, once available, and achieve consensus on any changes.
  • (warning)We need to discuss the aes32* and sm4* rt encodings.
    • Comments from others and Andrew particularly suggest that having distinct rd/rs1/rs2 is acceptable and that we over-estimated the importance of minimising encoding cost.
    • Suggest we consider We will likely be reverting to the original form of these instructions, with separate rd/rs1/rs2 before public review?.

Architecture Tests

  • Test plan for the scalar-crypto specific instructions is available.
  • No actual tests suitable for use currently available. An old experimental set need removing from the riscv-crypto repository, as these no longer work with the latest toolchain or architectural test framework.
  • What's next:
    • Imperas have a complete set of tests, written to the existing test plan, for the scalar crypto instructions and the bitmanip instructions we borrow.
      • There is an open pull request (with some open questions) in the riscv-arch-test repository, with many thanks to Imperas.
      • They form a base we can use to develop prototype implementations / Spike / SAIL / QEMU very easily and quickly.
    • IIT Madras are also looking at writing the scalar crypto tests for integration into the official architectural tests repo as well.
      • Agreed SoW for IITM
      • Likely path is that they They will re-implement the tests as part of the blessed coverage and test generation tooling.
      • We then switch over to using the IIT tests when they are finished, since they will be easier to maintain/extend going forward than the Imperas tests.
    • YAML config changes for K have been merged in. See here.

...