2
\$\begingroup\$

I have a board that uses a Lattice XP2-8 (BGA256, in case it makes any difference).

Some FPGA pins are connected directly to LEDs with positive logic. That is:

schematic

simulate this circuit – Schematic created using CircuitLab

At power-up, the LED goes super-bright for a tiny fraction of a second (very very short, but very very obvious).

This is already in a PCB, manufactured and populated, etc., so I cannot change the circuit. I tried configuring the pin (in Lattice Diamond, spreadsheet view) to pull-down, but it made no difference.

My question is: is there anything that I can do at the HDL or LatticeDiamond level that would allow me to get around this? (basically, I need to avoid the LED to be ON until the FPGA is configured and operating)

\$\endgroup\$
7
  • 2
    \$\begingroup\$ I've not used them, but isn't there a specification in the datasheet with respect to holding the I/O pin driver circuitry in a high impedance state during POR and then during initial boot/configuration of the device? I don't want to take the time to haul through them myself. But is that kind of information missing? (I was of course tempted to just say, when using Lattice just ground all the pins to be safe. But of course I then decided not to write any of that. ;) \$\endgroup\$ Commented Nov 5, 2021 at 1:00
  • 4
    \$\begingroup\$ At what stage are the outputs going high? Power up, during config or when your logic is running? Load up a bitstream that has the pins uncommitted or as inputs. See what happens. If there!s no flash, then that suggests it might be your logic. \$\endgroup\$ Commented Nov 5, 2021 at 1:03
  • 1
    \$\begingroup\$ Usually power up sequencing sends IOs of FPGA to high impedance. \$\endgroup\$ Commented Nov 5, 2021 at 5:20
  • 1
    \$\begingroup\$ I don't know Lattice but there is some often some flag at the start of configuration bitstream that say how to handle unused IOs (some part can use these as extra grounds for example). But before the start of load you can't really do anything, the real fix is to the hardware. \$\endgroup\$ Commented Nov 5, 2021 at 6:51
  • 1
    \$\begingroup\$ @Cal-linux Do you see that oversight now as a mistake? Can that be used during configuration, and perhaps just a little longer -- long enough for internal equilibrium to complete, to solve the current problem? If so, then there was a mechanism available. It just wasn't used. Is that about the summary of it? (Aside from the fact that there's no doc on I/O pin state during configuration.) \$\endgroup\$ Commented Nov 5, 2021 at 13:25

1 Answer 1

Reset to default
2
\$\begingroup\$

Change the design to make the LED pin an I/O with tri-state, then use a delayed clock to enable the output mode after some time. The idea is to make the pin an input immediately after configuration, then after a small time switch the pin to output mode.

Do not allow the synthesizer optimize away the input from the LED pin (making it just an output pin), maybe connect it to an unused pin. To create the delay, just create a counter that increments on your system clock.

\$\endgroup\$
1
  • 1
    \$\begingroup\$ This works, yes, although it seems like in this particular case it wasn't necessary; just assigning the LED port to a reg, instead of to a logic expression, that eliminated the problem. I did resort to the tri-state bidirectional pin for a different LED that was also giving me a hard time. \$\endgroup\$ Commented Nov 8, 2021 at 16:31

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.