Caravel user project is failing GL test of io_ports if I comment out the gpio 5-7 configurations in the .c file and give them default values in the user_defines.v. Is this a bug?

Note that

USER_CONFIG_GPIO__XX__INIT

is only used in the RTL, where the module of

gpio_defaults_block

can be parameterized. But the module is a hardened macro, so the gate-level netlist can't be parameterized. There has to be a separate netlist for each block that has a unique defaults setting. The script that applies the defaults creates new gate level netlists, one for each configuration, with names like

gpio_defaults_block_1803

, with the hex name of the configuration code suffixed to the name. Without running that script, the gate level netlist has only

gpio_defaults_block

(for everything except the first five GPIOs, which cannot have their defaults changed), and

gpio_defaults_block

defaults to a configuration word of all zeros, which turns off both the input and output buffers and leaves the GPIO in a high-impedence state. So the GPIOs cannot be simulated in gate level netlist without first running the script (

scripts/gen_gpio_defaults.py

). All that being said, the C code you posted is another problem altogether. The configuration triggered with

reg_mprj_xfer = 1

has nothing to do with the power-on defaults in

user_defines.v

. By triggering the load, you are automatically overriding the power-on reset state with the configuration saved in the

reg_mprj_io__XX_

registers. Because you commented out those lines, the registers take their default values, which are in the housekeeping module, not in

user_defines.v

. Ideally they should be the same, but the two sets of values are held in places far away from each other (one near the pin, the other in the housekeeping module). So they remain two independent sets of values. The housekeeping module defines the default value to be a management-controlled input (see

housekeeping.v

line 1094 in the sky130 version of caravel), so if you don't set the register values in your C code, that's what they will be. The underlying rule here is that you either (1) use the default values from

user_defines.v

and don't trigger the configuration serial load, or (2) you set all the register values to the configurations you want, and then trigger the configuration serial load.

Hi , absolute novice query: I’m trying to clone the caravel_user_project using git clone command and I see an error that git not found. Are there any documentation on instructions about pre-requisites that I could follow along for setting up the Galaxy terminal ? I tried to install git but don’t have super user privileges .

@Tim Edwards I used the script to generate the default power up values for GL netlist. However, still the caravel io pads are not being initialized correctly. This is how I define io[11] to be user output in user_defines.v

`define USER_CONFIG_GPIO_11_INIT `GPIO_MODE_USER_STD_OUTPUT

The C file is just

#include <defs.h>
#include <stub.c>
void main()
{
	reg_spi_enable = 1;
}

Our design is correctly producing output on io[11] as shown in the waveform below but the caravel io pad [11] remains

z

any ideas?

I'd have to see the gate level netlists, but assuming the script has created a file

gpio_defaults_block_1808

and the gate level netlist for caravel is instantiating it for GPIO 11, and your project holds the OEB pin low on the pad interface and drives the output low, then it should work in simulation.

Okay yes it works now. I had to move the new caravel netlist file generated by the script in the relevant folder and also include it and the other gpio_defaults blocks in the include files inside mgmt core wrapper. Thanks! I wish this was documented somewhere, could have saved some days