Lab_NHMFL
/
upsilon
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
upsilon/swic/load_exec.py

40 lines
1.2 KiB
Python
Raw Normal View History

Progress on PicoRV32 1) The PicoRV32 bus was not generated correctly. Running "finalize" on the bus, which is what the SoC does, does not generate the bus logic correctly. I don't know if this is a bug or if the SoC bus generator is only meant to be used in the main SoC. Currently the bus logic is copied from the LiteX finalize code. 2) Add test micropython code to load code. 3) Removed BRAM. The Wishbone cache was messing with the direct implementation of the BRAM because the BRAM did not implement all the bus features correctly. LiteX has a Wishbone "SRAM" module, and despite it's name it can also generate BRAM if there are available BRAM. This is how the ROM and the startup RAM are implemented. The PicoRV32 ram is now using this SRAM.
2024-02-20 10:28:51 -05:00
import machine
from mmio import *
def read_file(filename):
with open(filename, 'rb') as f:
return f.read()
Get PicoRV32 to execute code 1. Update LiteX to 2023.12. This update adds wishbone bus addressing modes. Before this update, all wishbone buses used word addressing. For example, 0x0 mapped to word 0, 0x0 mapped to word 1, etc. This caused problems with the PicoRV32 and other modules, which are byte addressed. 2. Use adapter to convert between byte and word addressing. The SRAM is word addressed. The PicoRV32 shifts the address down by two bits to address the correct word. The PicoRV32 core seems to expect this. 3. Add debug register output. This is not working yet. 4. Use LiteX PicoRV32 wishbone adapter instead of PicoRV32 default. This seems to be simpler (combinatorial not synchronous). 5. Add some documentation. 6. Seperate config to new config file.
2024-02-25 13:58:34 -05:00
def u(n):
return hex(n & 0xFFFFFFFF)
picorv32 now runs: debugging outputs
2024-02-21 23:58:59 -05:00
def check_running():
print("Running:", machine.mem32[pico0_enable])
print("Trap status:", machine.mem32[pico0_trap])
Get PicoRV32 to execute code 1. Update LiteX to 2023.12. This update adds wishbone bus addressing modes. Before this update, all wishbone buses used word addressing. For example, 0x0 mapped to word 0, 0x0 mapped to word 1, etc. This caused problems with the PicoRV32 and other modules, which are byte addressed. 2. Use adapter to convert between byte and word addressing. The SRAM is word addressed. The PicoRV32 shifts the address down by two bits to address the correct word. The PicoRV32 core seems to expect this. 3. Add debug register output. This is not working yet. 4. Use LiteX PicoRV32 wishbone adapter instead of PicoRV32 default. This seems to be simpler (combinatorial not synchronous). 5. Add some documentation. 6. Seperate config to new config file.
2024-02-25 13:58:34 -05:00
print("Bus address:", u(machine.mem32[pico0_d_adr]))
print("Bus write value:", u(machine.mem32[pico0_d_dat_w]))
print("Instruction address:", u(machine.mem32[pico0_dbg_insn_addr]))
print("Opcode:", u(machine.mem32[pico0_dbg_insn_opcode]))
for num in range(0,31):
Successfully read PicoRV32 registers
2024-02-25 19:47:43 -05:00
print("Reg", num + 1, ":", u(machine.mem32[pico0_dbg_reg + num*0x4]))
picorv32 now runs: debugging outputs
2024-02-21 23:58:59 -05:00
Progress on PicoRV32 1) The PicoRV32 bus was not generated correctly. Running "finalize" on the bus, which is what the SoC does, does not generate the bus logic correctly. I don't know if this is a bug or if the SoC bus generator is only meant to be used in the main SoC. Currently the bus logic is copied from the LiteX finalize code. 2) Add test micropython code to load code. 3) Removed BRAM. The Wishbone cache was messing with the direct implementation of the BRAM because the BRAM did not implement all the bus features correctly. LiteX has a Wishbone "SRAM" module, and despite it's name it can also generate BRAM if there are available BRAM. This is how the ROM and the startup RAM are implemented. The PicoRV32 ram is now using this SRAM.
2024-02-20 10:28:51 -05:00
def run_program(prog, cl_I):
# Reset PicoRV32
picorv32 now runs: debugging outputs
2024-02-21 23:58:59 -05:00
machine.mem32[pico0_enable] = 0
machine.mem32[pico0ram_iface_master_select] = 0
Progress on PicoRV32 1) The PicoRV32 bus was not generated correctly. Running "finalize" on the bus, which is what the SoC does, does not generate the bus logic correctly. I don't know if this is a bug or if the SoC bus generator is only meant to be used in the main SoC. Currently the bus logic is copied from the LiteX finalize code. 2) Add test micropython code to load code. 3) Removed BRAM. The Wishbone cache was messing with the direct implementation of the BRAM because the BRAM did not implement all the bus features correctly. LiteX has a Wishbone "SRAM" module, and despite it's name it can also generate BRAM if there are available BRAM. This is how the ROM and the startup RAM are implemented. The PicoRV32 ram is now using this SRAM.
2024-02-20 10:28:51 -05:00
picorv32 now runs: debugging outputs
2024-02-21 23:58:59 -05:00
offset = pico0_ram
Progress on PicoRV32 1) The PicoRV32 bus was not generated correctly. Running "finalize" on the bus, which is what the SoC does, does not generate the bus logic correctly. I don't know if this is a bug or if the SoC bus generator is only meant to be used in the main SoC. Currently the bus logic is copied from the LiteX finalize code. 2) Add test micropython code to load code. 3) Removed BRAM. The Wishbone cache was messing with the direct implementation of the BRAM because the BRAM did not implement all the bus features correctly. LiteX has a Wishbone "SRAM" module, and despite it's name it can also generate BRAM if there are available BRAM. This is how the ROM and the startup RAM are implemented. The PicoRV32 ram is now using this SRAM.
2024-02-20 10:28:51 -05:00
for b in prog:
machine.mem8[offset] = b
offset += 1
for i in range(len(prog)):
picorv32 now runs: debugging outputs
2024-02-21 23:58:59 -05:00
assert machine.mem8[pico0_ram + i] == prog[i]
Progress on PicoRV32 1) The PicoRV32 bus was not generated correctly. Running "finalize" on the bus, which is what the SoC does, does not generate the bus logic correctly. I don't know if this is a bug or if the SoC bus generator is only meant to be used in the main SoC. Currently the bus logic is copied from the LiteX finalize code. 2) Add test micropython code to load code. 3) Removed BRAM. The Wishbone cache was messing with the direct implementation of the BRAM because the BRAM did not implement all the bus features correctly. LiteX has a Wishbone "SRAM" module, and despite it's name it can also generate BRAM if there are available BRAM. This is how the ROM and the startup RAM are implemented. The PicoRV32 ram is now using this SRAM.
2024-02-20 10:28:51 -05:00
picorv32 now runs: debugging outputs
2024-02-21 23:58:59 -05:00
machine.mem32[pico0_params_cl_I] = cl_I
machine.mem32[pico0ram_iface_master_select] = 1
assert machine.mem8[pico0_ram] == 0
machine.mem32[pico0_enable] = 1
return machine.mem32[pico0_params_zset]