enable ecall support in small config

[mateusz-holenko]

This commit enables ecall instruction in small variant enabling it to run Zephyr RTOS.

FPGA utilization verified on tinyfpga_bx.lite target in Litex: 4227 vs. 4273 LC.

Without ecall support:

Info: Device utilisation:
Info:            ICESTORM_LC:  4227/ 7680    55%
Info:           ICESTORM_RAM:    32/   32   100%
Info:                  SB_IO:    13/  256     5%
Info:                  SB_GB:     8/    8   100%
Info:           ICESTORM_PLL:     0/    2     0%
Info:            SB_WARMBOOT:     0/    1     0%

With ecall support:

Info: Device utilisation:
Info:            ICESTORM_LC:  4273/ 7680    55%
Info:           ICESTORM_RAM:    32/   32   100%
Info:                  SB_IO:    13/  256     5%
Info:                  SB_GB:     8/    8   100%
Info:           ICESTORM_PLL:     0/    2     0%
Info:            SB_WARMBOOT:     0/    1     0%

[mithro]

ecall is needed for Zephyr support (which makes sense on small config).

[Dolu1990]

Hmm, the ecall isn't the only feature required by the zephyr port, will likely need :
mtvecAccess = CsrAccess.WRITE_ONLY,
wfiGenAsNop = true,

[mateusz-holenko]

litex-vexriscv is definied as a separate SoC in Zephyr that does not touch mtvec or generate wfi (at least for now).

We tested it on shell and philosophers samples and verified that enabling ecall was enough to make them run on HW.

Of course you are right that when VexRiscvc Zephyr port gets extended in the future, there might be a need to enable additional features in the cpu.

[Dolu1990]

@mateusz-holenko Can you send me the link of the litex-vexriscv SoC ? Just to exactly understand how things were customized for litex.

[mateusz-holenko]

@Dolu1990 LiteX+VexRiscv SoC definition in Zephyr: https://github.com/zephyrproject-rtos/zephyr/tree/master/soc/riscv/litex-vexriscv. It's very basic, based mostly on the defaults.

riscv-privilege SoC definition is more advanced (uses wfi for instance), but it's separate from litex-vexriscv

[mateusz-holenko]

After analyzing the code of LiteX+VeRiscv port of Zephyr again I realized I was mistaken.

litex-vexriscv SoC definition does use fragments of riscv-privilege: https://github.com/zephyrproject-rtos/zephyr/blob/master/soc/riscv/litex-vexriscv/CMakeLists.txt#L8-L9 (which includes vector.S that sets the mtvec). In this context mtvecAccess should not be set to NONE (which, if I understand correctly causes mtvec to be always the default 0x20), but rather be modifiable (hence WRITE_ONLY or READ_WRITE access is of course needed).

There is also a wfi instruction generated in loop_slave_core (https://github.com/zephyrproject-rtos/zephyr/blob/e0ed8ebac48b2ad2ada82224348a87fda80ee47b/arch/riscv/core/reset.S#L44), so the proper wfi configuration is also needed. I see there are two options: wfiGenAsWait and wfiGenAsNop - what happens if both are set to false (which is the case now)?

We are now reproducing the test on HW to see why is it working with only ecall enabled.

[mateusz-holenko]

I can confirm that Zephyr binaries work fine on VexRiscv.small configuration with mtvec access set to NONE.

Zephyr congifures mtvec to 0x40000010, so it shouldn't work.

Looking at the generated verilog it seems that the code for mtvec reading/writing is there - could it be a bug in the VexRiscv?

[Dolu1990]

@mateusz-holenko

In SpinalHDL, the description seem right (https://github.com/SpinalHDL/VexRiscv/blob/master/src/main/scala/vexriscv/plugin/CsrPlugin.scala#L541)
Hmm i will check the generated verilog, that's weird.

Anyway, thanks for the info :)

[mateusz-holenko]

@Dolu1990 Did you have time to check why mtvec logic is generated in the verilog even when mtvec access is set to NONE?

Anyway, your suggestion that we should configure MTVEC and WFI are valid, so we updated the commit. Does it look fine now?

[mateusz-holenko]

I see that Travis has failed with:

Error during sbt execution: No Scala version specified or detected

Could it be related to our changes?

[Dolu1990]

@mateusz-holenko Ahh mybad, sorry i forgot about it, stack overflow, just ping me when if it appen again ^^

So, i just generated a small config (GenSmallest => mtvecAccess = CsrAccess.NONE,)
and the hardware is correct, mtvec is realy hardwired as expected :

  assign CsrPlugin_mtvec_mode = (2'b00);
  assign CsrPlugin_mtvec_base = (30'b000000000000000000000000001000);

  always @ (*) begin
    CsrPlugin_xtvec_base = (30'bxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx);
    case(CsrPlugin_targetPrivilege)
      2'b11 : begin
        CsrPlugin_xtvec_base = CsrPlugin_mtvec_base;
      end
      default : begin
      end
    endcase
  end

  always @ (*) begin
    CsrPlugin_jumpInterface_payload = (32'bxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx);
    if(_zz_108_)begin
      CsrPlugin_jumpInterface_payload = {CsrPlugin_xtvec_base,(2'b00)};
    end
    if(_zz_109_)begin
      case(_zz_110_)
        2'b11 : begin
          CsrPlugin_jumpInterface_payload = CsrPlugin_mepc;
        end
        default : begin
        end
      endcase
    end
  end

So i susspect you had maybe some luck one way or another. Can you send me your verilog ?

About the travis failure, sometime that happen, and i don't think that's related to your changes, but just crap on their VM side. I relauched them :)

[mateusz-holenko]

Since the verilog files have around 5k lines I posted them on pastebin: https://pastebin.com/KuE46fpB https://pastebin.com/DjxzhYHf.

Both of them have a fragment, that I believe is responsible for setting mtvec value:

    case(execute_CsrPlugin_csrAddress)
      12'b101111000000 : begin
      end
      12'b001100000000 : begin
      end
      12'b001101000001 : begin
        if(execute_CsrPlugin_writeEnable)begin
          CsrPlugin_mepc <= execute_CsrPlugin_writeData[31 : 0];
        end
      end
      12'b001100000101 : begin
        if(execute_CsrPlugin_writeEnable)begin
          CsrPlugin_mtvec_base <= execute_CsrPlugin_writeData[31 : 2];
          CsrPlugin_mtvec_mode <= execute_CsrPlugin_writeData[1 : 0];
        end
      end
      12'b001101000100 : begin
        if(execute_CsrPlugin_writeEnable)begin
          CsrPlugin_mip_MSIP <= _zz_365_[0];
        end
      end
      12'b110011000000 : begin
      end
      12'b001101000011 : begin
      end
      12'b111111000000 : begin
      end
      12'b001100000100 : begin
      end
      12'b001101000010 : begin
      end
      default : begin
      end
    endcase

I think that MTVEC writeability is a separate issue that does not have to block this PR. Do you think that the current configuration is mergable?

[Dolu1990]

Ahhhhhhhhhhhhhhhh
got it :
https://github.com/m-labs/VexRiscv-verilog/blob/master/src/main/scala/vexriscv/GenCoreDefault.scala#L176

Make sense now :) ?

[mateusz-holenko]

Yeah, it definiately does!

So there are apparently two ways we can proceed:

• either change the defaults for small configuration at this repo;
• or leave this repo as it is and just modify the actual configuration used to generate verilogs at https://github.com/m-labs/VexRiscv-verilog.

Which one you think is better?

[mateusz-holenko]

@Dolu1990 What do we do with this PR?

[Dolu1990]

@mateusz-holenko Sorry for the delay.

I would prefer keeping things on the VexRiscv as barmetal as possible and avoid specifics requirements of OS to leak in, as different OS have different requirements, having to enable by default the common denominator of those could lead in quit some overhead.

So the way to go would be to add those configurations in https://github.com/m-labs/VexRiscv-verilog to meet demands.

Sound good ?

[mateusz-holenko]

Sounds fine. We will move this change to https://github.com/m-labs/VexRiscv-verilog.