2
\$\begingroup\$

I have a simple Verilog module with only one synchronously reset DFF:

module scratch (input clk, reset_n, serial,
                output reg serial_ff);

   always @ (posedge clk) begin
      if (!reset_n) begin
         serial_ff <= 1'b0;
      end
      else begin
         serial_ff <= serial;
      end
   end

endmodule // scratch

When running a lint check (hal 06.20-s004) on my design for ASIC, I get the following warning in the DFT category:

*W,FFWASR (./scratch.v,9|0): Flip-flop 'serial_ff' does not have any asynchronous 
set or reset.
------
Flip-flops must have asynchronous set or reset. If a flip-flop
does not have any asynchronous set or reset then it is not 
controllable from primary inputs.

The following example illustrates this problem:

if(rst)
port_a <= '0';
elsif rising_edge(clk) then
port_a <= var_a;
port_b <= var_b;
end if;

In the above HDL code, the value of 'port_a' can be
brought to '0' using asynchronous reset 'rst', while 
this is not the case with 'port_b'. This may cause
issues during simulation.

I am already using a synchronous reset for the FF, so it is getting initialized. But the warning tells me to use an asynchronous reset instead. But why is this important for testing? What sort of failures can this DFT methodology (asynchronous R instead of synchronous R) identify?

In short, when should I care, and when is it okay to ignore the warning?

Update: I found a parameter mentioned in passing in the documentation: "setreset_type". I grepped the entire doc set and it appears its undocumented. So I guess Cadence REALLY wants everyone to use async resets religiously. But the truth is that resets shouldn't be implemented religiously, but that the designer should consider the trade-offs and design requirements for any type of reset. This is the resounding conclusion of the answers so far, so you all get points for being helpful! I will update if I can find how to use that undocumented parameter. That was the only possible setting I could find after digging through all related documents. For now, I ignore the warning since we already have considered the design of the reset from the system architecture level.

\$\endgroup\$
6
\$\begingroup\$

This answer is valid for ASICs.

After reading few references on the net I discovered that the question "sync or async" is a kind of "iOS or Android" question. All the below is my opinion on the subject which is biased.

Async resets are pain in the neck because:

  1. They are glitch sensitive
  2. They must be deasserted synchronously
  3. They must be deasserted synchronously, to all flops, at the same clock cycle
  4. They can cause metastability problems if there are flops which are not reset

While section 1 and 2 are easy to handle, the rest are major issues which require thorough understanding and a whole lot of tools for validation.

And now the painful truth: async resets are still preferable for large systems. The advantages of async resets are:

  1. Async resets have priority over any other signal
  2. Async resets do not share combinational paths with other signals
  3. Async resets do not require clocks

The fact that all the flops are reset, and that all the flops are out of reset at the same clock cycle is a major advantage (and if it does not happen on the same cycle, then this is indicated by tools and awaits for designer's decision). In complex designs (containing many clock domains where each clock is gated tens or hundred of times) it is very difficult to ensure that there are no corner cases when sync resets are used. Async resets are agnostic to these issues (there is still one place where async resets meet clocks - in the deassertion logic, which must be distinct for each clock domain).

The warning you see suggests that all your flops should be reset asynchronously. However, it is a matter of micro-architectural decision which kind of reset to use, and this should be consistent across some defined boundary. Still, if you're sure that non-standard reset is more appropriate in some place - use it and waive the warning.

EDIT:

During scan insertion all the flops in a scan chain are required to function properly. If you're using an externally fed async reset then the above condition is very simple to satisfy - just tie the external net to a non-reset value.

In a sync reset designs the above condition must also be satisfied. This is achieved in the same manner, but since sync resets may share combinational paths with other logic, the tools may erroneously detect flops which can get reset during scan (or not erroneously).

In light of the additional information provided in comments (no async resets at all and this warning is reported for all flops), I believe that you can disable this rule completely. On the other hand, you might want to ensure that your Lint DFT supports sync resets (i.e. it has parallel rules for sync resets, and these rules are enabled)

EDIT2:

I found this great article on the Web. I've never been to SNUG myself, but it seems like there are many designers who favor sync reset schemes. You can find pretty deep analysis of sync and async schemes in the above article, along with many practical advices.

|improve this answer|||||
\$\endgroup\$
  • \$\begingroup\$ Yes, this is all valid, but I am not convinced that the real reason for the warning is explained here. Why would DFT FFs need to be controllable by primary inputs? My current idea is that a synchronous reset might mess with the scan chain in a DFT FF. \$\endgroup\$ – travisbartley Jul 30 '13 at 10:00
  • \$\begingroup\$ What do you mean by "DFT FFs"? I thought we are talking about a regular flop which is reported in Lint DFT. Anyway, the only piece of information you provided is the warning's log. It is very difficult to understand why you're getting this warning without actually seeing your code. Based on warning's example, I can guess that you may have a sequential block with async reset for some of signals and no reset for others. \$\endgroup\$ – Vasiliy Jul 30 '13 at 11:35
  • \$\begingroup\$ I just understood what were you asking. Sorry man - I've always been a fail in English. I added few sentences at the end of the answer, but, still, no advices until you show some code \$\endgroup\$ – Vasiliy Jul 30 '13 at 12:25
  • \$\begingroup\$ DFT is design for test and FF is flip flop. By DFT FF I mean "FF in a DFT design". I will get a minimum working example that triggers the warning tomorrow. It really is just a flip flop with synchronous reset. There are no FFs in the design with async reset. All have sync reset. \$\endgroup\$ – travisbartley Jul 30 '13 at 13:24
  • \$\begingroup\$ If you have other sync reset FFs and you get no warnings for them, then it is probable that either your Linting tool can't derive a reset condition for this particular flop (it may be a tool deficiency or a real bug), or it is reporting a bad coding style. \$\endgroup\$ – Vasiliy Jul 30 '13 at 13:28
2
\$\begingroup\$

I would ignore the warning, but you have to understand that it will have an undetermined value until the first clock edge (where var_b is valid). There are many cases where this is actually desirable!

If you are designing for a Xilinx FPGA, where a LUT can also function as a giant shift register, then you do not want a reset case for your shift register. Without the reset case, a shift register can be combined into a single LUT. Once you put a reset on it, the entire shift register will be done using normal FF's instead of a LUT.

In some other cases, you might not want a reset case for every flip flop. If you are doing an ASIC, using a reset case on only the critical flip flops can reduce the routing of having to run the reset signal to every flip flop.

It is also my duty to point out that async-resets are not advisable for Xilinx designs (and I assume most FPGAs). Instead, use sync-resets. You didn't say if you are doing an FPGA, so this may not apply to you.

Update: More stuff about DFT.

The problem with not having a reset for your FF's is that when they start up they are in an indeterminate state. In real hardware, they might be a 0 or 1. In VHDL simulations they have a 'U' or 'X' (I forgot which). When testing (either in real hardware or in simulation) this has to be taken into account. In some cases, this just means that those signals have to be ignored for several clock cycles as the system starts up. In other cases it can cause some logic to come up different but still valid ways. Depending on how you are doing the verification this may or may not be an issue.

Consider a simple 4 bit counter. If you have a "proper" reset then it will come up and start counting like this: 0, 1, 2, 3, 4, etc. But without a reset then the real system could come up and count 15, 0, 1, 2, 3, etc. or even 6, 7, 8, 9, etc. Some design verification systems expect the system to come up the same way every time, since they just compare test vectors and do not take into account the actual functionality of the design. So if the verification system is looking for 0, 1, 2, 3 but gets 6, 7, 8, 9 then it will flag that as an error-- even though you may consider 6, 7, 8, 9 as perfectly valid.

The solution to this is to have a valid reset for each FF. This makes verification easier, but complicates lots of other things. My preference is to design the logic to be optimal, at the possible expense of making verification more complicated.

|improve this answer|||||
\$\endgroup\$
  • \$\begingroup\$ I am particularly interested in why this would be necessary for DFT. Is there some testing technique that specifically requires asynchronous as opposed to synchronous? I updated the question to specify it is ASIC design. \$\endgroup\$ – travisbartley Jul 30 '13 at 2:21
  • \$\begingroup\$ @trav1s ASCII and you shall receive-II. \$\endgroup\$ – user3624 Jul 30 '13 at 2:33
  • \$\begingroup\$ Okay, resets are needed for initialization, I am on board with that. But the part of the warning that gets me is this: I am using a synchronous reset, so initialization is not a problem. Despite that, the warning is telling me I should use an asynchronous reset. Would you say it is just an erroneous warning in this case? \$\endgroup\$ – travisbartley Jul 30 '13 at 2:40
  • \$\begingroup\$ @trav1s I think that the warning is incorrect, specifically the part about controllable from primary inputs. Where simulations might run into issues with sync-resets is that they will still require a clock edge to be reset, where an async-reset will force the FF to a known state at time=0. \$\endgroup\$ – user3624 Jul 30 '13 at 2:47
  • \$\begingroup\$ I hope it's just an incorrect warning, but I don't think it is. For instance, a sync-R requires valid setup/hold time, so if there is a timing violation or fault in the logic you can't control the FF. By having async-R you can isolate such faults. I am not sure if this is the reason for the warning or not though, so I am hoping a DFT guru can give more detail. \$\endgroup\$ – travisbartley Jul 30 '13 at 2:59
1
\$\begingroup\$

The other answers cover the possible landmines.

In linting, formal equivalency checking or other verification, the propagation of Unknowns and don't cares greatly complicates the results. Having a forced reset to known state reduces the complexity of the analysis. And frankly in some cases the tool cannot (provably so) resolve the correct state (because of propagation of unknowns and don't cares). At least until those conditions have flushed through the system.

That warning is a "use async reset cells or our checks can't be as complete as we'd like and it's your fault if it fails" statement.

The trade off you face is, "should I carry extra gate area (is it that much?)" vs. "how sure am I that I don't have a hidden state?" If it's complex logic have you covered all the possible start up states? If it's a register that then gets loaded, that is dealt with differently.

The trend is towards letting the tool deal with it. And if the tool requires that you use certain types of cells then you accept the area loss. It really depends on the size of the design and the complexity of the design database.

|improve this answer|||||
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.