https://open-source-silicon.dev logo
Channels
aa
abcc
activity
adiabatonauts
analog-design
announce
announcements
b2aws
b2aws-tutorial
bag
basebands
beagleboard
bluetooth
board-respin
cadence-genus
cadence-innovus
cadence-spectre
cadence-virtuoso
caravan
caravel
caravel-board
chilechipmakers
chip-yard
chipignite
chipignite2206q_stanford_bringup
chisel
coalition-for-digital-environmental-sustainability
community_denmark_dtu
containers
courses
design-review
design-services
dffram
digital-design
digital-electronics-learners
discord-mods
dynamic-power-estimation
efabless
electric
events
fasoc
fault
foss-asic-tools
fossee-iitb-esim
fossee-iitb-google-sky130
fpga
funding
fuserisc
general
generative-ai-silicon-challenge
genius-vlsi
gf180
gf180mcu
hardware-beginners
help-
ieee-sscs-cac-23
ieee-sscs-dc-21q3
ieee-sscs-dc-22
ieee-sscs-dc-23
ihp-sg13g2
images
infiniband
j-core
japan-region
junk
klayout
latam_vlsi
layouteditor
lvs
lvs-analysis
magic
magical
maker-projects
maker-zone
microwatt
mpw-2-silicon
mpw-one-clean-short
mpw-one-silicon
neuro-mem
nydesign
open_pdks
open-pdk
openadiabaticlogic
openfpga
openhighqualityresonators
openlane
openlane_cloudrunner
openlane-development
openocd
openpositarithmetic
openpower
openram
openroad
opentitan
osu
pa-test-chip
paracells
pd-openlane-and-sky130
picosoc
pll
popy_neel
power
private-shuttle
rad-lab-silicon
radio
rdircd
reram
researchers
rf-mmw-design
rios
riscv
sdram
serdes
shuttle
shuttle-precheck
shuttle-status
silicon-photonics
silicon-validation
silicon-validation-private
sky130
sky130-ci
sky130-pv-workshop
sky65
sky90
skywater
sram
stdcelllib
strive
swerv
system-verilog-learners
tapeout-job
tapeout-pakistan
team-awesome
timing-closure
toysram
travis-ci
uvm-learners
vendor-synopsys
venn
verification-be
verification-fe
verilog-learners
vh2v
vhdl
vhdl-learners
vliw
vlsi_verilog_using_opensource_eda
vlsi_verilog_using_opensoure_eda
vlsi-learners-group
vlsi101
waveform-viewers
xls
xschem
xyce
zettascale
Powered by
Title
k

Kavya Sreedhar

02/28/2023, 7:43 PM
Hi everyone, to run gpio_test, do we need to run
make flash_nucleo
and then
make sim
(https://github.com/efabless/caravel_board/blob/main/firmware_vex/gpio_test/Makefile)? The diagonstic steps are working for me (https://github.com/efabless/caravel_board/blob/main/firmware_vex/nucleo/README.md).
t

Tim Edwards

02/28/2023, 8:58 PM
make check
is more meaningful than `make sim`; the former is just the final line of output for the latter and shows what configuration ended up in the registers after programming, based on the calibration results (
make sim
shows every single step of the data shifting into the registers, which is more information than you really need). Neither one depends on the program being flashed. Once you do
make flash_nucleo
, the board should get reset and you should see all the GPIOs toggling (which you can test with an oscilloscope or frequency counter---somebody should write a simple program that allows the Nucleo to read each GPIO pin and confirm whether or not it's toggling). If not all GPIOs are toggling, then the points of failure should match what's reported by
make sim
.
k

Kavya Sreedhar

02/28/2023, 11:31 PM
I was able to run
make check
which looks okay, but I get the below error with
make flash_nucleo
.
(caravel) kavya@Kavyas-MacBook-Pro gpio_test % make check
python3 ../gpio_config/gpio_config_checker.py
PASS: Low gpio matches.
PASS: High gpio matches.
(caravel) kavya@Kavyas-MacBook-Pro gpio_test % make flash_nucleo
/usr/local/bin/riscv64-unknown-elf-gcc -I/Users/kavya/Desktop/Kavya/sky130_xgcd_bringup/caravel_board/firmware_vex/gpio_test -I../ -I../generated/ -O0 -mabi=ilp32 -march=rv32i -D__vexriscv__ -Wl,-Bstatic,-T,../sections.lds,--strip-debug -ffreestanding -nostdlib -o gpio_test.elf ../crt0_vex.S ../isr.c gpio_test.c
make: /usr/local/bin/riscv64-unknown-elf-gcc: No such file or directory
make: *** [gpio_test.elf] Error 1
@Tim Edwards do you know what might be causing this error? thanks for the help!
p

proppy

03/01/2023, 1:55 AM
You have to have a risc-v toolchain installed.
đź‘Ť 1
We need to make those requirements clearer https://github.com/efabless/caravel_board/issues/37
k

Kavya Sreedhar

03/01/2023, 3:59 AM
awesome, thanks!
I ended up installing it and it got past that issue
thanks for the explanation above @Tim Edwards I see the GPIOs toggling!
p

proppy

03/01/2023, 4:02 AM
@Kavya Sreedhar can you comment on the issue on what toolchain you installed?
It will be helpful for other stumbling on the same issue
k

Kavya Sreedhar

03/01/2023, 4:03 AM
yes, I had to do the following on MacOS Ventura
brew tap riscv-software-src/riscv
brew install riscv-tools
I ran into this issue:
Error: Your Command Line Tools are too outdated
on the brew install step
^ I followed this link to get past that error and then
brew install riscv-tools
worked
p

proppy

03/01/2023, 4:15 AM
Awesome! do you want to add this to the issue? That's would be a good contribution for other that are on macosx.
k

Kavya Sreedhar

03/01/2023, 4:15 AM
Sounds good!
đź‘Ť 1
also, when we modify gpio_test for our own tests, do we need to ensure gpio_test.c matches with gpio_config_io.py?
so if
reg_mprj_io_27 = GPIO_MODE_USER_STD_INPUT_PULLDOWN;
in gpio_test.c then I would want to make sure the 27th config is
C_USER_BIDIR_WPD
in gpio_config_io.py?
@Tim Edwards @proppy if so, what does
GPIO_MODE_USER_STD_ANALOG
in gpio_test.c correspond to in gpio_config_io.py? the possibilities I see are below, but I’m not sure which one fits
C_USER_OUT = 0
C_MGMT_IN = 1
C_USER_BIDIR = 2
C_DISABLE = 3
C_ALL_ONES = 4
C_USER_BIDIR_WPU = 5
C_USER_BIDIR_WPD = 6
C_USER_IN_NOPULL = 7
C_USER_OUT = 8
and are the below pairings correct?
GPIO_MODE_USER_STD_OUTPUT -> C_USER_OUT
GPIO_MODE_USER_STD_INPUT_PULLDOWN -> C_USER_BIDIR_WPD
it seems like that isn’t quite enough because I get this error when I try to modify gpio_test to use user modes instead of management…any ideas what might be going wrong? @Tim Edwards @proppy
python3 ../gpio_config/gpio_config_checker.py
PASS: Low gpio matches.
FAIL: *** High gpio does not match ***
   0:     : ____IO[37]___ I___IO[36]___ I___IO[35]___ I___IO[34]___ I___IO[33]___ I___IO[32]___ I___IO[31]___ I___IO[30]___ I___IO[29]___ I___IO[28]___ I___IO[27]___ D___IO[26]___ I___IO[25]___ I___IO[24]___ I___IO[23]___ I___IO[22]___ D___IO[21]___ I___IO[20]___ I___IO[19]___ 
0110000000000 0110000000000 0110000000000 0110000000000 0110000000000 0110000000000 0110000000000 1100000000000 0110000000001 0110000000000 0110000000000 0110000000000 0110000000000 0110000000000 0110000000000 0110000000000 0110000000000 0110000000000 0110000000000
this is with
make check
Also, do we also need to modify gpio_config_data.py when we modify the gpio_test? thanks for all the help!
t

Tim Edwards

03/01/2023, 3:45 PM
Sorry for the late reply---time zone differences. So when you see
reg_mprj_io_27 = GPIO_MODE_USER_STD_INPUT_PULLDOWN;
in the C code: The configuration ends up being held in two places. One is in the housekeeping module, and one is near the GPIO pad. The serial loader is what gets it from the housekeeping to the pad; however, in our code, we're bypassing the serial loader and bit-banging the data into the serial chain directly. The value
reg_mprj_io_27
is the register address in housekeeping. It is important for only one reason: The housekeeping looks at bit 3 (input disable) to determine which direction the single-wire interface between housekeeping (management) and GPIO goes. If INP_DIS = 1, then the management SoC drives the wire; if INP_DIS = 0, then the GPIO drives the wire. So the value in the register doesn't matter much but you want to make sure that the management SoC and the GPIO are not both trying to drive the data wire at the same time. The simplest thing to do is to just set each GPIO channel to an input mode or output mode, depending on what the GPIO is supposed to be doing. If the GPIO is being used by the user project, then set the channel to an input. I would suggest setting
GPIO_MODE_MGMT_STD_INPUT_NOPULL
for all channels being used by the user project. The
gpio_config_def.py
file will be created once by the calibration process and should not be changed except when changing the chip under test. Our policy has been to copy the file to a name indicating which chip it is for, like
gpio_config_def_F1_7.py
, and then making
gpio_config_def.py
a symbolic link to the one corresponding to the chip currently being programmed and tested. The
gpio_config_io.py
file is what needs to be changed to match what you want the GPIOs to be doing in your C program. The builder then generates the
gpio_config_data.py
file (and the corresponding C file) which contains the bit stream definition. Don't change
gpio_config_io.py
without re-running the build process, so that
gpio_config_data.py
is always in sync with
gpio_config_io.py
. Otherwise the checker will give wrong results. I hope that answers your questions!
k

Kavya Sreedhar

03/01/2023, 3:52 PM
Thank you so much for the explanation, this greatly clarifies things! Just to double check, then
GPIO_MODE_MGMT_STD_INPUT_NOPULL
should be used for user io_in, io_out, and analog_io and we set io_oeb appropriately to choose between io_in and io_out? And if we are using analog_io[i], then it doesn’t matter what io_oeb[i] is set to?
t

Tim Edwards

03/01/2023, 3:57 PM
All of that is correct, yes. For analog I/O, the output mode is set to
000
which turns the output buffer (and also the input buffer) off completely, regardless of the state of OEB.
k

Kavya Sreedhar

03/01/2023, 3:59 PM
Sounds good! How do we actually indicate that we are using an analog I/O pad then?
t

Tim Edwards

03/01/2023, 5:05 PM
@Kavya Sreedhar: Any channel that you are connecting an analog signal to should be set to
C_DISABLE
in the configuration file and
GPIO_MODE_USER_STD_ANALOG
in the C file configuration.
k

Kavya Sreedhar

03/02/2023, 12:41 AM
awesome, thank you! I was missing the C_DISABLE. I will try that.
@Tim Edwards just to follow up, for
GPIO_MODE_MGMT_STD_INPUT_NOPULL
in the C file, should we be using
C_MGMT_IN
in the python file?
It looks like the input configurations are good now for user I/O, but I still get “High gpio does not match” when I try to use an analog_io configuration with
GPIO_MODE_USER_STD_ANALOG
in the C code and
C_DISABLE
in the Python code. (If I set that to an input and input_nopull that gpio is fine so it seems to be this configuration that causes problem with
make check
)
oddly enough, if I change the Python config to
C_MGMT_IN
or
C_MGMT_OUT
with
GPIO_MODE_USER_STD_ANALOG
and then run
make gpio_config_data.c
and then
make check
, it passes (but
C_DISABLE
fails)…it doesn’t sound like
C_MGMT_IN
or
C_MGMT_OUT
is the right thing to do though
one other follow up…I saw above that we should use
GPIO_MODE_MGMT_STD_INPUT_NOPULL
for user project I/Os…I just wanted to make sure that should say
MGMT
and not
USER
(
GPIO_MODE_MGMT_STD_INPUT_NOPULL
vs
GPIO_MODE_USER_STD_INPUT_NOPULL
)?
a

Ayushman Tripathi

03/03/2023, 2:35 AM
@Tim Edwards I have also tried with C_DISABLE and GPIO_MODE_USER_STD_ANALOG. For me also make check fails for High_GPIO.. Make check passes for GPIO_MODE_MGMT_STD_INPUT_NOPULL and C_MGMT_IN. My analog outputs were not coming correctly in both cases.
Also, I wanted to confirm if I want to read out analog signals from my chip, should I configure my IOs and .c files as C_DISABLE, GPIO_MODE_USER_STD_ANALOG or should I keep it as C_MGMT_IN and GPIO_MODE_MGMT_STD_INPUT_NOPULL
t

Tim Edwards

03/03/2023, 2:58 PM
If you have any analog signal connected to an
analog_io
pin on a GPIO, you want to keep both the (digital) input and output buffers turned off. The output buffer is the most critical because it will interfere with your analog signal. The input buffer will draw crowbar current if your analog signal is mid-range. So both of your configurations above will work, but the first one is better. Also, if you have the Nucleo board connected, make sure that the Nucleo board pins aren't interfering with the signals.
Otherwise, we'll probably need to dig down into the user project schematic and figure out how the pad signal is being driven, and what might interfere with the ability to read the value from it. As I was telling Kavya yesterday, if you know what the bits are in the configuration, you can figure out from the
make check
result whether or not you care if it fails. For example, in analog mode you want the first three bits (the output mode) to be
000
, which turns off all digital buffers. If that's true, then the rest of the configuration bits are all don't-cares. If
make check
reports that the analog channel "fails" because it was specified as "user analog" and the management mode bit got set, then that's an error that can be ignored. Likewise, if the failures occur in channels you aren't using, then you can ignore them.
a

Ayushman Tripathi

03/06/2023, 7:14 PM
@Tim Edwards Thanks for the reply. For GPIO_MODE_USER_ANALOG_STD_PROJECT and C_DISABLE case, using make check I found that GPIO 24, doesn't have its 3LSBs as 000. Consequently, on logic analyzer it outputs 3.3V while all other analog IO pins are at 0V. expected output from rest of the analog output pins is between 1.4V~1.8 V.
t

Tim Edwards

03/06/2023, 7:32 PM
@Ayushman Tripathi: For the screenshot you show, GPIO 24 has the low bit set, which should be fine (that is, you should be able to ignore the error) because as long as the three highest bits are
000
, then the pad is disabled (both input and output digital buffers are turned off), and the state of the lowest (management enable) bit has no effect on the GPIO function at all.
p

Praveen raj

03/11/2023, 3:24 PM
@Tim Edwards @Kavya Sreedhar, Thanks for this thread, it greatly helped me to make the GPIO analog pins work!