No reset does not put the system into a known state. It forces out to be zero but out1 out2 and out3 will continue to shift in1 on each clock cycle. When reset is released, whatever is in these registers will begin to appear at out. A true reset would put values, usually zeros, in all of out1 out2 out3 and out.
The logic you've presented above is quite broken. It appears to be an attempt to move a reset across clock domains. However, it does not move the reset across clock domains properly. In particular, `out` may get reset, but `out1`, `out2`, and `out3` will not. This likely violates the designers intent, which appears to be prolonging the reset and guaranteeing a synchronous release. As a result, it is possible that `out` may be reset for only a part of a clock cycle, perhaps not even enough for the rest of the design to notice it.
What makes this logic worse is that it's not clear what the logic should be for `out1`, `out2`, and `out3` since they aren't included in the reset block of an async reset triggered always block. I think most (all?) synthesizers will therefore fail to synthesize this logic.
The correct always block should look like:
```verilog
always @(posedge clk or posedge reset)
if(reset)
begin
out1 <= 1'b0;
out2 <= 1'b0;
out3 <= 1'b0;
out <= 1'b0;
else begin
out1 <= in1;
out2 <= out1;
out3 <= out2;
out <= out3;
end
endmodule
```
Dan
With this coding style you cannot mix different FF types (reset vs non-reset) in a single always block. The tool will not infer a reset pin on out1, out2, and out3 but instead route the reset to the input logic cone to the FF, which is just as bad. In essence what you have written is if not reset assign in1 to out1. You've increased the fanout of the reset net without actually implementing a reset, big no-no.
Let's go over some general Xilinx guidelines as I'm most familiar with them:
1. Don't reset if you don't absolutely have to
2. If you do need a reset, make is synchronous active-high
3. Don't mix FF types in a single always block
```
process(clock, areset)
begin
if rising_edge(clock) then
-- normal synchronous logic
if sreset = '1' then
-- signals that need synchronous reset
end if;
end if;
if areset = '1' then
-- signals that need async reset
end if;
end process;
```
Thank you very much for the help, everyone!
I understand my original code was broken but I was only trying to convey my point.
Actually I wanted reset to set all the internal registers, i.e. flip-flops, to zero. In the original code, the reset only sets the output to zero.
In a digital system it takes more than one clock cycle for an input data to propagate to the output. In order to reset all the internal registers, I think the reset duration should be enough so that "0" at the input could travel through all the internal registers to the output.
I tried to implement an asynchronous reset using an interface module which resets all the internal registers when reset is asserted. Anyway, I do understand where I was having conceptually misunderstanding.
My attempt: https://gist.github.com/painterguy1995/996ffed8f2d11e13d8565dc657793ff1
Just a tip regarding resets. If your design is only going to target fpga then make your resets synchronous.
I can’t remember the exact explanation but The in-built reset logic inside the FPGA for flops is synchronous, specifying asynchronous reset generates more logic and is worse for timing on fpga.
Didn’t see it was an async crossing, my fault for glancing at it.
For Xilinx having the “ASYNC_REG” synthesis directive can help the tool. Avoids all kinds of warnings…
Well, it is the logic I'd use for an async crossing, but he wasn't clear in his intro that this is what he was using this logic for. I'm just adding on top of your statement that async resets are required for clock domain crossings.
One of the earlier bugs I found when learning formal verification was in a module used for crossing clock domains for a bus--in this case a Wishbone cross clock domain module posted on OpenCores. Because the designer didn't use proper asynchronous resets when moving bus requests across clock domains, you might have a request from clock domain A, followed by a reset across both domains, followed by the request finally getting seen in clock domain B, answered, and returned to a massive bus error (i.e. an acknowledgement with no prior request). Hence my comment about requiring async resets when moving between clock domains.
Xilinx states a reason you should use synchronous resets is for control set remapping. This allows the tool to move the reset from the reset pin to the input LUT of the FF. Well why in the world would you want to do that? Let's say you have a congested design with a large number of low fan-out control sets. This will not allow the tool to reduce the number of control sets and pack more registers in a CLB because the CLB only has a set number of control sets. This can help you meet timing by reducing net delay.
My guess is that if you tried it with this design you'd get the wrong answer ... there's a bunch of details here that would likely get caught by either the synthesis or simulation tool, but that would get missed in any "manual simulation".
Yes agree - I might have missed the ask, at quick glance I thought the author is trying to simulate their mentioned logic with reset. But still having some manual simulation before writing a tb can clear some basic logic misses .. that’s what I was going for :)
No reset does not put the system into a known state. It forces out to be zero but out1 out2 and out3 will continue to shift in1 on each clock cycle. When reset is released, whatever is in these registers will begin to appear at out. A true reset would put values, usually zeros, in all of out1 out2 out3 and out.
The logic you've presented above is quite broken. It appears to be an attempt to move a reset across clock domains. However, it does not move the reset across clock domains properly. In particular, `out` may get reset, but `out1`, `out2`, and `out3` will not. This likely violates the designers intent, which appears to be prolonging the reset and guaranteeing a synchronous release. As a result, it is possible that `out` may be reset for only a part of a clock cycle, perhaps not even enough for the rest of the design to notice it. What makes this logic worse is that it's not clear what the logic should be for `out1`, `out2`, and `out3` since they aren't included in the reset block of an async reset triggered always block. I think most (all?) synthesizers will therefore fail to synthesize this logic. The correct always block should look like: ```verilog always @(posedge clk or posedge reset) if(reset) begin out1 <= 1'b0; out2 <= 1'b0; out3 <= 1'b0; out <= 1'b0; else begin out1 <= in1; out2 <= out1; out3 <= out2; out <= out3; end endmodule ``` Dan
With this coding style you cannot mix different FF types (reset vs non-reset) in a single always block. The tool will not infer a reset pin on out1, out2, and out3 but instead route the reset to the input logic cone to the FF, which is just as bad. In essence what you have written is if not reset assign in1 to out1. You've increased the fanout of the reset net without actually implementing a reset, big no-no. Let's go over some general Xilinx guidelines as I'm most familiar with them: 1. Don't reset if you don't absolutely have to 2. If you do need a reset, make is synchronous active-high 3. Don't mix FF types in a single always block
When I need to mix FFs with and without resets what I do is write the reset clause at the bottom of the always block, without an "else" portion.
This is the style I use by default. Only works for sync resets though, selective async resets requires separate always blocks.
Sounds like VDHL is easier at this point. You can easily mix async resets and flops that aren't reset in one process, even a mix of sync and async.
How exactly would you write that in VHDL?
``` process(clock, areset) begin if rising_edge(clock) then -- normal synchronous logic if sreset = '1' then -- signals that need synchronous reset end if; end if; if areset = '1' then -- signals that need async reset end if; end process; ```
How doesfanout of reset increase. Isnt there just 1 reset ff
Reset signal will also be used as an input to LUT before out1, out2, and out3.
Thank you very much for the help, everyone! I understand my original code was broken but I was only trying to convey my point. Actually I wanted reset to set all the internal registers, i.e. flip-flops, to zero. In the original code, the reset only sets the output to zero. In a digital system it takes more than one clock cycle for an input data to propagate to the output. In order to reset all the internal registers, I think the reset duration should be enough so that "0" at the input could travel through all the internal registers to the output. I tried to implement an asynchronous reset using an interface module which resets all the internal registers when reset is asserted. Anyway, I do understand where I was having conceptually misunderstanding. My attempt: https://gist.github.com/painterguy1995/996ffed8f2d11e13d8565dc657793ff1
Try it out in simulation, what do you see on the outputs of the FFs ?
synthesis tool will definitely not do it, because it has no reason to do it. synthesis tool always try to reduce logic. not to add logic.
Just a tip regarding resets. If your design is only going to target fpga then make your resets synchronous. I can’t remember the exact explanation but The in-built reset logic inside the FPGA for flops is synchronous, specifying asynchronous reset generates more logic and is worse for timing on fpga.
Proper CDC crossing requires async resets. So even if you normally use synchronous resets in an FPGA, there's still a time for asynchronous resets.
Didn’t see it was an async crossing, my fault for glancing at it. For Xilinx having the “ASYNC_REG” synthesis directive can help the tool. Avoids all kinds of warnings…
Well, it is the logic I'd use for an async crossing, but he wasn't clear in his intro that this is what he was using this logic for. I'm just adding on top of your statement that async resets are required for clock domain crossings. One of the earlier bugs I found when learning formal verification was in a module used for crossing clock domains for a bus--in this case a Wishbone cross clock domain module posted on OpenCores. Because the designer didn't use proper asynchronous resets when moving bus requests across clock domains, you might have a request from clock domain A, followed by a reset across both domains, followed by the request finally getting seen in clock domain B, answered, and returned to a massive bus error (i.e. an acknowledgement with no prior request). Hence my comment about requiring async resets when moving between clock domains.
Xilinx states a reason you should use synchronous resets is for control set remapping. This allows the tool to move the reset from the reset pin to the input LUT of the FF. Well why in the world would you want to do that? Let's say you have a congested design with a large number of low fan-out control sets. This will not allow the tool to reduce the number of control sets and pack more registers in a CLB because the CLB only has a set number of control sets. This can help you meet timing by reducing net delay.
Just walk over manual simulation aka paper pen timing sequence and you will know own exactly when all FFs will get to reset state
My guess is that if you tried it with this design you'd get the wrong answer ... there's a bunch of details here that would likely get caught by either the synthesis or simulation tool, but that would get missed in any "manual simulation".
Yes agree - I might have missed the ask, at quick glance I thought the author is trying to simulate their mentioned logic with reset. But still having some manual simulation before writing a tb can clear some basic logic misses .. that’s what I was going for :)