Vivado: Reset signal flagged as primary clock by Timing Constraints Wizard?

Question

I inherited an FPGA design (Avnet MicroZed PCB) that does not meet timing. I have found that many of the design constraints are missing, and I am in the process of trying to properly implement the missing constraints.

I found one strange thing: it appears that the main asynchronous reset line for the logic is being interpreted as an unconstrained primary clock by the Vivado timing constraints wizard:

For reference, rst_n is my active-low reset signal for my flip flops. Example:

always_ff @ (posedge clk or negedge rst_n)
   if(~rst_n) begin
      // do things on reset
   end
   else begin
      // do other things on rising clk edge
   end

I am not sure why this reset would pop up as a primary clock. Is this expected behavior?

If this is normal, how do I constrain this signal? If this is not normal, what do I need to do to resolve the missing constraint?

I don't know verilog, but is "posedge" and "negedge" the equivalent of "rising_edge" and "falling_edge" in VHDL? If so, that is the problem because any signal attached to those keywords is giveh it's own clock network on the FPGA. Do not use those keywords with any signal that you do not want to get a dedicated clock network. Find another way. I assume you did that because you wanted the reset signal to be asynchronous, but do you actually need that reset signal to be asynchronous? And if it does, then why do the reset tasks need to check the clock as well? It's asynchronous. — DKNguyen, Mar 06 '19 at 19:43
"And if it does, then why do the reset tasks need to check the clock as well? It's asynchronous." Every verilog example I've seen for always blocks with async resets uses this (posedge clk or negedge rst_n) form. See [example 1](https://electronics.stackexchange.com/questions/163018/asynchronous-reset-in-verilog), [example 2](http://www.asic-world.com/examples/verilog/d_ff.html). — Chris Fernandez, Mar 06 '19 at 19:51
You could be on to something though. Maybe this is a clue that the async reset simply needs its own clock constraint? In which case I just need to find out how to properly constrain it. — Chris Fernandez, Mar 06 '19 at 19:53
I'm not sure about it either way since I don't use asynchronous resets, but I would look into that farther and make sure it's not an outdated or bad legacy habit that continues to be taught. There's at least a few things like that in VHDL too. I don't think a clock constraint would fix what I see as an extreme waste the entirety of one of the precious few dedicated clock networks on an FPGA just to make a reset signal asynchronous. If there's another way to make it asynchronous without needing a clock network I would definitely do that instead. — DKNguyen, Mar 06 '19 at 19:57
This article: http://chipverification.blogspot.com/2008/05/asynchronous-and-synchronous-reset.html that implies the reason you also trigger off the clock in an asynchronous reset is to get around metastability issues if the asynchronous reset deasserts too closely to the clock edge. However, it still seems like a major waste of a clock network just to do that. The only disadvantage I have found looking around for synchronous resets is the one outlined in the article where a slower clock domain can miss the reset if there are faster clocks domains present. — DKNguyen, Mar 06 '19 at 20:18
I don't think this weakness of the synchronous reset is that big a deal. It can be designed around. The more I look around the more I think the examples you mentioned are either bad habits being taught repeatedly (there were possibly carried from ASIC design and misapplied to FPGAs). Wasting a clock network is really big weakness that I can't find a way to design around. I really think the solution to avoid dedicating an entire clock network just to have an asynchronous reset is to actually just use a synchronous reset. (Assuming what I suggested really is the problem). — DKNguyen, Mar 06 '19 at 20:20
@Toor I tried out your suggestion and changed my logic to run off of synchronous resets instead, and FCLK_RESET0_N was no longer listed as an unconstrained primary clock. Switching to synchronous resets also eliminated a set of unconstrained generated clocks that I needed to figure out as well. If you want to compile your above comments into an Answer, I'll happily accept it. Thanks for the help! — Chris Fernandez, Mar 06 '19 at 22:16

DKNguyen · Accepted Answer · 2019-03-06T22:39:30.487

1

The issue is that the keywords "posedge" and "negedge" in Verilog (or "rising_edge" and "falling_edge" in VHDL) have very special meaning to the synthesizer. The synthesizer gives every signal attached with these keywords a dedicated clock routing network on the FPGA. Do not use those keywords for any signal that you do not want connected to a clock routing network on the FPGA (which obviously, should be no signal other than a clock).

It is a great waste to use one of the precious few dedicated clock routing networks on an FPGA just to have an asynchronous reset. I know of no way around this and the solution is to actually just not use asynchronous resets at all. Just use synchronous resets.

The use of asynchronous resets appears to be a practice that was carried over from ASIC design early on that has been misapplied to FPGAs and repeatedly taught turning it into a bad habit. Asynchronous resets have advantages in ASIC design that do not carry over to FPGA design due to the hardware constraints of the FPGA. One such advantage is saving gates which you can do in an ASIC since you have control over everything, but in an FPGA the flip-flops are already there and all have a clock input anyways so you save nothing.

It is interesting that asynchronous resets in FPGAs also monitor the clock signal as well. You would think this would not be necessary since the reset is asynchronous, after all, so why would it ever need to trigger on a clock at all? The reason is because if the asynchronous reset deasserts too soon after a clock edge, there are metastability issues because timings are violated. A true asynchronous reset (as one that might appear in an ASIC which is where the practice came from) would not need to also trigger off the clock to stop this from happening.

The only weakness I have been able to find about synchronous resets is that if you have multiple clock domains and improperly use the synchronous reset with only the higher speed clocks in mind, it is possible for the slower clock domain to miss the reset pulse since the reset deasserts before the slow clock can tick to register the reset pulse. However, you can protect against this by design and I do not think it is a big deal compared to using a dedicated clock routing network for something so trivial as an asynchronous reset.

edited Mar 06 '19 at 22:39

answered Mar 06 '19 at 22:34

DKNguyen

54,733
4
67
153

Paragraph 3 is wrong in every way, I'm afraid. Read the FPGA datasheets, look at register schematics: in nearly all families (certainly nearly all of those sold), registers have hardware async reset. FPGA sync reset certainly isn't logic free, it adds register input muxes to get the reset value in. That hits gate count and timing. FPGA async reset is logic free, that's why it's a better option. ASICs use sync resets. I've done ASICs as well as lots of FPGAs and CPLDs. I always check my target architecture before starting design. Have to downvote unless changed. – TonyM Mar 10 '19 at 16:31
Coincidentally, our team is going thru someone's VHDL now, changing sync resets to asyncs to free gates in big FPGA. Took taking 10s % off gate count. The logic will be rock-stable for testing over full temp' range. In last paragraph, you're not crossing clock domains properly. Drive all async resets from an async-asserted/sync-negated source reset. I've used multi clock domains at varying frequencies and pass a long source reset across to domain reset circuits that produce async-asserted/sync-negated local resets. Works perfectly, gets stable, unchanged designs across temperature and years. – TonyM Mar 10 '19 at 16:41
Regarding your statement of "not crossing clock domains properly in the last paragraph", I believe I addressed that was the case when I said that "you can protect this against this by design" which to me is the same as saying "if you design it properly". – DKNguyen Mar 10 '19 at 17:12
Now, regarding the presence of hardware asynchronous resets in all FPGA families, I'm willing to concede they exist but if you are going to claim that, please provide examples of some families and where this information is found and how to access them in VHDL/Verilog. Because it's useless just to say they exist when clearly very few seem to know how to access them. Common methods like what the OP tried treat it as a clock Don't get me wrong, it would be great if they were there but if they are, it seems few know about it or how to access it. – DKNguyen Mar 10 '19 at 17:19
For example, I'm looking right now at Tables 5-2, and 5-3 in Xilinx UG331 for the Spartan 3. "Synchonrous Reset" is in there plain as day. Asynchronous clear is not nearly as obvious. There is a "asynchronous clear". Is this what you are referring to? – DKNguyen Mar 10 '19 at 17:38
For the Artix 7, in UG474, pg 23 and 24, it does state asynch sets/resets are global or on power-up. It's still not entirely clear to me if asynch resets exist as I understand them since in the middle of pg. 23, it says says these terms but then has something extra in brackets: "Asynchronous set (preset)" and "asynchronous reset (clear)". The presence of "preset" makes me think they still might be talking about power-up and global only. There is also more information on page 52 that says they do exist more strongly. – DKNguyen Mar 10 '19 at 17:52
If the stuff on page 52 of UG474 is what I'm looking for, is there a reason they use the term "set/reset" for synchronous, but for asynchronous they use "clear/preset"? You can just add your own answer and I can remove the offending parts in mine – DKNguyen Mar 10 '19 at 17:53
I looked into it, and from what I've found, the way to get the asynchronous resets to work in an FPGA that has them is to include the Reset signal in the sensitivity list and to just check the logic state of the Reset signal like normal in the process (i.e. do not check the edge as one would with a clock since that would cause it to be interpreted as a clock signal). Can you confirm that this is correct? – DKNguyen Mar 11 '19 at 05:39
Happy to discuss but have taken it to Chat :-) – TonyM Mar 11 '19 at 11:41
Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/90875/discussion-between-toor-and-tonym). – DKNguyen Mar 11 '19 at 14:07

Vivado: Reset signal flagged as primary clock by Timing Constraints Wizard?

1 Answers1