Vivado is bugged up the *** per usual (no, my bad)

[Tickstart]

Every time... Here I am, just wanting to test the most benign of things, and Vivado has to give me ****. It says "design rev_top has unconnected port sw[4]" (I assume because "design revving has unconnected port rev" - which it is connected to), which I know for a fact is a lie. It also says "design has unconnected top module" and I'm suspecting Vivado has become senile at this point.

My goal is to reverse bits, depending on a signal (sw(4) - to reverse or not). Just to test the syntax and functionality of VHDL. VERY SIMPLE, IF I JUST HAD A CHANCE TO TEST IT.

 

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

entity rev_top is
    Port (clk : in STD_LOGIC;
          sw : in STD_LOGIC_VECTOR (4 downto 0);
          led : out STD_LOGIC_VECTOR (3 downto 0));
end rev_top;

architecture Behavioral of rev_top is

component revving is
    Port (clk, rev : in STD_LOGIC;
          in_sig : in STD_LOGIC_VECTOR (3 downto 0);
          out_sig : out STD_LOGIC_VECTOR (3 downto 0));
end component;

begin

    REVERSER: revving port map(clk => clk, rev => sw(4), in_sig => sw(3 downto 0), out_sig => led);

end Behavioral;

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;

entity revving is
    Port (clk, rev : in STD_LOGIC;
      in_sig : in STD_LOGIC_VECTOR (3 downto 0);
      out_sig : out STD_LOGIC_VECTOR (3 downto 0));
end revving;

architecture Behavioral of revving is

signal reverse_order_bits : STD_LOGIC_VECTOR (0 to 3); 

begin

    reverse_order_bits <= in_sig;
    out_sig <= reverse_order_bits when rev = '1' else in_sig;

end Behavioral;

 

[Tickstart]

It could be the textbook that's lying also. That you can reverse bits like that (with a downto vs to trick).

[xc6lx45]

1 hour ago, Tickstart said:

"design rev_top has unconnected port sw[4]" ... which I know for a fact is a lie

laughing out loud... but a lie implies intent - Vivado would plead for diminished responsibility or insanity

Well... It just tells you its view, without much interpretation. And this is post-optimization - the assumption is that all signals contribute to irreducible logic. If something gets optimized away, it gives this kind of warning which seems weird at first but is just a statement of the "hard" facts available to the tool. Interpretation is left to the user.

Did you notice that it completely optimized out the "reversed" option but apparently not the non-reversed path (no warning for sw(0..3)?

The warning about "clk" is legit - you have a clock in a fully combinational design. I'd get rid of that (or register the output) just to clear the waters. I'd look at the elaborated design, this is Vivado's view of your input.

If you can pinpoint the problem, I'm curious to know what exactly caused it.

 

[hamster]

I can't see what the issue is... can you describe exactly how are you expecting this to reverse the order of the bits? 

If your assignment into 'reverse_order_bits' does change the order, then when you assign that into 'out_sig' then that will also reverse the order.

So if the output is always the input, then 'rev' (and that means 'SW[4]') also has no effect, and can be optimized out.

And if the out_sig always equals in_sig, then your design does indeed contains no logic, just three connections from input pins to output pins.

All seems consistent to me.

Try it with explicitly reversing the order of the bits.

[xc6lx45]

1 minute ago, hamster said:

 then that will also reverse the order.

10 points for hamster, case closed.

It's double reversal. Both cases are identical, so the rev input does not contribute to irreducible logic, gets optimized away with a warning (see above). Everything works as designed.

[Tickstart]

Yes yes, I understand. So there is no way to flip the order this way, i.e you need to keep the to or downto chain consistent between modules?

 

I'm sorry I slandered you Vivado :'(

[hamster]

12 hours ago, Tickstart said:

Yes yes, I understand. So there is no way to flip the order this way, i.e you need to keep the to or downto chain consistent between modules?

I don't think you have to keep it consistent within a module. but it makes sense to.

Conventions I have seen and use are:

signals are always "downto". This makes numbers make sense - e.g. "00110000";

   sig_downto <= "00110000"; assigns binary 48

   sig_to <= "00110000"; assigns binary 12;

Arrays are always "to". This makes initialization make sense.- the first element in the list goes into slot zero.

If you do want to flip bits, this can do it for you:

out_sig(0) <= in_sig(2) when rev = '1' else in_sig(0);
out_sig(1) <= in_sig(1) when rev = '1' else in_sig(1);
out_sig(2) <= in_sig(0) when rev = '1' else in_sig(2);