Why is this an issue?

Using both active-low and active-high resets within the same reset domain can lead to several issues:

1. Confusion and Misinterpretation
   • Design Misunderstanding: Developers might mistakenly assume one type of reset behavior when the opposite is true, leading to logical errors in the design.
   • Documentation Complexity: Keeping track of which modules or flip-flops respond to which reset polarity complicates documentation and maintenance.
2. Increased Design Complexity
   • Verification Challenges: Testing becomes more intricate since you need to account for different reset behaviors across the design. This can lead to more test cases and more complex testbenches.
   • Reset Distribution: Managing how reset signals are routed and inverted (if necessary) adds unnecessary complexity to the design, especially if reset trees involve multiple levels of logic.
3. Timing and Glitch Issues
   • Timing Closure: Ensuring that both types of resets work correctly with respect to the clock can be challenging, particularly if you're dealing with timing margins where small delays matter.
   • Glitches: If reset signals are not perfectly aligned or if there's any delay or skew in the reset path, you might encounter glitches or temporary states where parts of your system are reset while others are not.
4. Synthesis and Implementation
   • Tool Handling: Synthesis tools might handle mixed reset polarities inconsistently, potentially leading to different area, timing, or power characteristics for the same logical design.
   • Reset Recovery: Recovery from reset can be non-deterministic if some parts of the system are using active-low while others use active-high, complicating the timing analysis of reset release.
5. Debugging Complexity
   • Fault Isolation: When an issue occurs, it's harder to pinpoint whether it's due to reset polarity confusion, especially in large designs where reset signals propagate through various logic levels.
6. Consistency in Design Practices
   • Design Standards: Most design standards or company practices advocate for uniformity in reset polarity to reduce errors and improve maintainability. Mixing polarities goes against these principles.

In summary, while there might be specific cases where using both active-low and active-high resets might seem beneficial, the drawbacks generally outweigh the advantages. It's advisable to choose one reset polarity standard for all elements within a reset domain to ensure clarity, reduce design complexity, and facilitate easier verification, synthesis, and debugging processes.

How to fix it

Code examples

Noncompliant code example

architecture rtl of top is
begin
  A: process (clk) is
  begin
   if rising_edge(clk) then
     s1 <= '1';
     if rst = '1' then  -- Active-high reset
       s1 <= '0';
     end if;
   end if;
  end process;

  B: process (clk) is
  begin
   if rising_edge(clk) then
     s2 <= '1';
     if rst = '0' then  -- Active-low reset
       s2 <= '0';
     end if;
   end if;
  end process;
end architecture;

Compliant solution

architecture rtl of top is
begin
  A: process (clk) is
  begin
   if rising_edge(clk) then
     s1 <= '1';
     if rst = '1' then  -- Active-high reset
       s1 <= '0';
     end if;
   end if;
  end process;

  B: process (clk) is
  begin
   if rising_edge(clk) then
     s2 <= '1';
     if rst = '1' then  -- Active-high reset
       s2 <= '0';
     end if;
   end if;
  end process;
end architecture;