Refactor vector extension configuration.

[wwwwwwOwO]

This PR focuses on the configuration aspect extracted from #982, the features:

• Configuration setup in config file and riscv_extensions.sail, ordered by category and then alphabetically
• Check extension dependencies in riscv_validate_config.sail and riscv_vext_control.sail

Follow-up PRs will address instruction-level support logic.

[wwwwwwOwO]

Thanks for the feedback! I’ve made the changes and updated the riscv_vext_control.sail and README.

[wwwwwwOwO]

0      Zvl*
         ↓           
1      Zve32x      F   D
       ↙      ↘
2  Zve32f     Zve64x           Zve32f
      ↘       ↙                   ↓
3      Zve64f      Zfhmin      Zvfhmin
         ↓           ↓
4      Zve64d      Zvfh
         ↓           
5        V
         ↓   
    Other Zv*

I've updated the currentlyEnabled_measure() in riscv_termination.sail, the graph reflects it logic.

[jordancarlin]

The dependencies for the vector bit manipulation and cryptography extensions need to change too:

The Zvknhb and Zvbc Vector Crypto Extensions --and accordingly the composite extensions Zvkn, Zvknc, Zvkng, and Zvksc-- depend on Zve64x.

All of the other Vector Crypto Extensions depend on Zve32x.

Note: If Zve32x is supported then Zvkb or Zvbb provide support for EEW of 8, 16, and 32. If Zve64x is supported then Zvkb or Zvbb also add support for EEW 64.

[wwwwwwOwO]

I’ve updated the currentlyEnabled() checks to reflect the new Zve32x/Zve64x requirements for these extensions.

As for:

Note: If Zve32x is supported then Zvkb or Zvbb provide support for EEW of 8, 16, and 32. If Zve64x is supported then Zvkb or Zvbb also add support for EEW 64.

I’ll handle those SEW constraints in the instruction-level changes.

[wwwwwwOwO]

The dependencies for the vector bit manipulation and cryptography extensions need to change too:

The Zvknhb and Zvbc Vector Crypto Extensions --and accordingly the composite extensions Zvkn, Zvknc, Zvkng, and Zvksc-- depend on Zve64x.
All of the other Vector Crypto Extensions depend on Zve32x.
Note: If Zve32x is supported then Zvkb or Zvbb provide support for EEW of 8, 16, and 32. If Zve64x is supported then Zvkb or Zvbb also add support for EEW 64.

Thanks for pointing that out!
I've corrected the riscv_termination.sail, and accordingly updated the riscv_validate_config.sail and currentlyEnabled() for these extensions.

[jordancarlin]

Thanks for getting these all added! LGTM, but I think we should wait until after the upcoming release before merging to avoid confusion because #1170 probably won’t be ready.

[jordancarlin]

@wwwwwwOwO Now that Zvfh is a distinct config option, the fli.h instruction from the Zfa extension needs to be supported when Zvfh or Zfh are supported. See this recent issue: riscv/riscv-isa-manual#2190.

[wwwwwwOwO]

@wwwwwwOwO Now that Zvfh is a distinct config option, the fli.h instruction from the Zfa extension needs to be supported when Zvfh or Zfh are supported. See this recent issue: riscv/riscv-isa-manual#2190.

Got it! I'll make changes for

mapping clause encdec = FLI_H(constantidx, rd)
  <-> 0b111_1010 @ 0b00001 @ constantidx @ 0b000 @ encdec_freg(rd) @ 0b101_0011
  when currentlyEnabled(Ext_Zfh) & currentlyEnabled(Ext_Zfa)

to

mapping clause encdec = FLI_H(constantidx, rd)
  <-> 0b111_1010 @ 0b00001 @ constantidx @ 0b000 @ encdec_freg(rd) @ 0b101_0011
  when (currentlyEnabled(Ext_Zfh) |  currentlyEnabled(Ext_Zvfh)) & currentlyEnabled(Ext_Zfa)

Because it is instruction-level change, I'll put it in #1170.

[pmundkur]

0      Zvl*
         ↓           
1      Zve32x      F   D
       ↙      ↘
2  Zve32f     Zve64x           Zve32f
      ↘       ↙                   ↓
3      Zve64f      Zfhmin      Zvfhmin
         ↓           ↓
4      Zve64d      Zvfh
         ↓           
5        V
         ↓   
    Other Zv*

I've updated the currentlyEnabled_measure() in riscv_termination.sail, the graph reflects it logic.

It would be good to put this nice diagram in riscv_termination.sail with suitable comments.

[nadime15]

0      Zvl*
         ↓           
1      Zve32x      F   D
       ↙      ↘
2  Zve32f     Zve64x           Zve32f
      ↘       ↙                   ↓
3      Zve64f      Zfhmin      Zvfhmin
         ↓           ↓
4      Zve64d      Zvfh
         ↓           
5        V
         ↓   
    Other Zv*

It probably does not matter here, and as far as I can tell, this only applies to riscv_termination.sail anyway but in theory, the relationship is more nuanced: a given Zvl* does not enable all Zve* extensions (or the other way around, a given Zve* extension does not include all Zvl* extension). For example, Spike derives VLEN from Zvl and ELEN from Zve, so combinations like Zvl32b with Zve64d are invalid.

[wwwwwwOwO]

Sorry, I closed the PR by accident, I'll try to reopen it.

[nadime15]

Maybe it’s just me, but I think we should either let the user enable these extensions by explicitly setting vlen and (!) elen, or we implicitly set vlen and elen when using the Zve* and Zvl* extensions (like Spike does) and remove vlen and elen from the config file. Right now, this approach feels like a mix of both options, and elen doesn’t play a role at all anymore.

For example, if I set elen to 32 but enable Ext_Zve64x, what should elen actually be?

I also think the way currentlyEnabled(Ext_Zve*) is structured needs to change. For instance, enabling Zve64d should automatically enable all the Zve* subset extensions.

(Actually, we don’t need to enable all subset extensions, otherwise, the ISA string becomes unnecessarily long but at the very least, the user should be able to enable Zve64d without having to enable every subset extension manually)

Spike just updated its approach as well. Spike will set elen (and vlen if no Zvl* extension is provided) based on the Zve* extensions. So elen comes from Zve* and vlen from Zvl* or from Zve* (if no Zvl* is provided)

This is probably worth discussing in the Monday meeting @pmundkur

[jordancarlin]

Agreed that this is worth further discussion. I don't think we can remove VLEN as a config option and just use the Zvl* extensions though because that prevents anyone from using a VLEN greater than 1024. I know there are already implementations with VLEN greater than that.

[nadime15]

As far as I can tell, Spike supports Zvl2048b and Zvl4096b, even though they haven’t been ratified yet. We might want to do the same here.

[nadime15]

@wwwwwwOwO We discussed this in the meeting today. The overall conclusion was to remove ELEN from the config and instead set it to match whichever Zve* extension is enabled, basically like Spike, taking the maximum possible ELEN. For example, if Zve64f, Zve64d,Zve64x or V are enabled, set ELEN=64 otherwise for the other extensions, set ELEN=32.

But this will break the vector test case configurations in CI.

See

• https://github.com/riscv/sail-riscv/blob/master/config/CMakeLists.txt
  (I just realized we currently generate config files where XLEN != ELEN, which is not supported.)
• https://github.com/riscv/sail-riscv/blob/master/test/CMakeLists.txt

The good news is vector test cases are only supported when XLEN == ELEN. So, we could just replace ELEN with XLEN, and it should work.

If we decide to remove ELEN, I can patch these files myself, so you wont need to touch them.