neorv32 Program Counter Operation

[DS-567]

Hi Stephan,

I have been experimenting and becoming familiar with the neorv32 core and really enjoying using it so far. I'm now ready to start using it for my PhD research project. I am trying to understand how the program counter works with this processor. I have been reading through the VHDL files under neorv32/rtl/core and can see the program counter (PC) seem to be driven from the module neorv32_cpu_control. I know it is a complicated question, but can you explain how the PC works internally regarding how it is updated? I mean in terms of current, last and next instruction that are used in this module.

I want to be able to inject faults into the program counter but not 100% sure how it operates yet.

[stnolting]

Hey there!

I have been experimenting and becoming familiar with the neorv32 core and really enjoying using it so far. I'm now ready to start using it for my PhD research project.

Great to hear! :)

I know it is a complicated question, but can you explain how the PC works internally regarding how it is updated? I mean in terms of current, last and next instruction that are used in this module.

Actually, there are two program counters:

• one for fetching 32-bit chunks of the instruction data ("PC" in the figure below)

neorv32/rtl/core/neorv32_cpu_control.vhd

Line 400 in a004fb5

fetch_engine.pc <= (others => '0');

• another one that reflects the actual "application" program counter ("PC2" in the figure below)

neorv32/rtl/core/neorv32_cpu_control.vhd

Line 682 in a004fb5

execute_engine.pc <= CPU_BOOT_ADDR(XLEN-1 downto 2) & "00"; -- 32-bit aligned boot address

The instruction fetch program counter ("PC") will keep increasing by 4 with each now instruction fetch. The fetched instruction data is stored into a FIFO (the "instruction prefetch buffer (IPB)"). As soon as there is a taken branch, a jump, an interrupts, ..., the actual program counter ("PC2") will get updated and copied to the instruction fetch PC will also clearing the instruction prefetch buffer:

neorv32/rtl/core/neorv32_cpu_control.vhd

Lines 416 to 420 in a004fb5

	when IF_RESTART => -- set new fetch start address
	-- ------------------------------------------------------------
	fetch_engine.pc <= execute_engine.pc(XLEN-1 downto 2) & "00"; -- initialize with "real" PC, 32-bit aligned
	fetch_engine.unaligned <= execute_engine.pc(1);
	fetch_engine.state <= IF_REQUEST;

The application program counter ("PC2") is the one visible to the ISA / to the actual program being executed. It will increment by 4 (or by 2 when executing a compressed instruction) whenever the CPU's "execution engine" is in the EXECUTE state:

neorv32/rtl/core/neorv32_cpu_control.vhd

Lines 734 to 735 in a004fb5

	when EXECUTE => -- NORMAL pc increment
	execute_engine.next_pc <= std_ulogic_vector(unsigned(execute_engine.pc) + unsigned(execute_engine.next_pc_inc)); -- next linear PC

Additionally, the PC from the previous instruction is backup-ed in case we encounter an exception (for example an illegal instruction word:

neorv32/rtl/core/neorv32_cpu_control.vhd

Lines 704 to 707 in a004fb5

	-- PC of "last executed" instruction for trap handling --
	if (execute_engine.state = EXECUTE) then
	execute_engine.pc_last <= execute_engine.pc;
	end if;

In this case the RISC-V mepc CSR is written with the address that corresponds to the instruction that has caused the exception.

If we encounter an interrupt we need to store the address of the interrupted instruction (that has not been executed yet) to the mepc CSR (which is the "current" PC):

neorv32/rtl/core/neorv32_cpu_control.vhd

Lines 1571 to 1573 in a004fb5

	-- exception program counter (for updating xCAUSE CSRs) --
	trap_ctrl.epc <= (execute_engine.pc(XLEN-1 downto 1) & '0') when (((trap_ctrl.cause(trap_ctrl.cause'left)) = '1') or (trap_ctrl.cause = trap_iba_c)) else -- interrupted instruction
	(execute_engine.pc_last(XLEN-1 downto 1) & '0'); -- last executed instruction

As mentioned above, whenever we encounter a trap (exception or interrupt) we update the mepc CSR. That trap handler can optionally modify this CSR before returning:

neorv32/rtl/core/neorv32_cpu_control.vhd

Lines 1906 to 1912 in a004fb5

	-- NORMAL trap entry: write mcause, mepc and mtval - no update when in debug-mode! --
	-- --------------------------------------------------------------------
	if (CPU_EXTENSION_RISCV_Sdext = false) or ((trap_ctrl.cause(5) = '0') and (debug_ctrl.running = '0')) then
	-- trap cause ID --
	csr.mcause <= trap_ctrl.cause(trap_ctrl.cause'left) & trap_ctrl.cause(4 downto 0); -- type + identifier
	-- trap PC --
	csr.mepc <= trap_ctrl.epc;

I know the VHDL code is quite complex here... 😅 So feel free to ask if you have further questions!

---

I want to be able to inject faults into the program counter but not 100% sure how it operates yet.

Sounds interesting! What kind of "faults" do you plan to inject (in what situations)?