Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Altera_Forum
Honored Contributor I
830 Views

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;
0 Kudos
3 Replies
Altera_Forum
Honored Contributor I
37 Views

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
Honored Contributor I
37 Views

 

--- 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
Honored Contributor I
37 Views

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.
Reply