I can't get caravel + wishbone to work in simulation for an mpw-7 project. Whenever I enable caravel (by writing 1 to

reg_wb_enable

, the RISC-V core always get a trap (code 2) a few instructions later. The full code is here: https://github.com/wokwi/wrapped_silife/blob/85426e520bbd6e23239966ee6f4dca004a54eafa/caravel_silife_test/silife_test.c#L117

@Uri Shaked may not be directly related, but I found some issues with the zero-to-asic chip on mpw-7. CVC-RV detected some tri-state outputs into buffers. CVC: tri-state output into buffers

Signal	                            Instance
/wb_openram_wrapper/wb_b_clk_i	    /Xwb_openram_wrapper(ND_JE_wb_openram_wrapper)/Xclkbuf_0_wb_b_clk_i(ND_JE_sky130_fd_sc_hd__clkbuf_16)
/wb_openram_wrapper/wb_b_rst_i	    /Xwb_openram_wrapper(ND_JE_wb_openram_wrapper)/Xinput66(ND_JE_sky130_fd_sc_hd__clkbuf_2)
/wb_openram_wrapper/wbs_b_adr_i[2]	/Xwb_openram_wrapper(ND_JE_wb_openram_wrapper)/Xinput115(ND_JE_sky130_fd_sc_hd__clkbuf_4)
/wb_openram_wrapper/wbs_b_adr_i[3]	/Xwb_openram_wrapper(ND_JE_wb_openram_wrapper)/Xinput116(ND_JE_sky130_fd_sc_hd__clkbuf_4)
/wb_openram_wrapper/wbs_b_adr_i[4]	/Xwb_openram_wrapper(ND_JE_wb_openram_wrapper)/Xinput117(ND_JE_sky130_fd_sc_hd__clkbuf_4)
/wb_openram_wrapper/wbs_b_adr_i[5]	/Xwb_openram_wrapper(ND_JE_wb_openram_wrapper)/Xinput118(ND_JE_sky130_fd_sc_hd__clkbuf_4)
/wb_openram_wrapper/wbs_b_adr_i[6]	/Xwb_openram_wrapper(ND_JE_wb_openram_wrapper)/Xinput119(ND_JE_sky130_fd_sc_hd__buf_2)
/wb_openram_wrapper/wbs_b_adr_i[7]	/Xwb_openram_wrapper(ND_JE_wb_openram_wrapper)/Xinput120(ND_JE_sky130_fd_sc_hd__buf_2)
/wb_openram_wrapper/wbs_b_adr_i[8]	/Xwb_openram_wrapper(ND_JE_wb_openram_wrapper)/Xinput121(ND_JE_sky130_fd_sc_hd__buf_2)
/wb_openram_wrapper/wbs_b_adr_i[9]	/Xwb_openram_wrapper(ND_JE_wb_openram_wrapper)/Xinput122(ND_JE_sky130_fd_sc_hd__buf_2)
/wb_openram_wrapper/wbs_b_cyc_i	    /Xwb_openram_wrapper(ND_JE_wb_openram_wrapper)/Xinput123(ND_JE_sky130_fd_sc_hd__clkbuf_1)
/wb_openram_wrapper/wbs_b_stb_i	    /Xwb_openram_wrapper(ND_JE_wb_openram_wrapper)/Xinput160(ND_JE_sky130_fd_sc_hd__clkbuf_1)

The new oeb/gpio check gives these results

gpio |   in   |   out  | analog |  oeb min/sim/max  | gpio default                      | Message
   0  |        |     12 |        | vssd*/     /vssd* | 13'h1803                          | Warning: default override required / USER and OUTPUT mode required. 
   1  |        |     12 |        | vssd*/     /vssd* | 13'h1803                          | Warning: default override required / USER and OUTPUT mode required. 
   2  |        |     12 |        | vssd*/     /vssd* | GPIO_MODE_MGMT_STD_INPUT_NOPULL   | Warning: default override required / USER and OUTPUT mode required. 
   3  |        |     12 |        | vssd*/     /vssd* | GPIO_MODE_MGMT_STD_INPUT_PULLUP   | Warning: default override required / USER and OUTPUT mode required. 
   4  |        |     12 |        | vssd*/     /vssd* | GPIO_MODE_MGMT_STD_INPUT_NOPULL   | Warning: default override required / USER and OUTPUT mode required. 
   5  |        |     12 |        | vssd*/     /vssd* | GPIO_MODE_MGMT_STD_OUTPUT         | ERROR: USER and OUTPUT mode required. 
   6  |        |     12 |        | vssd*/     /vssd* | GPIO_MODE_MGMT_STD_OUTPUT         | ERROR: USER and OUTPUT mode required. 
   7  |        |     12 |        | vssd*/     /vssd* | GPIO_MODE_MGMT_STD_OUTPUT         | ERROR: USER and OUTPUT mode required. 
   8  |      8 |     12 |        | vssd*/     /vssd* | GPIO_MODE_MGMT_STD_OUTPUT         | ERROR: USER BIDIRECTIONAL mode required. 
   9  |      8 |     12 |        | vssd*/     /vssd* | GPIO_MODE_MGMT_STD_OUTPUT         | ERROR: USER BIDIRECTIONAL mode required. 
  10  |      8 |     12 |        | vssd*/     /vssd* | GPIO_MODE_MGMT_STD_OUTPUT         | ERROR: USER BIDIRECTIONAL mode required. 
  11  |     12 |     12 |        | vssd*/     /vssd* | GPIO_MODE_MGMT_STD_OUTPUT         | ERROR: USER BIDIRECTIONAL mode required. 
  12  |     12 |     12 |        | vssd*/     /vssd* | GPIO_MODE_MGMT_STD_OUTPUT         | ERROR: USER BIDIRECTIONAL mode required. 
  13  |      8 |     12 |        | vssd*/     /vccd* | GPIO_MODE_MGMT_STD_OUTPUT         | ERROR: USER BIDIRECTIONAL mode required. 
  14  |     12 |     12 |        | vssd*/     /vssd* | GPIO_MODE_MGMT_STD_OUTPUT         | ERROR: USER BIDIRECTIONAL mode required. 
  15  |      4 |     12 |        | vssd*/     /vssd* | GPIO_MODE_MGMT_STD_OUTPUT         | ERROR: USER BIDIRECTIONAL mode required. 
  16  |      8 |     12 |        | vssd*/     /vssd* | GPIO_MODE_MGMT_STD_OUTPUT         | ERROR: USER BIDIRECTIONAL mode required. 
  17  |      4 |     12 |        | vssd*/     /vssd* | GPIO_MODE_MGMT_STD_OUTPUT         | ERROR: USER BIDIRECTIONAL mode required. 
  18  |      8 |     12 |        | vssd*/     /vssd* | GPIO_MODE_MGMT_STD_OUTPUT         | ERROR: USER BIDIRECTIONAL mode required. 
  19  |      4 |     12 |        | vssd*/     /vssd* | GPIO_MODE_MGMT_STD_OUTPUT         | ERROR: USER BIDIRECTIONAL mode required. 
  20  |      8 |     12 |        | vssd*/     /vssd* | GPIO_MODE_MGMT_STD_OUTPUT         | ERROR: USER BIDIRECTIONAL mode required. 
  21  |      4 |     12 |        | vssd*/     /vssd* | GPIO_MODE_MGMT_STD_OUTPUT         | ERROR: USER BIDIRECTIONAL mode required. 
  22  |      8 |     12 |        | vssd*/     /vssd* | GPIO_MODE_MGMT_STD_OUTPUT         | ERROR: USER BIDIRECTIONAL mode required. 
  23  |      8 |     12 |        | vssd*/     /vssd* | GPIO_MODE_MGMT_STD_OUTPUT         | ERROR: USER BIDIRECTIONAL mode required. 
  24  |      4 |     12 |        | vssd*/     /vssd* | GPIO_MODE_MGMT_STD_OUTPUT         | ERROR: USER BIDIRECTIONAL mode required. 
  25  |        |     12 |        | vssd*/     /vssd* | GPIO_MODE_MGMT_STD_OUTPUT         | ERROR: USER and OUTPUT mode required. 
  26  |        |     12 |        | vssd*/     /vssd* | GPIO_MODE_MGMT_STD_OUTPUT         | ERROR: USER and OUTPUT mode required. 
  27  |        |     12 |        | vssd*/     /vssd* | GPIO_MODE_MGMT_STD_OUTPUT         | ERROR: USER and OUTPUT mode required. 
  28  |        |     12 |        | vssd*/     /vssd* | GPIO_MODE_MGMT_STD_OUTPUT         | ERROR: USER and OUTPUT mode required. 
  29  |        |     12 |        | vssd*/     /vssd* | GPIO_MODE_MGMT_STD_OUTPUT         | ERROR: USER and OUTPUT mode required. 
  30  |        |     12 |        | vssd*/     /vssd* | GPIO_MODE_MGMT_STD_OUTPUT         | ERROR: USER and OUTPUT mode required. 
  31  |        |     12 |        | vssd*/     /vssd* | GPIO_MODE_MGMT_STD_OUTPUT         | ERROR: USER and OUTPUT mode required. 
  32  |      4 |     12 |        | vssd*/     /vssd* | GPIO_MODE_MGMT_STD_OUTPUT         | ERROR: USER BIDIRECTIONAL mode required. 
  33  |        |     12 |        | vssd*/     /vssd* | GPIO_MODE_MGMT_STD_OUTPUT         | ERROR: USER and OUTPUT mode required. 
  34  |        |     12 |        | vssd*/     /vssd* | GPIO_MODE_MGMT_STD_OUTPUT         | ERROR: USER and OUTPUT mode required. 
  35  |        |     12 |        | vssd*/     /vssd* | GPIO_MODE_MGMT_STD_OUTPUT         | ERROR: USER and OUTPUT mode required. 
  36  |        |     12 |        | vssd*/     /vssd* | GPIO_MODE_MGMT_STD_OUTPUT         | ERROR: USER and OUTPUT mode required. 
  37  |        |     12 |        | vssd*/     /vssd* | GPIO_MODE_MGMT_STD_OUTPUT         | ERROR: USER and OUTPUT mode required.

You’ll probably want to reprogram gpio 0-7,25-31,33-37 as

GPIO_MODE_USER_STD_OUTPUT

gpio 8-24,32 as

GPIO_MODE_MGMT_STD_BIDIRECTIONAL

Although it’s not flagged, there may be a problem with the

io_oeb

signals on the input/output pins with max vssd voltage. In input mode, you probably want the

io_oeb

signal to be high. Looks like the

io_in

,

io_out

, and

io_oeb

signals are being shared by several macros. The macros using a gpio as only output most likely have

io_oeb

tied low. However, other macros using the same gpio as an input, may not set

io_oeb

to high. This would result in a Hi-Z input to

io_oeb

for macros expecting input and if the gpio is configured as bidirectional, you may get unexpected output when you input too. When using multiple macros, macros expecting inputs should set

io_oeb

to high (and tie

io_out

to something). The workaround is to reprogram the gpio for the macro you want active. Use

GPIO_MODE_USER_STD_OUTPUT

for outputs and

GPIO_MODE_MGMT_STD_INPUT_NOPULL

for inputs. I do not recommend using

GPIO_MODE_USER_STD_INPUT_NOPULL

for input because the user

io_oeb

and

io_out

are probably Hi-Z and may result in leaks.

This is just a simulation issue for now as I understand it

I've tried several tags, starting from mpw-7a, then mpw-7h, and now even with the mpw-9g

@Uri Shaked, @Matt Venn: I am seeing something that might or might not be related; I'm seeing the issue in hardware and not in simulation. In simulation, I have a testbench set up that is operating correctly, but the same testbench run on the hardware is not communicating with the user project through wishbone. It seems to be related to the

reg_wb_enable

signal, in that the behavior is the same whether or not I have that set to one or zero. It does not appear to be related to any trap state on the CPU, though; it follows what I would consider to be the normal behavior for the CPU if a peripheral is not responding on wishbone---It counts down from 1 million, executes a timeout, and then continues (the count of 1 million being 1/10 second with the 10MHz clock, this is actually pretty easy to confirm). I was not aware that the VexRISC produces a trap state because I was told that there was no signal to connect to the trap monitor; otherwise, I could monitor the trap state on the physical hardware. Without it, I have to guess what's going on in the CPU (although the CPU has a debug feature which I will need to learn how to use). My simulation setup is using a copy of "caravel" and "caravel_mgmt_soc_litex" both of which are set to the tag "mpw-8c".

Thanks Tim! I don't have the silicon. Matt has is - I sent him the firmware for testing.

There was also a recent issue solved in the new firmware library where wishbone writes were not using volatile types and the processor could issue 2 writes before getting the first ack

@Matt Venn: Can you elaborate on that? In the

defs.h

file I see all memory-mapped addresses specified as volatile, and my own user project address specification marks all user project memory-mapped addresses as volatile, too.

Here: https://github.com/efabless/caravel_mgmt_soc_litex/pull/135#issuecomment-1875306878

hi, @Matt Venn even my wishbone is not able to return data, pls can u give link to final firmware with updates?