Why is this an issue?

There are several reasons why the rising edge of a clock is generally favored over the falling edge for clock domains:

1. Consistency with Other Systems
   • Industry Standards: Many standard interfaces (like SPI, I2C, etc.) and protocols use rising edges for clock synchronization. Using rising edges ensures compatibility and simplifies integration with these standards.
2. Tool Support and Synthesis
   • Better Optimization: Synthesis tools are often optimized for rising edge triggers, potentially leading to better timing and area results.
   • Simulation Consistency: Simulation tools might have more robust support or better performance modeling for rising edge clocks due to widespread use.
3. Signal Integrity
   • Noise Tolerance: Rising edges are often less susceptible to noise since they usually transition from a logic low, which might be closer to ground, making them cleaner transitions. Falling edges, transitioning to ground, might be more affected by ground bounce or noise.
   • Power Considerations: Rising edges can be less power-intensive for certain types of logic, particularly in CMOS where the charging of the load capacitance occurs on the rising edge.
4. Design Practice and Readability
   • Convention: Rising edge clocking is a widespread convention, making designs more readable and understandable by others in the field.
   • Clock Tree Synthesis: Clock tree synthesis, which is crucial for timing closure, might have better support or methodologies developed for rising edges due to their common use.
5. Timing Analysis
   • Setup and Hold Times: The timing analysis tools might have better models or default settings for rising edges. Additionally, setup times are generally measured with respect to the rising edge in most data sheets.
6. Clock Gating and Power Management
   • Clock Gating: Implementing clock gating or power management strategies can be simpler with rising edge clocks, as these techniques often involve gating the clock low, which aligns with rising edge detection.

While there's no inherent technical limitation preventing the use of falling edges, the preference for rising edges stems from these practical considerations in design, implementation, and verification. However, in some specialized applications, falling edge triggered designs might be chosen for specific reasons, but this is less common.

How to fix it

Code examples

Noncompliant code example

process(clk)
begin
  if(clk'event and clk='0') then -- Noncompliant: Falling
    xr <= not xr;
  end if;

  if(not clk'stable and clk='0') then -- Noncompliant: Falling
    xr <= not xr;
  end if;

  if(falling_edge(clk)) then -- Noncompliant: Falling
    xr <= not xr;
  end if;
end process;

Compliant solution

process(clk)
begin
  if(clk'event and clk='1') then -- Compliant: Rising
    xr <= not xr;
  end if;

  if(not clk'stable and clk='1') then -- Compliant: Rising
    xr <= not xr;
  end if;

  if(rising_edge(clk)) then -- Compliant: Rising
    xr <= not xr;
  end if;
end process;

Resources

Related rules

• Falling should be preferred over falling to detect clock transitions