The asker wrote an asynchronous-reset flip-flop in what looks like textbook Verilog:

always @(posedge clk or negedge rst_n)
  if (rst_n)      LED <= {LED[0], LED[3:1]};
  else            LED <= 4'b0000;

Vivado's synthesizer rejects it with [Synth 8-7213]. The message is cryptic — "operand 'x' does not match with the corresponding edges used in event control" — but the bug is a subtle semantic one, not a typo.

Why this is interesting. Simulators cheerfully accept this code and will even produce plausible-looking waves, which is why beginners get bitten. The problem is that the sensitivity list declares negedge rst_n — meaning "wake up when rst_n falls" — but the if branch treats rst_n high as the reset condition. The polarity is inverted. Synthesis tools infer flip-flop primitives from the pattern of the always block, and every FDCE/FDPE/FDRE cell in the FPGA library has a fixed relationship between the async control edge and the reset value. When your RTL says "trigger reset on the falling edge but only while the signal is high," there is no cell that implements that; the tool refuses to guess.

The fix is to make the edge and the level agree:

always @(posedge clk or negedge rst_n)
  if (!rst_n) LED <= 4'b0000;              // reset branch first, level matches negedge
  else        LED <= {LED[0], LED[3:1]};

Rules of thumb that fall out of this:

• The reset branch must always be the first if in the block, with no else if between it and the clocked logic.
• The polarity of the reset test must match the edge: negedge rst_n pairs with if (!rst_n); posedge rst pairs with if (rst).
• Only the clock and the asynchronous reset (or set) may appear in the sensitivity list — nothing else.

Gotchas. Simulation-vs-synthesis divergence is the real danger here: the buggy code simulates as a latch-like structure that resets when rst_n rises, which is completely different from the FPGA netlist the tool would have to build. Also worth noting — some tools emit a warning for this and infer something anyway, so the fact that Vivado hard-errors is actually protective. Xilinx's UG901 spells out the exact inference templates; deviating from them tends to punish you at synthesis time, not at simulation time.