GPIO input interrupt

[biosbob]

while i can associate GPIO_I[0] with (say) a button on my icebreaker board, i can't find a mechanism for detecting a change of value (1 => 0 when pressed) -- except by continuously polling....

said another way, how can i receive a CPU interrupt on the rising- and/or falling-edge of some GPIO????

my domain-of-interest are "sleepy SoCs", which spend most of their time in a low-power state awaiting some external event.... while timers are often used here, input GPIOs provide a (better) way to awaken the CPU "immediately".... and no, i don't want to tie my GPIO to reset!!!!

[stnolting]

The GPIO module does not provide any interrupt features at all. However, you can connect your buttons also to the External Interrupt Controller (XIRQ) to add individual interrupt capabilities.

[biosbob]

that makes sense, but it then raises another question.... suppose i want to take an interrupt on the falling edge of the button press (a 1
=> 0 transition); no problem using the XIRQ module.... but assume i ALSO want to the track the state of the button -- treating it now as a GPIO_I pin.... this is helpful when "de-glitching" a button press as well as when distinquishing a "short" from "long" press....

is it possible in my (icebreaker) constraints file to have the same physical button associated with two DIFFERENT pins???? i recall having problems with this in the past....

[stnolting]

You can do both: state-checking via the GPIO controller and interrupt detection via the XIRQ by connecting your input pin to both modules internally:

input_pin -----+-----> XIRQ(0)
               |
               +-----> GPIO.in(0)

[biosbob]

works just fine -- though this is quite different from almost every MCU (risc-v or otherwise) i've seen.... perhaps i'm still getting used to FPGAs versus ASICs; the "hard" nature of the latter forces software to configure an individual GPIO (input, pullup, edge-triggered, etc) at runtime....

in the general case with ASICs, each GPIO cannot only serve as an input or output pin but i can also have an "alternative" function such as UART_TX or SPI_CLK.... but if your final target is in fact an FPGA, then by all means we should specializing the function of each pin....

given my interest in "minimalist" silicon, however, this approach certainly has merits if a downstream ASIC is lower-cost, lower-power (all other things being equal)....

[stnolting]

A "real ASIC" might have some kind of software-programmable crossbar switch to arbitrarily connect the module's interface signals to physical pins. Luckily, we do not need something like this in a FPGA 😉