Add Sbox in stdlib

[ZenithalHourlyRate]

Contributor Checklist

• [ ] Did you add Scaladoc to every public function/method?
• [x] Did you add at least one test demonstrating the PR?
• [x] Did you delete any extraneous printlns/debugging code?
• [x] Did you specify the type of improvement?
• [x] Did you add appropriate documentation in docs/src?
• [x] Did you state the API impact?
• [x] Did you specify the code generation impact?
• [x] Did you request a desired merge strategy?
• [x] Did you add text to be included in the Release Notes for this change?

Type of Improvement

API Impact

Add new API

Backend Code Generation Impact

No

Desired Merge Strategy

Squash

Release Notes

An efficient SBox implementation for both AES and SM4 is added in stdlib

Other notes

This is suggested by https://github.com/chipsalliance/rocket-chip/pull/2950#discussion_r873330412

This is beneficial for all chisel user who wants to implement SBox for their scalar crypto extension

Reviewer Checklist (only modified by reviewer)

• [ ] Did you add the appropriate labels?
• [ ] Did you mark the proper milestone (Bug fix: 3.4.x, [small] API extension: 3.5.x, API modification or big change: 3.6.0)?
• [ ] Did you review?
• [ ] Did you check whether all relevant Contributor checkboxes have been checked?
• [ ] Did you mark as Please Merge?

[sequencer]

If not using a VIA ROM or other custom designs, this seems to be a state-of-the-art SBox implementation(it can be directly synthesis with a good performance), and its idea can also be reused to other cryptography algorithms. So besides providing a implementation of AES and SM4, I prefer a hardware generator which directly describe the algorithm, and use this algorithm to generate the RTL.

[ZenithalHourlyRate]

If not using a VIA ROM or other custom designs, this seems to be a state-of-the-art SBox implementation

A note on the area: ROM needs 1899 whereas this design takes only 323 for both AESEnc/AESDec. See https://github.com/chipsalliance/rocket-chip/pull/2950#issuecomment-1107651298 for more detail.

[ekiwi]

In order to start a discussion about use cases, since a component in the stdlib should have more than one use case: I happen to have a Chisel port of TinyAES here: https://github.com/ekiwi/paso/blob/main/benchmarks/src/benchmarks/aes/TinyAES128.scala

How could I make use of the S-Box from this PR to simplify my code?

[ZenithalHourlyRate]

How could I make use of the S-Box from this PR to simplify my code?

In class S you can use SBoxAESEncOut(SBoxMid(SBoxAESEncIn(io.in))) instead of VecInit(StaticTables.S.map(_.U(8.W)))(io.in)

Also, you can merge the datapath of S and xS as demoed in https://github.com/OpenRigil/rocket-chip/blob/076d041e02d08cc78500cdea004276f57f1eca87/src/main/scala/rocket/CryptoNIST.scala#L119-L122 and that is why we seperate SBoxMid into a standalone object

[jiegec]

We need document explaining how and where to integrate these modules into custom crypto designs.

[ZenithalHourlyRate]

Also, you can merge the datapath of S and xS

It seems that your impl only has the encryption part so no merge can be done. I think encryption/decryption would both be present most of the time and reusing some datapath is wanted

[ZenithalHourlyRate]

We need document explaining how and where to integrate these modules into custom crypto designs.

Agreed. doc is a TODO.

talking about custom crypto design, I think we could have a package like stdlib.crypto?

A util like "GFMul a UInt with Int" is useful for AES (maybe also for other crypto tools, I've not done a survey on this) and can be upstreamed to chisel3, I think. See https://github.com/OpenRigil/rocket-chip/blob/076d041e02d08cc78500cdea004276f57f1eca87/src/main/scala/rocket/CryptoNIST.scala#L125-L145

Other utils in CryptoNIST.scala is also useful for other AES implementations, though that needs quite a lot discussion.

[ZenithalHourlyRate]

Agreed. doc is a TODO.

Doc added.

[sequencer]

since treadle is removed. I think it’s OK for now. But I just realised that The formal tool will be deprecated with SFC as well…………… I think we can depend on SFC formal backend on test for now until we have the LEC tool in CIRCT.

[ekiwi]

But I just realised that The formal tool will be deprecated with SFC as well

It is not actually going to get deprecated. At least not the full formal verification package that you can access from chiseltest. Only the firrtl compiler itself will be deprecated, but I plan on keeping the formal capabilities of chiseltest alive for as long as possible.