https://open-source-silicon.dev logo
Join Slack
Powered by
My design is currently integrated with the picorv3...
# mpw-3-silicon
j
My design is currently integrated with the picorv32 management core I'm just trying to swap it with the newer caravel version (mpw-3 to mpw-3b). @Tim Edwards maybe you would remember if there were any gotchas with this?
t
What have you done so far and what have you run across? There are a handful of specific gotchas, certainly, as (1) the RISCV compiler target type changed, as did the linker file and startup assembler code; (2) addresses changed, which should be transparently handled by defs.h; (3) a handful of new memory-mapped addresses were added. The first step is just to swap out the original caravel core for the mpw-3 version. Have you gotten that far? What issues are you currently seeing?
j
I swapped the picorv32 core out for the vex core but it looks like the management core wrapper interface may have changed a bit? I see
Copy code
/home/jcirimel/mpw3/clean/caravel/verilog/rtl/caravel.v:371: error: port ``sram_ro_clk'' is not a port of soc.
/home/jcirimel/mpw3/clean/caravel/verilog/rtl/caravel.v:371: error: port ``sram_ro_csb'' is not a port of soc.
/home/jcirimel/mpw3/clean/caravel/verilog/rtl/caravel.v:371: error: port ``sram_ro_addr'' is not a port of soc.
/home/jcirimel/mpw3/clean/caravel/verilog/rtl/caravel.v:371: error: port ``sram_ro_data'' is not a port of soc.
when I try to run an rtl simulation. I see some potentially relevant warnings in the mpw-3b repo for the core here https://github.com/efabless/caravel_mgmt_soc_litex/blob/mpw-3b/sram_roerrors
I should have the correct tooling because I was able to program the silicon fine and run simple programs.
I started everything from scratch again and am not seeing this anymore. I'm running an unmodified la_test1 rtl and simulations are running but it still looks like there are issues, probably from what you mentioned earlier. I'm dumping a vcd now.
I see that the spi flash address is unknown but the rest of the spi looks fine.
t
The 
sram_ro_clk
and other signals indicate that the 
caravel/
repository, which is usually cloned from "caravel-lite", was still out of date, since the read-only 2nd port access to the SRAM was removed (because the SRAM was replaced with DFFRAM that doesn't have a 2nd port). Feel free to post your C code and I can check for compatibility issues that I know about (but won't necessarily come to my mind without prompting).
j
I imagine my immediate issue isn't a C problem since it seems like things are going wrong before the flash starts executing
la_test1.zip
t
The 
Makefile
targets need to be updated. What you have is using 
-march=rv32imc
which might run some simple code but is going to fail if the compiler generates a compressed instruction or a hardware multiply, neither of which is supported on the VexRISC. Compare the compile line from your Makefile:
Copy code
${GCC_PATH}/${GCC_PREFIX}-gcc -I $(CARAVEL_PATH) -march=rv32imc -mabi=ilp32 -Wl,-Bstatic,-T,$(CARAVEL_FIRMWARE_PATH)/sections.lds,--strip-debug -ffreestanding -nostdlib -o $@ $(CARAVEL_FIRMWARE_PATH)/start.s $<
to the Makefile from the caravel_board repo `firmware/mpw2-5/blink/Makefile`:
Copy code
$(TOOLCHAIN_PATH)$(TOOLCHAIN_PREFIX)-unknown-elf-gcc -I../ -I../generated/ -O0 -mabi=ilp32 -march=rv32i_zicsr -D__vexriscv__ -Wl,-Bstatic,-T,../sections.lds,--strip-debug -ffreestanding -nostdlib -o $@ ../crt0_vex.S ../isr.c $<
There is also a significant difference between the startup code in 
crt0_vex.S
and 
start.s
.
The Makefiles in user project verification now look like this (and all the Makefiles are the same):
Copy code
PWDD := $(shell pwd)
BLOCKS := $(shell basename $(PWDD))

# ---- Include Partitioned Makefiles ----

CONFIG = caravel_user_project

include $(MCW_ROOT)/verilog/dv/make/env.makefile
include $(MCW_ROOT)/verilog/dv/make/var.makefile
include $(MCW_ROOT)/verilog/dv/make/cpu.makefile
include $(MCW_ROOT)/verilog/dv/make/sim.makefile
and all the compiler stuff has been moved into one of those included files. But I'm not sure if that predates mpw-3 or not; 
$MCW_ROOT
points to 
caravel_mgmt_soc_litex
and if there is a directory there called 
verilog/dv/make/
then the Makefile style above applies; otherwise it doesn't.
j
Ok thanks. I'll try these adjustments
I'm running into the same issue compiling with
Copy code
$(GCC_PATH)/$(GCC_PREFIX)-gcc -I$(MCW_FIRMWARE_PATH)/ -I$(MCW_FIRMWARE_PATH)/../ -I$(MCW_FIRMWARE_PATH)/../generated/ -O0 -mabi=ilp32 -march=rv32i_zicsr -D__vexriscv__ -Wl,-Bstatic,-T,$(MCW_ROOT)/verilog/dv/firmware/sections.lds,--strip-debug -ffreestanding -nostdlib -o $@ $(MCW_FIRMWARE_PATH)/crt0_vex.S $(MCW_FIRMWARE_PATH)/isr.c $<
should I be using caravel/mgmt_core_wrapper/verilog/dv/firmware/sections_vexriscv.lds instead of sections.lds? they both look different than https://github.com/efabless/caravel_board/blob/main/firmware/mpw2-5/sections.lds
I got rid of the reg_spimaster_config in my c code as well because I don't see it in the examples in the caravel_board repo so I'm assuming that was for the picorv core?
t
Yes, the SPI master registers are different; 
reg_spimaster_control
and 
reg_spimaster_status
. But what error(s) are you getting now? You mentioned "things are going wrong before the flash starts executing". Is that still the case?
j
Yeah, I'm still having some spi issues. I'm going to try compiling against the files in the caravel_board firmware repo instead of the mpw3 tags of the mcw repo since it looks like the firmware ones my be more up to date
t
Looks like it got out the SPI flash command 0x03 (stream read) and an address (0x000000) and then things started going undefined. But I'm not sure if the undefined values are originating in the processor or in the SPI flash. The hex file in the zip file you posted had a first line pegging the start address at zero, but you've changed things since then. Is your hex file still originating at zero? Having it sitting at the wrong position in the SPI would certainly cause that kind of behavior---Any attempt to access an unoccupied address in the SRAM emulation macro will end up as undefined bits on the flash_io0 and flash_io1 pins.
j
I think my hex now has the start at 0x10000000 which I think makes sense. I think the spi is sets the PC to that after it's done copying the data over.
t
Just change the first line to zero and run it again without any other changes.
The start point is tricky. The compiler needs to assume that it's at 0x10000000 but the hardware maps that in the SPI flash driver to zero.
j
oh nevermind the first line is @00000000 in the hex
I was looking at entry0() in the elf
t
In that case, I would guess that the problem originates in the processor, although I can't think of what would go wrong if it is getting so far as to generate the command word and address to the flash.
j
I'll try loading a prebuilt hex from the caravel_board repo into the simulation just as a sanity check
t
The other sanity check is to check whether the "mpw3" tags were actually valid for the mpw3 tapeout.
j
ah, should I use ./caravel/mgmt_core_wrapper/verilog/dv/vip/spiflash.v instead of ./caravel/verilog/dv/caravel/spiflash.v in the testbench verilog?
Copy code
➜  caravel_user_project git:(mpw-3) ✗ diff ./caravel/verilog/dv/caravel/spiflash.v ./caravel/mgmt_core_wrapper/verilog/dv/vip/spiflash.v
68c68
< 	reg powered_up = 0;
---
> 	reg powered_up = 1;
110,112d109
< 		$display("Memory 5 bytes = 0x%02x 0x%02x 0x%02x 0x%02x 0x%02x",
< 			memory[1048576], memory[1048577], memory[1048578],
< 			memory[1048579], memory[1048580]);
114a112,114
> 		//$display("Memory 5 bytes = 0x%02x 0x%02x 0x%02x 0x%02x 0x%02x",
> 		//	memory[0], memory[1], memory[2],
> 		//	memory[3], memory[4]);
117,118c117,118
< 			memory[1048576], memory[1048577], memory[1048578],
< 			memory[1048579], memory[1048580]);
---
> 			memory[0], memory[1], memory[2],
> 			memory[3], memory[4]);
t
I do recall something about that 
powered_up = 0
vs. 
powered_up = 1
. . .
Now I recall what it was: The picoRV32 always sent out a power-up code first, which is something that the VexRISC doesn't do.
j
Ok, I'll give it a try then. I'm not sure how to check whether the mpw3 tags are valid or not. I did all my verification with the picorv core.
t
Now that my memory has been nudged, I have increasing confidence that the power-on state of the SPI is the problem here. I had just forgotten about working through that same problem myself.
j
ok, great
image.png
spi address and output look good now
t
Great, although that should have been a lot easier than it was.
j
PC is getting set to 0x10000000 and start executing which looks good
the la_test1 still isn't passing so i'm looking into that now
I had to do a lot of manual importing of the MCW paths to get to this point
t
There was a change in the definition of oeb and oea which is probably affecting the logic analyzer.
j
do I need to do anything with reg_spimaster_control or reg_spimaster_status?
t
No, I don't think so.
j
Thanks for all the help too btw!
t
From a discussion with Matt Venn yesterday, I think you need "oena" bits set low for input, but "oenb" bits set low for output. The "oenb" are the same as before but the "oena" signals got inverted.
j
ok 👍
just to be sure, you mean iena not oena right? I don't see oena in the defs file
got the rtl la_test1 working now. The def file in caravel_mgmt_soc_litex mpw-3b tag is missing the reg_la3_data_in addresses since I guess the vexriscv la is full duplex now
t
Okay, good to know.
27 Views
Open in Slack
PreviousNext
Powered by