Add bit manip extensions to README.md by mrcmry · Pull Request #144 · SpinalHDL/VexiiRiscv

mrcmry · 2026-06-29T18:53:53Z

This fix #140.

I did some test with generating a simple, very minimal MCU setup (no peripherial, nothing) with random zb* and it did generate verilog with a lot of combinations. My code look like this:

  val allIsaList = Seq("m", "d", "zicsr", "zifencei", "zba", "zbb", "zbc", "zbs")
  val rand = new scala.util.Random(345)

  for (_ <- 0 to 100) {
    val isaList = scala.collection.mutable.Set[String]()
    for (isa <- allIsaList) {
      if (rand.nextBoolean())
        isaList += isa
    }

It was successful with xlen=32 and xlen=64.

Note that if I use "f" instead of "d" in the list, it crash when "f" is activated in these kind of cases:

i + Set(f, zbb, zicsr, zbc, zbs)
i + Set(f)
i + Set(f, zba, zbs)
i + Set(f, zbb, zicsr, zbc, zba, zbs)
i + Set(f, zbb, zbc, zbs)
i + Set(f, zifencei, zbc)

with the callstack:

failed with extension i + Set(f, zbb, zicsr)
Exception in thread "main" java.lang.Exception: Can't find the service vexiiriscv.execute.RsUnsignedPlugin
        at spinal.lib.misc.plugin.PluginHost.apply(Host.scala:54)
        at vexiiriscv.execute.fpu.FpuUnpackerPlugin$$anon$1.<init>(FpuUnpackerPlugin.scala:58)
        at vexiiriscv.execute.fpu.FpuUnpackerPlugin.$anonfun$logic$1(FpuUnpackerPlugin.scala:56)
        at spinal.lib.misc.plugin.FiberPlugin$$anon$1.$anonfun$setup$4(Fiber.scala:74)
        at spinal.core.ScopeProperty$ApplyClass.apply(ScopeProperty.scala:144)
        at spinal.lib.misc.plugin.PluginHost.rework(Host.scala:29)
        at spinal.lib.misc.plugin.FiberPlugin$$anon$1.$anonfun$setup$2(Fiber.scala:72)
        at spinal.core.internals.BooleanPimped.generate(Misc.scala:285)
        at spinal.lib.misc.plugin.FiberPlugin$$anon$1.$anonfun$setup$1(Fiber.scala:69)
        at spinal.core.fiber.Fiber.$anonfun$addTask$1(Fiber.scala:74)
        at spinal.core.fiber.package$.$anonfun$hardForkRawHandle$1(package.scala:30)
        at spinal.core.fiber.AsyncThread.$anonfun$jvmThread$1(AsyncThread.scala:60)
        at spinal.core.fiber.EngineContext.$anonfun$newJvmThread$1(AsyncCtrl.scala:39)

inochisa · 2026-09-14T11:33:44Z

@mrcmry, I have read #140, I think instead of claiming that we have good bitmanip extension support, it is better to claiming that it only passed ACT test and may need further improvement.

And I wonder if you can do me a favor by also adding clarification crypto, H and AIA support, I think crypto should has the same state as bitmanip, And H and AIA should be claimed as experimental.

mrcmry · 2026-09-17T19:41:52Z

@inochisa I added AIA, H, crypto. Please check the section about testing, I looked at the PR discussion to write it. Did you test AIA (probably no test suite because it's hardware interrupt stuff, it has to be tested in the field) ?

inochisa · 2026-09-17T22:13:06Z

+- [Bit-manipulation extensions](https://docs.riscv.org/reference/isa/extensions/bitmanip/_attachments/bitmanip.pdf) [Zba][Zbb][Zbc][Zbs]
+- [Cryptography scalar & entropy source instructions](https://docs.riscv.org/reference/isa/extensions/crypto-scalar/_attachments/riscv-crypto-spec-scalar.pdf)
+  [Zbkb][Zbkc][Zbkx][Zbs][Zknd][Zkne][Zknh][Zksed][Zksh]
+- [Hypervisor extension](https://docs.riscv.org/reference/isa/v20260120/priv/hypervisor.html) [H]
+- [Advanced Interrupt Architecture specification](https://docs.riscv.org/reference/aia/_attachments/riscv-interrupts.pdf) (AIA with APLIC and IMSIC controllers)


I suggest all the extension document use https://docs.riscv.org/reference. This should be only up-to-date blob.

If you want to keep this, I think it is fine to use https://docs.riscv.org/reference/isa/ instead of https://docs.riscv.org/reference/isa/v20260120/. I found it will redirect to the latest version

Great point, in fact I found how to find the relevant spec in the html library. And you are right, we can drop the version, there is a redirection to the lastest html version. I will update this.

inochisa · 2026-09-17T22:33:48Z

+- Bit manipulation extensions and cryptography scalar & entropy source instructions
+passed the [RISC-V Architectural Certification Tests](https://github.com/riscv/riscv-arch-test), but may need further improvement
+- The H extension is experimental, and was tested by running linux on the core,
+  executing QEMU with the [KVM-unit-tests](https://www.linux-kvm.org/page/KVM-unit-tests)
+- The AIA is experimental


I am not an expert on expressing this. But I think the can be reduced by using two list, so we can add new things simply.

The following extensions only passed the [RISC-V Architectural Certification Tests](https://github.com/riscv/riscv-arch-test), but may need further improvement - [Zba][Zbb][Zbc][Zbs] - XXXX ... The following extensions are still experimental, it may have some bugs in some edge case: - H - AIA [Smaia][Ssaia]

Or maybe we just add a standalone file with a table to maintain all the extension states?

Unlike code, I do not have a good taste on document, so feel free to drop my advice and do the thing you think it is better

Personally I think we should state facts, and let the people decide based on this. There is not even a single version for the code, and it is targeting advanced users what are knowledgeable enough to build their own opinion on the maturity.

So we should state "this part was tested using this tool suite with these conditions" or "this part passes on the CI this test suite". This way people can build there mind, it's much better that "this is experimental and we are not really sure it work fine (but it boot linux and run doom :)". Also, this allows people to reproduce the tests, and point us to the potential regression. Or they can report new tests (I ran NetBSD with IC + H and doom was 1 fps).

Your idea of using two lists is good, I will change to this.

By the way, how was H tested ? With a real FPGA running linux with QEMU running a hosted linux with the KVM extension, right ? And for AIA ?

Personally I think we should state facts, and let the people decide based on this. There is not even a single version for the code, and it is targeting advanced users what are knowledgeable enough to build their own opinion on the maturity.

Right, it is something necessary for advanced uses. It is a hard time when I check the VexiiRiscv support compatibility at the first time.

So we should state "this part was tested using this tool suite with these conditions" or "this part passes on the CI this test suite". This way people can build there mind, it's much better that "this is experimental and we are not really sure it work fine (but it boot linux and run doom :)". Also, this allows people to reproduce the tests, and point us to the potential regression. Or they can report new tests (I ran NetBSD with IC + H and doom was 1 fps).

In fact, I think the state could be different. For an unprivileged extension, it is almost no problem if it passes the ACT test (If the test has no bug XD). For an privileged extension, the thing is different, as the ACT can not cover all the cases because it is hard. A failed test does not mean the thing is broken. And we may need clarify some implementation detail. (And actually, I have a hard time on this XD).

And for extension support, I hope we can have some guarantee on it. For example, H and AIA may not pass the ACT test, but it can run linux with nothing changed. This could be much better than only clarifying it is experimental.

Your idea of using two lists is good, I will change to this.

Maybe for a long time maintenance, it is better to use something like support matrix?

By the way, how was H tested ? With a real FPGA running linux with QEMU running a hosted linux with the KVM extension, right ? And for AIA ?

It can be tested with Litex, but I do not suggest providing this build arguements directly, as the Litex integration is not completed. At least you need to writing the DTB for IMSIC by yourself.

./litex-boards/litex_boards/targets/alibaba_vu13p.py \ --build --update-repo=no --cpu-type vexiiriscv --cpu-variant debian --cpu-count 4 \ --with-coherent-dma --no-netlist-cache \ --sys-clk-freq 150000000.0 --libc-mode full \ --with-isa g c h sstc \ --with-aplic --imsic-interrupts 256 \ --vexii-args " --guest-external-interrupt-file-number=3 --asid-width=8" \ --l2-bytes=262144 --l2-ways=4 \ --with-pcie --driver --with-ethernet --eth-dynamic-ip \ --io-region-mapping 0xc0000000 0x40000000

For testing, yes, you just need a rootfs that includes Qemu. And setup a KVM guest like other architectures. AIA also uses the same method.

inochisa · 2026-09-17T22:36:42Z

with the callstack:

failed with extension i + Set(f, zbb, zicsr)
Exception in thread "main" java.lang.Exception: Can't find the service vexiiriscv.execute.RsUnsignedPlugin
        at spinal.lib.misc.plugin.PluginHost.apply(Host.scala:54)
        at vexiiriscv.execute.fpu.FpuUnpackerPlugin$$anon$1.<init>(FpuUnpackerPlugin.scala:58)
        at vexiiriscv.execute.fpu.FpuUnpackerPlugin.$anonfun$logic$1(FpuUnpackerPlugin.scala:56)
        at spinal.lib.misc.plugin.FiberPlugin$$anon$1.$anonfun$setup$4(Fiber.scala:74)
        at spinal.core.ScopeProperty$ApplyClass.apply(ScopeProperty.scala:144)
        at spinal.lib.misc.plugin.PluginHost.rework(Host.scala:29)
        at spinal.lib.misc.plugin.FiberPlugin$$anon$1.$anonfun$setup$2(Fiber.scala:72)
        at spinal.core.internals.BooleanPimped.generate(Misc.scala:285)
        at spinal.lib.misc.plugin.FiberPlugin$$anon$1.$anonfun$setup$1(Fiber.scala:69)
        at spinal.core.fiber.Fiber.$anonfun$addTask$1(Fiber.scala:74)
        at spinal.core.fiber.package$.$anonfun$hardForkRawHandle$1(package.scala:30)
        at spinal.core.fiber.AsyncThread.$anonfun$jvmThread$1(AsyncThread.scala:60)
        at spinal.core.fiber.EngineContext.$anonfun$newJvmThread$1(AsyncCtrl.scala:39)

Forgot to mention, this is because the floating point always depends on the RsUnsignedPlugin, which is only selected by M extension. XD

inochisa · 2026-09-17T22:49:51Z

Anyway, I think you did find my forgotten things. I think I can merge this after these minor fixes. Thanks.

Add bit manip extensions to README.md

17b742f

mrcmry mentioned this pull request Aug 2, 2026

Add crypto instruction support #154

Merged

Improve README with crypto, H an AIA there testing status

95e23fe

inochisa requested changes Sep 17, 2026

View reviewed changes

Navigation Menu

Add bit manip extensions to README.md - #144

Add bit manip extensions to README.md#144
mrcmry wants to merge 2 commits into
SpinalHDL:devfrom
mrcmry:add-bitmanip-to-readme

mrcmry commented Jun 29, 2026

Uh oh!

inochisa commented Sep 14, 2026

Uh oh!

mrcmry commented Sep 17, 2026

Uh oh!

inochisa Sep 17, 2026

Uh oh!

mrcmry Sep 21, 2026

Uh oh!

inochisa Sep 17, 2026 •

edited

Loading

Uh oh!

mrcmry Sep 21, 2026

Uh oh!

inochisa Sep 21, 2026 •

edited

Loading

Uh oh!

inochisa commented Sep 17, 2026

Uh oh!

inochisa commented Sep 17, 2026

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

mrcmry commented Jun 29, 2026

Uh oh!

inochisa commented Sep 14, 2026

Uh oh!

mrcmry commented Sep 17, 2026

Uh oh!

inochisa Sep 17, 2026

Choose a reason for hiding this comment

Uh oh!

mrcmry Sep 21, 2026

Choose a reason for hiding this comment

Uh oh!

inochisa Sep 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mrcmry Sep 21, 2026

Choose a reason for hiding this comment

Uh oh!

inochisa Sep 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

inochisa commented Sep 17, 2026

Uh oh!

inochisa commented Sep 17, 2026

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

inochisa Sep 17, 2026 •

edited

Loading

inochisa Sep 21, 2026 •

edited

Loading