Concerns about

user_defines

file. I have been working on the RTL simulation related to my project for a couple of days, looking closely at the RTL testbench my main problem was that my user area output was not connected to the caravel GPIO, I check the C-Base code using the

GPIO_MODE_USER_STD_OUTPUT

to define the port as a user_prj output, as well as the correct definition of the output in the

user_defines.v

file (e.g.

reg_mprj_io_23 = GPIO_MODE_USER_USER_STD_OUTPUT;

, in the path

caravel_user_project/verilog/rtl/

) and the IOB signal in the

user_project_wrapper.v

(e.g.

assign io_oeb[23:14]={10{1'b0}};

). When I start following the control signals, both mgmt and user_prj end up in the GPIO module, and the strange thing about this is that the GPIO is always handled by mgmt no matter what was defined in the C file and in the

user_defines.v

file previously. Digging deeper into the caravel verilog files, in the path

caravel_user_project/caravel/verilog/rtl/

, I found that all GPIOs are handled by the gpio_defaults signals which are defined by the

user_defines.v

but by the

user_defines.v

in the caravel path (

caravel_user_project/caravel/verilog/rtl/

) and not by the user defined file in the

caravel_user_project/verilog/rtl/

path. Now, something that worries me a lot is what file OpenLane will take when hardening my module, because if the layout uses the user_defines.v file in the caravel path all the GPIO ports will be handled by the mfmt as an input, and that will be a big problem for everyone. Does anyone have information about this?

You do not need to worry about the contents of

user_defines.v

unless you have a particular need for your circuit to come up and run in a standalone configuration without the RISC-V CPU. Otherwise, just configure all the I/O pads from software.

OK thanks, that's useful and important to know. Now, why if I don't change the

user_defines.v

I can't manage the GPIO by software (RISC-V CPU) with the following command

reg_mprj_io_23 = GPIO_MODE_USER_STD_OUTPUT;

? Actually in my C code I only change how the GPIO works.

That should work. You're saying that it doesn't?

Yes, that's why I'm a bit worried. I don't know if it's my version of caravel, when I try to download the latest version to test it, I had problems installing it.

If you trace the signals at the user project interface, do the in/out/oeb lines look correct?

The inputs and outputs of the User project have the correct values. The problem lies in the GPIO instance (gpio_control_block), actually the values going from the user project to the GPIO are fine, the problem is the mgmt enable. Inside the GPIO verilog file we have the following declaration:

/* For 2-wire interfaces, the mgmt_gpio_oeb line is tied high at	*/
    /* the control block.  In this case, the output enable state is	*/
    /* determined by the OEB configuration bit.				*/

    assign pad_gpio_outenb = (mgmt_ena) ? ((mgmt_gpio_oeb == 1'b1) ?
			gpio_outenb : 1'b0) : user_gpio_oeb;

    /* For 2-wire interfaces, if the pad is configured for pull-up or	*/
    /* pull-down, drive the output value locally to achieve the		*/
    /* expected pull.							*/

    assign pad_gpio_out = (mgmt_ena) ? ((mgmt_gpio_oeb == 1'b1) ?
			((gpio_dm[2:1] == 2'b01) ? ~gpio_dm[0] : mgmt_gpio_out) :
			mgmt_gpio_out) : user_gpio_out;

Tracing the mgmt_ena I have the following:

always @(posedge serial_load or negedge resetn) begin
    if (resetn == 1'b0) begin
        /* Initial state on reset depends on applied defaults */
        mgmt_ena <= gpio_defaults[MGMT_EN];
        gpio_holdover <= gpio_defaults[HLDH];
        gpio_slow_sel <= gpio_defaults[SLOW];
        gpio_vtrip_sel <= gpio_defaults[TRIP];
            gpio_ib_mode_sel <= gpio_defaults[MOD_SEL];
        gpio_inenb <= gpio_defaults[INP_DIS];
        gpio_outenb <= gpio_defaults[OEB];
        gpio_dm <= gpio_defaults[DM+2:DM];
        gpio_ana_en <= gpio_defaults[AN_EN];
        gpio_ana_sel <= gpio_defaults[AN_SEL];
        gpio_ana_pol <= gpio_defaults[AN_POL];
    end else begin
        /* Load data */
        mgmt_ena         <= shift_register[MGMT_EN];
        gpio_outenb      <= shift_register[OEB];
        gpio_holdover    <= shift_register[HLDH]; 
        gpio_inenb       <= shift_register[INP_DIS];
        gpio_ib_mode_sel <= shift_register[MOD_SEL];
        gpio_ana_en      <= shift_register[AN_EN];
        gpio_ana_sel     <= shift_register[AN_SEL];
        gpio_ana_pol     <= shift_register[AN_POL];
        gpio_slow_sel    <= shift_register[SLOW];
        gpio_vtrip_sel   <= shift_register[TRIP];
        gpio_dm          <= shift_register[DM+2:DM];

    end
    end

It seems that it is always in reset mode because throughout the whole simulation it always took the values from the define file.

Reset to this block comes from power-on-reset, and as long as (!power-on-reset) (porb) is low, then none of the digital can run. It could remain in the state if it never received a serial load. You can check the

serial_load

signal in the

housekeeping

module. Check

serial_clock

to make sure that the serial programming has been triggered, and

serial_load

to make sure that the load signal was passed to the GPIO control block. If that didn't work, then you may have to look into the wishbone signaling to the housekeeping module.

the

signals serial_load

and

serial_clock have the value 0. On the other hand I don't know how to interpret the WB signals.

What of the WB signal i have to check?

This is way too soon in the simulation to see anything meaningful. It will take several hundred microseconds at least just to get through the startup code.

Thanks @Tim Edwards, everything works correctly, I gave it the same time as in the user example but that was not enough because I configured all the GPIO ports, once I gave the simulation more time the outputs started to work. Now, if i would like that always the GPIO ports are connected to the user are, i have to change the user_defines.v file on the <Git_repo>/carave/verilog/rtl/user_defines.v path or is enough with the modification of the <Git_repo>/verilog/rtl/user_defines.v file?

Modifying the

user_defines.v

in your user project repository only is sufficient. The file in your user project is the one that will be used for final chip assembly.

Hi @Tim Edwards, I hope you can help me with this, I am probably doing something wrong as in the last simulation. This time I am trying the GL simulation, I run the

gen_gpio_defaults.py

, as well as, add the

caravel_core

and the

gpio_defaults_block

. The problem occurs after several simulation times, the outps stop working and show an unknown value (

X

), and the strangest thing is that all the flash signals show a value

X

as well. What can generate this problem?

This actually looks like an error that I know about. . . In that scenario, what happens is that the VexRISC pre-fetches data from the flash. If the program runs all the way to the end then loops back into the program somewhere, then the VexRISC will pre-fetch data past the end of the program. The emulated flash is undefined in this area, and so reads back undefined values. The undefined values then infect the entire processor. Fortunately, it has a simple solution: Hand-edit the

.hex

file and add a full row of zeros at the end. That will be sufficient to prevent the pre-fetch cycle from corrupting the entire CPU.

Thank you, that worked.