Shrike-Lite FPGA: All FPGA GPIOs except F17 and F18 cannot be used as inputs

General
1

Hi Team,

I’m working with the Shrike-Lite development board (RP2040 + SLG47910 FPGA) and have encountered an issue with the FPGA GPIO pins.

I can successfully synthesize my design and generate the bitstream without any errors. The design programs correctly, and all FPGA GPIO pins work as outputs. However, at runtime, only FPGA GPIO F17 and F18 function correctly as inputs.

All other FPGA GPIO pins (F0–F16) do not work as inputs, even though the design synthesizes successfully and the bitstream is generated without any errors.

To verify this, I tested the same Verilog design by assigning the input to different FPGA GPIO pins. The input is detected correctly only on F17 and F18. The remaining GPIO pins never detect input changes.

Could you please confirm:

  1. Is this a known or expected limitation of the Shrike-Lite board?
  2. Why are only F17 and F18 usable as inputs?
  3. Is this behavior due to the board-level routing, IO Planner configuration, or an SLG47910 FPGA restriction?
  4. Is there any configuration or workaround that allows F0–F16 to be used as input or bidirectional GPIOs?

Toolchain: ForgeFPGA Workshop / Verilog

Thank you for your support.

Best regards,
Dharmendra A. Chauhan

2

Hello @DharmendraChauhan,

There is no any issue as you are mentioning for the shrike-lite, The FPGA GPIO’s can be used as inputs or outputs based on the configurations that we configure.

If you share the project that you trying to do and getting this issue, we might go through the project and will let you know what you are missing.

1 Like
3

Hello @UpendraReddy

Thanks for reply!
Please check the uploaded file.

notgate.zip (163.1 KB)

4

Hello, @DharmendraChauhan

In your design you have two modules, one is main.v and the other is macrocellmode_autogen.v in both modules you add the top attribute, which is not a good practice. By default the tool is considering the main.v as a top module and removing the other module while synthesizing.

In your main.v you are trying to implement the not gate and it is working when I checked from my side.
When I check from my side I use the GPIO16 (led pin of fpga) as a output to observe. In this, I observe that, when input pin- GPIO1 is floating the LED is off and while I connect the input with Ground LED is glowing and if I connect with 3.3v input, LED is off again, which is implementing the not gate behaviour correctly.

Can I know how did you confirm that you are not getting any output on that pin?? And how did you give input??

1 Like
5

Hi, @UpendraReddy

Thank you for checking the design and for pointing out the issue with having the top attribute in both modules. I understand that only main.v should be marked as the top module, and that the other module may be optimized away during synthesis.

Regarding the testing, I used GPIO F17 and F18 as the input pins and GPIO16 (LED) as the output. After programming the FPGA, I observed that the LED was already ON even when F17/F18 were left unconnected (floating). When I connected F17/F18 to 3.3 V, the LED turned OFF.

For the other GPIO input pins I tested previously, I only drove them with 3.3 V and did not explicitly connect them to GND. Based on your explanation, I realize that leaving an input floating is not a valid logic level and can produce unexpected behavior. I will repeat the test by explicitly driving the input to both GND and 3.3 V and will confirm whether the design works correctly.

Thank you for your guidance.
Dharmendra A. Chauhan

6

Yes, Whenever the input is floating, it should be anything it’s basically invalid, So we can ignore that case.
We have to give valid input and have to observe the output. You can check with any other GPIO’s by giving valid inputs, every GPIO will work.

1 Like
7

I will check and confirm whether the design works correctly.

Again thank you!
Dharmendra A. Chauhan

8

Hi,

I checked it and it’s working correctly now. When valid inputs are applied, the GPIO responds as expected. The floating input case can be ignored since it’s considered an invalid input condition.

I also verified with other GPIOs using valid inputs, and they are working properly as well.

Thanks for the clarification.

1 Like