Since you didn't identify any specific difficulties, here's a quick run-through. If there are points you still don't understand, ask followup questions in the comments below.
flipflops is used to create an edge detector; counter_set pulses high every time there's an input transition. (Note that this is poor design — since button is an asynchronous input, there should be at least one more flipflop to reduce the chance of metastability.)
Every time counter_set pulses high, counter_out is cleared; otherwise it counts up until the MSB gets set, at which time result is set to the same state as button.
As a demo, the code increments counter_10 on every debounced transition (both low-to-high and high-to-low), which then gets decoded for a 7-segment display. In place of this, you could toggle your LED. If you want the LED to only toggle on one edge and not the other, make it conditional on result.
Take the following VHDL design description:
library ieee;
use ieee.std_logic_1164.all;
entity bidir is
port (
Z : inout std_logic;
Y : out std_logic;
OE : in std_logic;
A : in std_logic
);
end;
architecture behave of bidir is
begin
Z <= A when OE = '1' else
'Z' when OE = '0' else
'X';
Z <= 'H'; -- pullup
Y <= TO_X01(Z);
end behave;
There are potentially three or more drivers for the net connected to the mode inout port Z. There are two local drivers - the two concurrent signal assigments one driving from port A depending on the output enable OE (and propagating unknowns), the other a pullup.
There can be some some number of external drivers on the net Z is connected to, potentially none. The value of that signal net is determined by a resolution function.
This introduces the distinction between the driven value from a driver and the effective value of signal net. The value of the signal net in an expression is the output of the resolution function, and not the nearest driver.
In a timed simulation, or in the case of the output enables of two of these buffers with the output enable being delivered on different delta cycles (a second signal for one of the output enables derived from the other by a signal assignment), there can be overlap between active drivers. You typically logically AND a chip select with the output enable to prevent overlapped enables on multiple drivers. If the driven values of the multiple drivers are different (e.g. one '1', the other '0') you'll see a resolution of 'X' during VHDL simulation for the overlap.
The pullup implies that the default value of the signal net is 'H' when there are no 'active' drivers providing strong values ('1' or '0'). You'd typically 'filter' the 'H' to a '1' by using a conversion function (e.g. TO_XO1) on the signal being used internally on the theory that un-driven signals floating in the switching region for an input buffer is a bad thing, potentially causing high transient current loads and potential latch up.
With std_logic there are two ways to insure a driver doesn't interfere with another driver. std_logic is a resolved type, using a resolution table to determine the effective value, taking two signals at a time (a result value and each driver in turn, the result initialized to 'Z.
constant resolution_table : stdlogic_table := (
-- ---------------------------------------------------------
-- | U X 0 1 Z W L H - | |
-- ---------------------------------------------------------
('U', 'U', 'U', 'U', 'U', 'U', 'U', 'U', 'U'), -- | U |
('U', 'X', 'X', 'X', 'X', 'X', 'X', 'X', 'X'), -- | X |
('U', 'X', '0', 'X', '0', '0', '0', '0', 'X'), -- | 0 |
('U', 'X', 'X', '1', '1', '1', '1', '1', 'X'), -- | 1 |
('U', 'X', '0', '1', 'Z', 'W', 'L', 'H', 'X'), -- | Z |
('U', 'X', '0', '1', 'W', 'W', 'W', 'W', 'X'), -- | W |
('U', 'X', '0', '1', 'L', 'W', 'L', 'W', 'X'), -- | L |
('U', 'X', '0', '1', 'H', 'W', 'W', 'H', 'X'), -- | H |
('U', 'X', 'X', 'X', 'X', 'X', 'X', 'X', 'X') -- | - |
);
The two axis of the resolution table are the two inputs. You might note that every intersection of 'Z' on one input results in the unchanged value of the other input. 'Z' is a safe value.
Specifying a 'Z' output for an 'inactive' driver is the correct thing to do for a pure behavioral model.
A structural model can use a disconnection specification on a guarded signal, specifying how long after an event a signal is driven. When it's not driven (disconnected) it's not involved in resolution.
Without disconnecting a driver the only way to have a driver uninvolved in the resolution value for a multi driver net is to drive it to 'Z'.
Best Answer
As FPGAs* do NOT support on-chip tri-state drivers you can not implement option-1 on them.
You should go for the MUX version.
*At least I don't know any FPGA of reasonable size which still has them.