Hi, I have some questions. If anyone can guide me. Our chip had three projects. Two were analog and one was digital. I planned to test digital first. Before going to test digital project, there was an inverter specially placed in my digital project to test it first and conclude the user silicon is working fine other than management SoC. The output of inverter was physically connected to io[0] and input to io[8]. I had installed riscv toolchain correctly on Linux and I am able to control D3 LED through gpio_test.c. I had observed the correct delay of LED blinking as per my updated code. Hence, I configured user io registers as IO[0} = GPIO_MODE_USER_STD_OUTPUT and IO[8} = GPIO_MODE_USER_STD_INPUT_NOPULL. I am not getting the results. What could be the possible reason, other than the silicon design mistakes, I am not getting my results? is it padframe? vdd supplies? or any other thing that I am missing?

io[0]is a special one, related to the flash if I recall. I'd recommend leaving the first 7 ios if you can

@Matt Venn: No, what you're thinking of is the housekeeping SPI, but those are GPIO[1] to GPIO[4]. GPIO[0] is connected to a debug function for the VexRISC CPU. In normal operation, GPIO[0] does not interfere with the CPU operation (I just checked to confirm).

there's a ton of traces, but you should also be able to follow the signal through the vcd file with gtkwave

When using user output, be sure to set

io_oeb[0]

to low. If you haven’t connected io_oeb to a gpio, you may not be able to see any external changes.

@Mitch Bailey Are you talking about bit 1 or last 3 bits of configuration in this picture below?

The

gpio_control_block

takes the

gpio_defaults_block

output and the connections to the user area and management area and creates the actual connections to the gpio.

caravel/verilog/rtl/gpio_control_block.v

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;

@Muhammad Farid Ud Din: In the 2nd picture above, the registers

reg_gpio_*

refer to the management GPIO, a single GPIO that is only accessible by the management CPU and which is not accessible to the user project. On the development board, this GPIO connects to the LED for diagnostic purposes. The GPIO[0] is connected to the VexRISC debug enable, but it can also be used by the user project, and it can also be used by the management CPU as a simple GPIO signal. As Mitch indicated, the OEB input to the pad comes from the gpio_control_block module, but that is flattened into the SoC layout. If GPIO[0] is configured for use by the user project, then it ultimately connects to the user project.

@Muhammad Farid Ud Din the

io_oeb

pin must be connected to a low signal for user output. I think there is a workaround for everything (input, analog) else.

Thanks for quick reply. I understood.