Ttdfjt

If I need to perform the same function on a number of different signals in a VHDL design will placing them in a vector affect synthesis optimization in any way?

As as example, let's say I'm trying to simulate a real-world circuit that's built up from TTL chips. A 7402 Quad 2-Input NOR chip, for example, can have the logic for each gate specified explicitly:

entity dm7402 is
 port(
 a0, a1, a2, a3,
 b0, b1, b2, b3: in std_logic := '0';
 y0, y1, y2, y3: out std_logic
 );
end dm7402; 

architecture behavior OF dm7402 IS
begin
 y0 <= a0 nor b0;
 y1 <= a1 nor b1;
 y2 <= a2 nor b2;
 y3 <= a3 nor b3;
end architecture;

Alternatively I can use a vector:

entity dm7402 is
 port(
 a, b : in std_logic_vector(3 downto 0) := "0000";
 y : out std_logic_vector(3 downto 0)
 );
end dm7402; 

architecture behavior OF dm7402 IS
begin
 y <= a nor b;
end architecture;

Intuitively I would guess that the first case could result in a faster design by giving the synthesizer the freedom to move gates around so as to optimize routing, whereas the second might result in using less resources. Is that a fair assumption to make?

(BTW I do realize that in a real-world situation I wouldn't actually be explicitly designing with TTL logic like this, but just humor me).

My guess is that there will be no difference. However, the results will depend greatly on the specific tool set you use as well as the target architecture (FPGA? ASIC?).

By the time the tools get to the placement and routing steps they have long forgotten what your RTL looked like. In fact, the gates themselves may have been optimized away or the logic function could be modified in such a way that there is no gate in the final design corresponding to your NOR gates...this is almost guaranteed to be the case in an FPGA.

It does not make a difference.

Synthesis tools are very, very good at optimizing.

As to "speed" versus "area": every synthesis tool I know has settings where you can choose which one you prefer. Normally the tools will optimize until it meets the timing constraints and then stop. Which means you get the smallest design which still meets timing.

The only time your gates are not "moved around" is if you explicitly tell the synthesis tool to not do that. It falls under the category where you tell the tool not to optimize across module boundaries. (e.g. 'no flattening' or 'flattening off' or a tick box with some 'keep boundaries' option.