I am using a Lattice ECP5U FPGA (lfe5u-25f-6BG256). I am using Diamond Lattice software with the included Synplify synthesizer. I am writing a code to toggle every single pin (or most of them) on an FPGA. The practical reason I need this for is reverse engineering an unknown board, and first I need to find out which pin is connected to the clock source. My idea is to change the clock inputs (there are ~30 possible clock pins on this device) until I find the one where the pins start toggling. (There are other ways to find the clock source, like desoldering the chip and trying to figure out the routing). The question however is not how to reverse engineer a board but a specific technical issue I am having with the FPGA which I would like to know the reason for, so please bear with me. I use the following code to toggle every pin:

library IEEE;

package pads_package is 
    constant c_register_width : NATURAL := 32;
    type t_pads is array(0 to c_register_width - 1)of STD_LOGIC;    
end pads_package;

library IEEE;
library ecp5u;
use ecp5u.components.all;
use pads_package.ALL;
use IEEE.math_real.all;

entity top is
        i_clk : IN STD_LOGIC;
        pads : INOUT t_pads := (others => '1')

end top;

architecture Behavioral of top is

    signal s_counter : STD_LOGIC_VECTOR(7 downto 0) := (others => '1');
    signal s_push_counter : NATURAL range 0 to 1 := 0;
    signal s_output : STD_LOGIC_VECTOR(0 to c_register_width - 1) := (0 => '1', others => '0');
    for j in 0 to c_register_width - 1 generate
        pads(j) <= s_output(j);
    end generate GEN_IO; 
    p_test : process(i_clk)
        if rising_edge(i_clk) then
            if s_counter(s_counter'HIGH) = '1' then
                for i in 1 to c_register_width - 1 loop
                    s_output(i) <= s_output(i - 1);
                end loop;
                if s_push_counter = 1 then
                    s_push_counter <= 0;
                    s_output(0) <= '1';
                    s_push_counter <= s_push_counter + 1;
                    s_output(0) <= '0';                 
                end if;
            s_counter <= "01000000";
                s_counter <= std_logic_vector( unsigned(s_counter) - 1);
            end if;         
        end if;
    end process;
end Behavioral;

Package pads_package includes a constant c_register_width which is used to set the width of a shift register later in the code and t_pads is just a custom array type for the IO pins. I am implementing a shift register (s_output, 32 bit-wide in this case, so I intend to toggle 32 pins at once) and connecting it directly to the output pins "pads". I also implement a counter (s_counter) to divide the clock by 64. The counter is decreased by '1' each clock cycle and when it reaches -1, or when s_counter(s_counter'HIGH) = '1', it gets reset to 64, or "01000000".

Each time the counter resets it pushes either '1' or '0' into the shift register, which is regulated by s_push_counter. The shift register is then directly tied to IO pins. Here's how it looks in the schematic. enter image description here

And here's the testbench output, which acts exactly as I want: enter image description here

As you see all of the pins are being toggled.

Here's the Place and Route Trace report that the Diamond software provides: enter image description here

The clock on my board is 50MHz, which I have set as the timing preference and the max frequency that the design is capable of running at is >200MHz, which is plenty.

All in all the code, and the functionality is pretty simple, and when I upload the bit file to the device everything works as expected.

The issue arises when I increase the c_register_width, in other words when I want to toggle more pins. At 64 pins code works normally, however when I try to toggle 128 pins at once, everything seems fine in the software, but on the board the pins don't toggle at all. The testbench seems fine, the schematic view has the same topology as above, just with 128 bit wide registers, and the timing analysis gives 98 MHz as max frequency, which should still be enough.

I have encountered the same behavior before, when I wanted to control many pins at once but I didn't find a solution back then. I assume there is something fundamental I don't understand about this FPGA, or maybe digital design as a whole, which why I am posting here. I understand that the "wider" the logic is bit-wise the more timing issues there may be, but the software doesn't report anything as being problematic, so I am not satisfied by this explanation. Is there anything that may cause this kind of behavior?

Power Consumption

I did the power consumption calculation as suggested in the comments and the tool gives 37 mA current draw with all of the 196 pins running. I don't think power consumption is the reason here.


As Mitu Raj suggested I've checked the DIO PRC report and there were some issues when outputting to 196 pins, however no issues when outputting to only 128 pins. In the first case there is a voltage mismatch error. This is caused by some of the pins being used as JTAG pins and me having a 1.8V constraint. I've set this constraint because otherwise the clock wasn't registering and later forgot about it. But I don't think this is the cause for the issue as the config with the 128 pins mapped didn't produce these errors (as there are no dedicated JTAG pins used) and the hardware is still not behaving as expected.

Possibility of gated clocks

I've noticed a warning message that I missed before: Found inferred clock top|i_clk which controls 137 sequential elements including s_push_counter[0]. This clock has no specified timing constraint which may prevent conversion of gated or generated clocks and may adversely impact design performance.

I thought I gave the constraint in this window: enter image description here

Although as I understand now the software did not tie this constraint to i_clk signal specifically. I'm not sure if this can cause what I'm seeing but I'll try to apply the constraint to this signal specifically.

  • \$\begingroup\$ What kind of behavior do you refer to? I don't see any problem - you give a constraint and it is met. \$\endgroup\$
    – asdfex
    May 6, 2021 at 10:54
  • \$\begingroup\$ The pins were not toggling at all when trying to output to 128 pins at once. The software is not indicating any issues but the hardware doesn't behave accordingly. \$\endgroup\$ May 6, 2021 at 11:04
  • \$\begingroup\$ I put the issue part in bold. \$\endgroup\$ May 6, 2021 at 11:05
  • 1
    \$\begingroup\$ Did the power calculation and updated the question. \$\endgroup\$ May 6, 2021 at 11:58
  • 1
    \$\begingroup\$ Let us continue this discussion in chat. \$\endgroup\$
    – Mitu Raj
    May 6, 2021 at 12:37

1 Answer 1


The solution to the problem came down to reducing the drive strength on every pin from 8 down to 4 (Lattice diamond values, not sure what they represent in real life). I am not sure why PIO DRC (suggested by Mitu Raj) did not spot an issue if the current consumption was too high, I may have not set it up properly. If anyone has a better explanation on this, since we already know how the problem was solved, I will be happy to accept your answer.

  • 3
    \$\begingroup\$ They represent the output impedance on these IO pins. Smaller values mean higher resistances, which will limit the current sourcing/sinking. Sorry, I am late by a year :D \$\endgroup\$
    – Mitu Raj
    Aug 5, 2022 at 8:51
  • 1
    \$\begingroup\$ Haha, thanks Mitu. Yeah I understand that but it's unclear what the actual values are in Ohms, or max mA. It's probably listed somewhere in a datasheet but I don't care enough at this point to check :D \$\endgroup\$ Dec 5, 2022 at 22:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.