Hi all, We noticed that our design in user project area is not working properly and we would like to understand why this happens. Previously we verified that the design works in RTL and GL simulations on Caravel design, which had been used for MPW-2 submissions at that time. I have two questions regarding this issue: 1. Which Caravel release in GitHub should be used for RTL and GL simulations regarding MPW-2 tape-outs? 2. Our design waits for a flag to be set by the software running on the core. Can we use the housekeeping block to understand that the wishbone interface is operational after reset?

I'd suggest that the best approach is (1) run a short program that outputs to the UART that you can receive on a serial display; then (2) assuming that your wishbone interface reads and writes to registers in the user project area, confirm that you can write a value to one of those registers and read it back, displaying a status to the UART (you can also use the simpler method of blinking out a response on the management gpio line connected to the LED on the board). The housekeeping block isn't going to tell you much about the internal state of the processor or user project. @jeffdi can confirm, but I believe that the state of the processor for MPW-2 was the tag

mpw-2b

. I am rather unsure on this point, because we moved to a new caravel repository before the MPW-2 tapeout. Some people did not update, leading to some confusion and issues with testing. Especially as MPW-one used the picoRV32 with several extra RISCV features like compressed instructions. If you want to share the testbench you're trying to get running, I'm happy to take a look at it.

@Tim Edwards, I can use the GPIOs to send UART packets and read the status of the registers on the terminal. After power-on reset, I observe that all the bits that are read from the wishbone interface have the value of

1

despite the expected reset response of some of the bits is

0

.

Can you post the C code for the program you're running?

@Tim Edwards, I have attached a MWE for your reference.

There is a register that enables the wishbone bus for the user project that you need to set.

Isn't it

reg_mprj_xfer

?

No; it's something like

reg_wb_ena

.

Is this introduced in the newer Caravel SoC harness? https://github.com/efabless/caravel_user_project/blob/b6f76303c4e1aba369375cf31461ae574371c904/verilog/dv/README.md#wishbone-test

It was introduced in MPW-2. The intent is to protect the management SoC from signals coming from the user project area. The "la_iena" signals are the equivalent enables for the logic analyzer.

These are reg_la0_iena, reg_la1_iena, reg_la2_iena, reg_la3_iena. Right?

Yes, that's correct (sorry about the late reply).

No worries.