Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
10 years ago

Local Reset Conditions - Sync or Async

Just pondering a question, and wondering what other people would do.

We all know that Altera recommends async asserted, sync de-asserted asynchronous resets, and real sync resets have to be emulated. So would it then follow, that if I have some signal that is reset by some other signal, and the global reset, to OR them together to reset the flop asynchronously: 


process(clk, rst, local_rst)
begin
  if rising_edge(clk) then
    op <= ip;
  end if;
  if rst or local_rst then
    op <= '0';
  end if;
end process;

Traditionally, I would always treat "local_rst" as a synchronous reset and take the setup timing hit, but would the above be worse from a recovery POV compared to the "traditional" code below: 


process(clk, rst)
begin
  if rising_edge(clk) then
    op <= ip;
  
    if local_rst = '1' then
      op <= '0';
    end if;
  end if;
  if rst = '1' then
    op <= '0';
  end if;
end process;

3 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    10 years ago

    I cannot say which is "better", but since your question is what other people would do... I'd use the second approach.

    The first approach puts an OR-gate into the reset, and this would basically make my reset de-assert asynchronous again. Well, not exactly completely asynchronous, it depends on whether rst and local_rst were generated using a register or not, so I think the timing would be safe. However, I like the idea that there is one global reset signal, which is properly synchronized, and resets the complete FPGA. If any entity can be put back into default state, then this usually happens via some "clear" signal or so, which comes from synchronous logic, and then it just makes sense to me to treat it as a regular, synchronous signal. Keeps the structure nice and clean (one reset and one clock per process).

    When I have to OR some resets (e.g. a push-button reset and a PLL-not-locked reset), I put a synchronizer after the OR. Same reason: one reset and one clock per process, no hidden funky features.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    10 years ago

    --- Quote Start ---

    I cannot say which is "better", but since your question is what other people would do... I'd use the second approach.

    The first approach puts an OR-gate into the reset, and this would basically make my reset de-assert asynchronous again. Well, not exactly completely asynchronous, it depends on whether rst and local_rst were generated using a register or not, so I think the timing would be safe. However, I like the idea that there is one global reset signal, which is properly synchronized, and resets the complete FPGA. If any entity can be put back into default state, then this usually happens via some "clear" signal or so, which comes from synchronous logic, and then it just makes sense to me to treat it as a regular, synchronous signal. Keeps the structure nice and clean (one reset and one clock per process).

    When I have to OR some resets (e.g. a push-button reset and a PLL-not-locked reset), I put a synchronizer after the OR. Same reason: one reset and one clock per process, no hidden funky features.

    --- Quote End ---

    This is kind of what I was thinking. local_reset would always be the output of a flop, but I was concerned about adding delay to the async reset signal, which could cause recovery violations. I just wondered if this would be any better/worse than the equivalent setup violation. But fixing setup is just a case of adding more regs/reducing logic.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    10 years ago

    I believe, we need to know more about the nature and purpose of local_reset.

    Introducing asynchronous signals without previous synchronizing brings up a risk of inconsistent design states, this can also happen in this case if only some signals are reset, while a global reset will always put all signals into a defined state.