Design does not fit ispLEVER - vhdl

Question

Hi I am trying to create a .jed file from a vhdl file through ispLEVER the problem appears when I try to create the fuse map and a port of 1 bit named le can´t be assigned to pin 23 (The GAL22V10-15LP has 24 pins)
Here is my vhdl code
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
entity alarm is port (
clk: IN std_logic;
le : OUT std_logic;
a: IN std_logic_vector(3 downto 0);
b: IN std_logic_vector(3 downto 0);
x: OUT std_logic_vector(1 downto 0));
end alarm;
architecture arch_alarm of alarm is
type states is (state0, state1, state2, state3 );
signal stado_pres, stado_fut: states;
begin
p_estados: process(stado_pres,a,b) begin
case stado_pres is
when state0 =>
x <= "00";
le <= '0';
if a = NOT(b) then
stado_fut <= state1;
else
stado_fut <= state0;
end if;
when state1 =>
x <= "01";
if a = NOT(b) then
stado_fut <= state2;
else
stado_fut <= state0;
end if;
when state2 =>
x <= "10";
if a = NOT(b) then
stado_fut <= state3;
else
stado_fut <= state0;
end if;
when state3 =>
x <= "11";
if a = NOT(b) then
le <= '1';
end if;
stado_fut <= state0;
end case;
end process p_estados;
p_reloj: process(clk) begin
if(clk'event and clk= '1') then
stado_pres <= stado_fut;
end if;
end process p_reloj;
end arch_alarm;
And the error that appears is :
Input file: 'untitled.tt2'
Device 'p22v10g'
Note 4068: Signal le cannot be assigned (to pin 23) because
the register type of 'le' pin 23 is invalid.
Design does NOT fit
FIT complete. Time: 1 second.
Done: failed with exit code: 0001
EDIT
I have added the le to all states but now it shows me another error
Here is the code
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
use work.std_arith.all;
entity alarm is port (
clk: IN std_logic;
le : OUT std_logic;
a: IN std_logic_vector(3 downto 0);
b: IN std_logic_vector(3 downto 0);
x: OUT std_logic_vector(1 downto 0));
end alarm;
architecture arch_alarm of alarm is
type states is (state0, state1, state2, state3 );
signal stado_pres, stado_fut: states;
begin
p_estados: process(stado_pres,a,b) begin
case stado_pres is
when state0 =>
x <= "00";
le <= '0';
if a = NOT(b) then
stado_fut <= state1;
else
stado_fut <= state0;
end if;
when state1 =>
x <= "01";
le <= '0';
if a = NOT(b) then
stado_fut <= state2;
else
stado_fut <= state0;
end if;
when state2 =>
x <= "10";
le <= '0';
if a = NOT(b) then
stado_fut <= state3;
else
stado_fut <= state0;
end if;
when state3 =>
x <= "11";
if a = NOT(b) then
le <= '1';
end if;
stado_fut <= state0;
end case;
end process p_estados;
p_reloj: process(clk) begin
if(clk'event and clk= '1') then
stado_pres <= stado_fut;
end if;
end process p_reloj;
end arch_alarm;
And the errors are :
Note 4059: Signal le cannot be assigned (to pin 23) because
there are too many terms for output le pin 23.
Note 4068: Signal le cannot be assigned (to pin 23) because
the register type of 'le' pin 23 is invalid.

Answer 1

Your le signal infers a latch. It is assigned in only two states. Assign it in all four.
too many terms for output le pin 23"
After doing so you now have too many terms for Pin 23. It's because
if a = NOT(b) then
le <= '1';
end if;
the comparison of `a and not b'.
Can you move le to an output with 10 terms (pin 23 has 8)? (stado_pres should be the output of two flip flops while stado_fut is the input to the flip flops).
Can you make this comparison a separate signal with a pin? The impact would be twice the fall through delay of the PAL.
Have you been supplied with any indication how your states are encoded? (As in are they duplicated in x?, is x a synonym for stado_pres?)
and as pwolf points out
I only looked at this distractedly for your second error message. le is still prone to a latch based on the lack of else assignment in state3.
Determining timing associated with a PAL is trivial. What is this used for?

Answer 2

Keeping with #David Koontz answer, le is still not fully defined in state3. Try completing the if statement to fully define le:
when state3 =>
x <= "11";
if a = NOT(b) then
le <= '1';
else
le <= '0';
end if;
stado_fut <= state0;
If your inputs a and b are synchronous to your input clk, I would suggest you rewrite the state machine to run synchronously as apposed to asynchronously. E.g.
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
use work.std_arith.all;
entity alarm is port (
clk: IN std_logic;
le : OUT std_logic;
a: IN std_logic_vector(3 downto 0);
b: IN std_logic_vector(3 downto 0);
x: OUT std_logic_vector(1 downto 0));
end alarm;
architecture arch_alarm of alarm is
type states is (state0, state1, state2, state3 );
signal stado_pres : states := state0; -- Initial condition
begin
p_estados: process(clk)
begin
if rising_edge(clk) then
case stado_pres is
when state0 =>
x <= "00";
le <= '0';
if a = NOT(b) then
stado_pres <= state1;
else
stado_pres <= state0;
end if;
when state1 =>
x <= "01";
le <= '0';
if a = NOT(b) then
stado_pres <= state2;
else
stado_pres <= state0;
end if;
when state2 =>
x <= "10";
le <= '0';
if a = NOT(b) then
stado_pres <= state3;
else
stado_pres <= state0;
end if;
when state3 =>
x <= "11";
if a = NOT(b) then
le <= '1';
else
le <= '0';
end if;
stado_pres <= state0;
end case;
end if;
end process p_estados;
end arch_alarm;
IMHO, writing synchronous logic is generally preferred to asynchronous logic as timing analysis is made easier and it's much simpler to debug. This also has the added benefit of removing all of the latches from your code, which maybe be the source of your issue.
Even if inputs a and b are not synchronous to input clk, you could consider doing a proper clock domain transfer of these buses to the clk domain.