I usually work with Xilinx FPGA boards. Based on the documentation I've reviewed and the research I've done, I try to avoid using a global reset signal in my designs as much as possible. However, let's assume I absolutely have to use one somehow.
In that case, I use a synchronous reset and only reset the registers that absolutely need it—not the entire design. For instance, suppose a module contains a Finite State Machine (FSM). The FSM needs to return to the IDLE state upon reset. I want to settle for just pulling the state to IDLE instead of resetting all associated counters, shift registers, etc.
However, if a counter is running while the reset signal arrives, the counter will remain unsynchronized when the FSM returns to IDLE. When the FSM eventually transitions back to that state, the counter will resume from its old value (e.g., 5) instead of 0, which breaks the design's intended structure.
For example, let's say a counter must count up to 10 in a specific state before the FSM moves to the next state. I typically reset the counter when it reaches 10 and simultaneously transition to the next state.
always_ff @(posedge clk) begin case(state) IDLE: state <= COUNT; COUNT: begin counter <= counter + 1; if(counter == 10 - 1) begin counter <= 0; state <= DATA; end end DATA: something.. ... .. endcase end But, as I mentioned, if a reset arrives when the counter is at, say, 5, it will resume from 5 upon returning to that state, which is erroneous. Should I instead use a structure like the one below, where the counter register is reset only when transitioning into the state where it will be used? This way, I would be safe regardless of when the reset signal arrives:
always_ff @(posedge clk) begin case(state) IDLE: begin state <= COUNT; counter <= 0; COUNT: begin counter <= counter + 1; if(counter == 10 - 1) begin state <= DATA; end end DATA: something.. ... .. endcase end Is this how good engineers design, or what is the standard practice?
wire local_reset; assign local_reset = (reset || state ==IDLE);The best way is that you have a reset hierarchy. Some subsystems (module collection) can come out of reset together. They go to an idle state and wait for other subsystems to come alive. There is no standard practice as it will depend on the system design (module connectivity within the design). I do not think you need to tie it to a state machine though (but you certainly can).clock,enable,resetas inputs and anexpireandcountoutput. Bothenableandresetwill set the count to zero. The count size is a parameter. With this module, it is more obvious what to do when the higher level module gets a reset.enableandresetcan probably be the same in your case. In computer science, this might be called aspect oriented (lamdas are another example; but neither work with HDL). System clocking is another example. For some designs, there might be one common clock as all I/O is asynchronous. The choice of reset type, hierarchy and clocking can not be a generic rule but will depend on the architecture of the device (to speak to what is the standard practice?). Enable structures can be critical for power.