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:

enter image description here

enter image description here

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
   else begin
      // do other things on rising clk edge

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?

  • 1
    \$\begingroup\$ 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. \$\endgroup\$ – DKNguyen Mar 6 '19 at 19:43
  • \$\begingroup\$ "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, example 2. \$\endgroup\$ – Chris Fernandez Mar 6 '19 at 19:51
  • \$\begingroup\$ 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. \$\endgroup\$ – Chris Fernandez Mar 6 '19 at 19:53
  • \$\begingroup\$ 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. \$\endgroup\$ – DKNguyen Mar 6 '19 at 19:57
  • 1
    \$\begingroup\$ @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! \$\endgroup\$ – Chris Fernandez Mar 6 '19 at 22:16

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.

| improve this answer | |
  • \$\begingroup\$ 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. \$\endgroup\$ – TonyM Mar 10 '19 at 16:31
  • \$\begingroup\$ 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. \$\endgroup\$ – TonyM Mar 10 '19 at 16:41
  • \$\begingroup\$ 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". \$\endgroup\$ – DKNguyen Mar 10 '19 at 17:12
  • \$\begingroup\$ 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. \$\endgroup\$ – DKNguyen Mar 10 '19 at 17:19
  • \$\begingroup\$ 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? \$\endgroup\$ – DKNguyen Mar 10 '19 at 17:38

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.