1
votes

I have the following code

    use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.all;

entity LUT is
    Port ( LUTin : in STD_LOGIC_VECTOR (15 downto 0);
           LUTout : out STD_LOGIC_VECTOR (15 downto 0));
end LUT;

architecture Behavioral of LUT is
signal fullout : std_logic_vector(15 downto 0);
signal tophalf : std_logic_vector(7 downto 0);
signal secondnibble, firstnibble : std_logic_vector(3 downto 0); --break the LSH into 2 nibbles

begin
 tophalf(7 downto 0) <= LUTin(15 downto 8);
 secondnibble(3 downto 0) <= LUTin(7 downto 4);
firstnibble(3 downto 0) <= LUTin(3 downto 0);

 fullout(15 downto 8) <= tophalf(7 downto 0);
--fullout(7 downto 4) <= "0001"; 
fullout(3 downto 0) <= firstnibble(3 downto 0);
p1: process
begin
   case secondnibble is
    when "0000" => --0 Sbox1
       fullout(7 downto 4) <= "0001";
    when others => 
    end case;
    end process;
end Behavioral;

I can comment the case statement out from p1:process to the end process and comment in the fullout(7 downto 4) <= "0001"; and it will put 0001 in the 7 to 4 bits in fullout. what I want to do is to give it 0001 when LUTin(7 downto 4) <= "0000";. so I need to put the case statement and the p1:process as it is above. but this means the fullout(7 downto 4) is left as 'U'. How does it work when its not in the case statement and left as U in the case statement? I will be doing the same for the full range of secondnibble. this is just a slimmed down case statement so I can figure out how to do it

1
There's a missing library clause, apparently no value being applied to LUTin and no process sensitivity list (should contain secondnibble). Note outside the case statement fullout(7 downto 3) doesn't depend on secondnibble (which depends on LUTin). Have you provided a value to LUTin? With a LUTin value of x"AC0B" the case statement assigns "0001" to fullout(7 downto 4). (secondnibble gets assigned the x"0" from LUTin.) - user1155120
yes. when I simulate it I drive LUTin it with x"FE0C". fullout then goes to x"FEUC". when I comment out the case statement and the process, I comment back in the --fullout(7 downto 4) <= "0001"; and simulate it again, drive LUTin FE0C again, fullout goes to x"FE1C". Its just when I out it in the case statement it doesn't change fullout. I tried an if statement instead and the same happens. Also, it doesn't matter if I use p1:process or p1:process(LUTin) with no wait; - Davie
So your shown code doesn't reproduce the problem. - user1155120
As the code is now, it reproduces the problem. I drive LUTin in the simulator with FE0C and fullout becomes FEUC, the secondnibble doesn't drive the fullout(7 downto 4); as it stays as uninitialized. the tophalf and the firstnibble do drive their section of the fullout as they are outside of the case statement. there is a secondnibble commented out in the above code. if I comment this back in and the case statement out, then the secondnibble does update its section of fullout. I need the case statement to do a lookup table but as I say, it doesn't change fullout when inside the case statement - Davie
As shown now the code doesn't work. No sensitivity list for process p1, no library clause and no input values on LUTin - you haven't provided a minimal reproducible example or clear problem statement. Note there's no assignment to fullout(7 downto 4) for non "0000" case statement choices. Until secondnibble = "0000" fullout (7 downto 0) will have "UUUU". Code as shown with a library clause, p1 sensitivivty list (secondnibble), with input stimulus (a testbench) and LUTout assigned fullout shows this. - user1155120

1 Answers

0
votes

Yes. Please initialize fullout value before the "begin" keyword of architecture like:

architecture Behavioral of LUT is
signal fullout : std_logic_vector(15 downto 0) := (others => '0'); 

This will kill the ambiguity and thus U state. Please keep in mind, always initialize all the outputs, thus to mitigate the ambiguity at the synthesizer and simulator end.