Serial Reads from the prev post, shows 0xFFFFFFFF, which I am guessing means that it is not reading anything valid as those base addresses must have non-FFFF values for the board to be functioning, which we can verify from the toggling of the LEDs or the operation of UART device.

Hi Samarth, I can see in your previous code that you are trying to read from address 0x21000000, which I don't think is correct anymore. It does appear that this is still referenced in a few places, but from what I can tell the correct register addresses are defined here: https://github.com/efabless/caravel_mgmt_soc_litex/blob/503eda0790085712ffef7f4ad8934c7daed3237f/verilog/dv/firmware/defs.h -- note that even though the comment on line 55 says the GPIO pin has a base address of 0x2100_0000, that comment is also wrong: CSR_GPIO_MODE1_ADDR is now defined via csr.h to be in the address range of 0xFxxxxxxx (i.e. `CSR_BASE` is 0xF000_0000), as are most of the other SoC registers (including UART). Normally these are abstracted in code as the

reg_uart_...

variables (actually they are `#define`s).

Is address for wishbone slave also chnaged?

A valid example of both Wishbone writes and reads is what I expect you see here: https://github.com/efabless/caravel_user_project/blob/main/verilog/dv/wb_port/wb_port.c -- note that it uses a similar pattern to define the direct register access for address 0x30000000 and then does a write and a read from that address.

I tried this:

print("\nWishbone @ "); print_hex(CSR_BASE + 0x5800L, 8); print(": ");

print_hex(read_wishbone(0xF0005800), 8);

print("\n");

and the output sort of made sense, but that cant be the full uart buffer. Anyway, basically the Wishbone read works is the takeaway from this. But trying the user area address of 0x30000000 or 0x30000004 still yields 0xFFFFFFFF. My guess is that the address must be wrong, because even when I tried with unused wishbone addresses like the gpio and stuff all of the addresses returned 00000000 instead of FFFFFFFF. Is there any way to verify that the address is correct and the memory is actually mapped there?

For anyone who comes across this in future, I believe this is all relevant to know for Caravel v6 (e.g. MPW-6+; not sure about MPW2-5), and might've otherwise been difficult to confirm elsewhere: 1. Wishbone includes a

wbs_ack_o

signal that is meant to be set to 1 by a peripheral in order to signal when it has finished making data ready (and thus end a read or write transaction). In other words, so long as it is 0 during a Wishbone read or write transaction, the controller (i.e. CPU) will assume it is still processing the request, and insert wait states (pausing execution) until that ACK signal goes high. 2. The Wishbone spec doesn't explicitly define a timeout for this; if ACK never goes high, this would otherwise lead to an indefinite pause (hang). However... 3. Caravel's Wishbone implementation includes a 1,000,000-cycle timeout, after which a Wishbone read returns 0xFFFFFFFF. Specifically register reads/writes done in the range 0x30000000-0x3FFFFFFF, your firmware will hang and eventually timeout (100ms at 10MHz) if the ACK signal never gets asserted. A timed-out read will see a value of 0xFFFFFFFF. For other addresses outside this range, and that are not otherwise part of the register map, the behaviour might vary; I suspect there's safety-net logic to do a dummy ACK with a value of 0x00000000.

Hi @Anton Maurovic (efabless support), I have seen the post and I think and hope you can help me, I am working with a project using wishbone but the response of the chip is not as expected, among my hundreds of tests trying to find the error I have the feeling that the problem is the whisbone address (0x30000000) when I write a value in 0x30000000 and read that address I find 0x000000000000. The problem is independent of my user_prejct because I only write and read specific memory addresses. I am doing physical validation of the SoC, my C code is as follows:

void main()
{

    reg_spi_enable = 1;
    reg_wb_enable = 1;
    
    reg_mprj_io_31 = GPIO_MODE_MGMT_STD_OUTPUT;
    reg_mprj_io_30 = GPIO_MODE_MGMT_STD_OUTPUT;
    reg_mprj_io_29 = GPIO_MODE_MGMT_STD_OUTPUT;
    reg_mprj_io_28 = GPIO_MODE_MGMT_STD_OUTPUT;
    reg_mprj_io_27 = GPIO_MODE_MGMT_STD_OUTPUT;
    reg_mprj_io_26 = GPIO_MODE_MGMT_STD_OUTPUT;
    reg_mprj_io_25 = GPIO_MODE_MGMT_STD_OUTPUT;
    reg_mprj_io_24 = GPIO_MODE_MGMT_STD_OUTPUT;
    reg_mprj_io_23 = GPIO_MODE_MGMT_STD_OUTPUT;
    reg_mprj_io_22 = GPIO_MODE_MGMT_STD_OUTPUT;
    reg_mprj_io_21 = GPIO_MODE_MGMT_STD_OUTPUT;
    reg_mprj_io_20 = GPIO_MODE_MGMT_STD_OUTPUT;
    reg_mprj_io_19 = GPIO_MODE_MGMT_STD_OUTPUT;
    reg_mprj_io_18 = GPIO_MODE_MGMT_STD_OUTPUT;
    reg_mprj_io_17 = GPIO_MODE_MGMT_STD_OUTPUT;
    reg_mprj_io_16 = GPIO_MODE_MGMT_STD_OUTPUT;

     /* Apply configuration */
    reg_mprj_xfer = 1;
    while (reg_mprj_xfer == 1);

	reg_la2_oenb = reg_la2_iena = 0x00000000;    // [95:64]

	reg_mprj_datal = 0xABCD0000; // Flag start of the test
    	reg_mprj_datal = reg_mprj_io_31<<8; // Show reg_mprj_io_31 on GPIOs
    	//Must be 0x1809
    	reg_mprj_datal = 0xDCBA0000; // 2nd Flag
    	reg_mprj_slave = reg_mprj_io_31;
	reg_mprj_datal = reg_mprj_slave<<8; // Show it on GPIOs

	
	}

Because I am performing physical tests of the SoC I use the GPIOs to see the values written to the memory , my start flag is “ABCD”, then I show the value stored in reg_mprj_io_31(0x260000a0) which corresponds to the definition of “GPIO_MODE_MGMT_STD_OUTPUT” (0x1809), I set a second flag “DCBA”, then I write and read reg_mprj_slave (0x30000000), however what I get back is 0s. Attached is an image of the signals obtained with the logic analyzer. Any idea what might be wrong? Note: I wrote this dummy C code just to try to write/read a value at the whisbone address.

Hi @Emilio Baungarten, at first glance your code appears to be correct, assuming that your Wishbone slave implementation in the user project area is designed correctly. Do you have a snapshot of your Verilog code that was used to synthesize this chip, and can you try running a full-chip RTL (and then Gate-Level) simulation of that version of the code using this same C firmware?