cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Contributor
Contributor
5,113 Views
Registered: ‎05-14-2008

Practical considerations regarding reset circuit implementation as per app note WP272

Jump to solution

I have read (Get Smart About Reset: Think Local, Not Global) WP272 (v1.0.1) March 7, 2008

https://www.xilinx.com/support/documentation/white_papers/wp272.pdf

 

I have some questions regarding practical implementation of this app note.

 

My understanding is that GSR is released asynchronously with regard to clocks generated by the DCM i.e. your system clk. I assume GSR is probably released synchronous to the configuration clock CCLK. Am I correct?

 

If you have multiple clock domains in your design it is not possible to release GSR synchronous to all clock domains.

 

For these reason as in this appnote one would implement localized resets for sensitive elements like Finite State Machine such as the one on page 5.

 

Now assume I have 1 clock domain with multiple state machines in it. Do I:

(1) create identical instances of such a reset circuit for each state machine or

(2) do I create 1 instance that drives the resets of all state machines. 

 

If  option 1. Will the map and place&route automatically group the reset generator circuit (FDP registers) close to the state machines register that it drives to facilitate low skew on the reset signal?

If option 2. Do I have to use a low skew global network to distribute the reset signal from the one reset generator to all the state machines or should normal interconnect suffice?

 

What is the best practice to follow? Which option is the best?

 

Thank you

CVT

 

 

0 Kudos
Reply
1 Solution

Accepted Solutions
5,043 Views
Registered: ‎01-22-2015

Hi @cvtabc

 

    I assume GSR is probably released synchronous to the configuration clock CCLK. Am I correct?

I agree with both jmcclusk and markcurry that the GSR/GWE should not be used to form the Power-On-Reset (POR) for your project.  Xilinx has a small but powerful footnote about this following Table 5-12 in UG470 which says “GWE is asserted synchronously to the configuration clock (CCLK) and has a significant skew across the part. Therefore, sequential elements are not released synchronously to the user's system clock and timing violations can occur during startup. It is recommended to reset the design after startup and/or apply some other synchronization technique.”

 

Actually, I learned from markcurry to use the LOCKED output of a mixed-mode clock manager (MMCM) as the source for a POR -and I have been using it successfully ever since. This LOCKED signal is low at FPGA power-up and goes high after all the clocks produced by the MMCM are running and stable. So, in practice we use the inverse, nLOCKED, of LOCKED for our POR.

 

   If you have multiple clock domains in your design it is not possible to release GSR synchronous to all clock domains.

You are correct.  However, it is important that the POR for each clock domain comes off synchronously with the domain clock. This is accomplished using a device called a reset bridge, which is described nicely by the EE-Times article found <here> . -the idea being that your global POR feeds a separate reset-bridge for each of your clock-domains. The reset-bridge has the added feature of being a synchronizer, which is necessary since nLOCKED should be considered asynchronous with all clocks in your project.

 

   Now assume I have 1 clock domain with multiple state machines in it. Do I:

     (1) create identical instances of such a reset circuit for each state machine or

     (2) do I create 1 instance that drives the resets of all state machines.

Unless your project is very large and/or you are overusing resets, I find that the one reset signal created by the reset-bridge for each clock domain is sufficient. That is, I simply use this one reset signal in all processes that need a reset and let the Vivado tools figure out how to route/distribute it.   Reset signals undergo timing analysis, so Vivado will tell you if a reset needs special handling as described by jmcclusk.  As you say, processes that implement a state machine certainly need a reset. However, I find that little else really needs a reset.

 

   If option 1. Will the map and place&route automatically group the reset generator circuit (FDP registers) close to the

   state machines register that it drives to facilitate low skew on the reset signal?

It is an interesting question, but do you really care?  If your project (and its resets) pass timing analysis then just keep charging ahead.

 

   If option 2. Do I have to use a low skew global network to distribute the reset signal from the one reset generator to

   all the state machines or should normal interconnect suffice?

When the going gets tough, “Logic optimization conservatively inserts global clock buffers on clock nets and high-fanout non-clock nets such as device-wide resets.“ as stated on about page-54 of UG904.  Once again, Vivado automatically takes care of things for you so you can keep charging ahead.

 

You might also find the following post helpful.

https://forums.xilinx.com/t5/Synthesis/GSR-net-and-flip-flop-initialization/m-p/745643#M20604

 

Cheers,

Mark

View solution in original post

19 Replies
jmcclusk
Mentor
Mentor
5,091 Views
Registered: ‎02-24-2014

Alas,  the answer to your question depends on a number of factors.

 

First of all,  GSR is usually deasserted before the clock buffers are enabled (this can be changed, but it's the default).  (2nd EDIT:  After reviewing UG474, page 73, I've decided this is actually true.)  Hence there's no issue with GSR and multiple clocks...   when the clocks are all started,  the GSR is long gone.     GSR is an extremely slow net, so it's completely unusable once the clocks are started.   GSR is a DIFFERENT reset than a local reset!     Local resets are allowed to be a different value than the initial power on value determined by GSR.   Very often they are the same, but this is up to the designer.

 

Now for the subject of local reset circuits, the usual practice is to have a reset generator for every clock domain in the design.  If a global reset is desired, this is usually generated in a core clock domain, and then propagated using CDC circuits to all the other clock domains.  

 

Should you have multiple reset circuits in a single clock domain?   the answer is "Maybe", depending on your clock speed and the speed grade of your target device.  Fanout can be a serious issue for older devices using ISE as a place & route tool.   If you are using Vivado, then driver replication and fanout can be nicely handled by the physical synthesis step,  phy_opt_design.   Even extremely large fanouts can be handled if you include 2 registers between the reset generator and the load network.     Adding 2 cycles of latency to the reset network is sufficient to allow Vivado to drive ten's of thousands of reset inputs in a large design.

 

Other considerations:    Asynchronous or Synchronous reset?     In theory,  synchronous resets are better, because you don't have to worry about deassertion setup time in place and route, but in practice, synchronous resets require careful attention to avoid having them folded into the logic cones of the target logic.   In large V7 designs I've seen with big reset networks,  timing closure was actually easier with async resets instead of synchronous ones...  I traced this back to the problem of the reset being shoveled into the register input logic cones, increasing the critical paths.   There is a specific attribute included in Vivado to prevent this,  "DIRECT_RESET".    When DIRECT_RESET is attached to a net,  the mapper is supposed to map this net directly to the slice SR input, instead of the logic cone.   There is a slight penalty in mapper flexibility, since otherwise the mapper could place registers and LUTS willy nilly without using the SR input.   In some designs, that flexibility might make timing closure easier...     but usually not.  

Don't forget to close a thread when possible by accepting a post as a solution.
markcurry
Scholar
Scholar
5,053 Views
Registered: ‎09-16-2009

@jmcclusk wrote:

 

First of all,  GSR is usually deasserted before the clock buffers are enabled (this can be changed, but it's the default).  Hence there's no issue with GSR and multiple clocks...      

  


Is this documented somewhere??  I had no idea.  For us GSR is practically useless because of the concerns @cvtabc illustrated in his post, (and many others have expressed in these forums).  We've never been able to take advantage of the GSR apart from a rare few FFs in special cases.

 

If, in fact, the GSR inactive edge can be guaranteed to occur, to all FFs, BEFORE the BUFG is enabled (with some margin), then there might be a bit more utility in that signal.  WP272 might not be quite as full of bad advice as many have always advocated.  (It's still recklessly bad advice in most regards, IMHO...).

 

I have my doubts that there's any way that spec can be guaranteed.  I've a feeling that Xilinx's doesn't model that GSR for timing at all..

 

Regards,

 

Mark

0 Kudos
Reply
5,044 Views
Registered: ‎01-22-2015

Hi @cvtabc

 

    I assume GSR is probably released synchronous to the configuration clock CCLK. Am I correct?

I agree with both jmcclusk and markcurry that the GSR/GWE should not be used to form the Power-On-Reset (POR) for your project.  Xilinx has a small but powerful footnote about this following Table 5-12 in UG470 which says “GWE is asserted synchronously to the configuration clock (CCLK) and has a significant skew across the part. Therefore, sequential elements are not released synchronously to the user's system clock and timing violations can occur during startup. It is recommended to reset the design after startup and/or apply some other synchronization technique.”

 

Actually, I learned from markcurry to use the LOCKED output of a mixed-mode clock manager (MMCM) as the source for a POR -and I have been using it successfully ever since. This LOCKED signal is low at FPGA power-up and goes high after all the clocks produced by the MMCM are running and stable. So, in practice we use the inverse, nLOCKED, of LOCKED for our POR.

 

   If you have multiple clock domains in your design it is not possible to release GSR synchronous to all clock domains.

You are correct.  However, it is important that the POR for each clock domain comes off synchronously with the domain clock. This is accomplished using a device called a reset bridge, which is described nicely by the EE-Times article found <here> . -the idea being that your global POR feeds a separate reset-bridge for each of your clock-domains. The reset-bridge has the added feature of being a synchronizer, which is necessary since nLOCKED should be considered asynchronous with all clocks in your project.

 

   Now assume I have 1 clock domain with multiple state machines in it. Do I:

     (1) create identical instances of such a reset circuit for each state machine or

     (2) do I create 1 instance that drives the resets of all state machines.

Unless your project is very large and/or you are overusing resets, I find that the one reset signal created by the reset-bridge for each clock domain is sufficient. That is, I simply use this one reset signal in all processes that need a reset and let the Vivado tools figure out how to route/distribute it.   Reset signals undergo timing analysis, so Vivado will tell you if a reset needs special handling as described by jmcclusk.  As you say, processes that implement a state machine certainly need a reset. However, I find that little else really needs a reset.

 

   If option 1. Will the map and place&route automatically group the reset generator circuit (FDP registers) close to the

   state machines register that it drives to facilitate low skew on the reset signal?

It is an interesting question, but do you really care?  If your project (and its resets) pass timing analysis then just keep charging ahead.

 

   If option 2. Do I have to use a low skew global network to distribute the reset signal from the one reset generator to

   all the state machines or should normal interconnect suffice?

When the going gets tough, “Logic optimization conservatively inserts global clock buffers on clock nets and high-fanout non-clock nets such as device-wide resets.“ as stated on about page-54 of UG904.  Once again, Vivado automatically takes care of things for you so you can keep charging ahead.

 

You might also find the following post helpful.

https://forums.xilinx.com/t5/Synthesis/GSR-net-and-flip-flop-initialization/m-p/745643#M20604

 

Cheers,

Mark

View solution in original post

avrumw
Guide
Guide
4,987 Views
Registered: ‎01-23-2009

@jmcclusk,

 

First of all,  GSR is usually deasserted before the clock buffers are enabled (this can be changed, but it's the default).

 

I also have never come across any reference that implies that this is the case. Do you have any documentation that supports this idea?

 

Also, there is a new technical blog post on resets that is worth looking at (I refuse to call it the "Adaptable Advantage Blog" - too marketing for me) .

 

Avrum

0 Kudos
Reply
jmcclusk
Mentor
Mentor
4,970 Views
Registered: ‎02-24-2014

 

I am guilty of fuzzy thinking on the GSR subject, @avrum.    I just realized that GSR can't be asserted during startup, since the GSR state and the initial startup state of a register are independent.  

 

After reading UG474 page 73, it's clear that GSR sets the registers to the power on state, NOT the local reset state.  Hence GSR and local reset using the slice SR input are two very different animals.

 

UG470 on page 95 talks about the "GSR being asserted safely on startup" and this is consistent with UG474

 

What does make sense is that GWE is connected to the enable inputs of all the clock buffers in such a way that on GWE assertion, only clean and full clock cycles are emitted from the clock buffers.   If runt clock pulses resulted,  there would be no end of startup corruption problems to deal with.    But this raises the issue of how state machines connected to local clocks without a clock buffer can start up cleanly...   or can they at all?

 

Perhaps @alesea can comment on the nature of the GWE network, and how it affects clock signal startup.

 

Don't forget to close a thread when possible by accepting a post as a solution.
0 Kudos
Reply
alesea
Explorer
Explorer
4,959 Views
Registered: ‎05-08-2018

jm,

 

GSR, GWE, GTS are all global signals used by the configuration state machine during configuration.  They each havea role, and each are asserted/de-asserted in cycles of the startup.

 

GWE is pretty obvious: global write enable, and GTS: global tristate. These two do pretty much what they are named:  hold off any writing to internal registers, and tri-state all IO, and any other tri-statable internal resources (of which there may be few to none today).  GSR is less obvious as to what it does, as it transfers the DFF state to a config bit to read it out, as well as loads the initial state for a DFF from the configuration.  As part of the startup, these global signals set the initial state, and prevent any switching or transitions until "DONE goes high" insuring nothing is anything other than what is desired.

 

Using these signals after start up, for example to read out DFF states, or to tristate all IO for debugging, is pretty rare, but they are there to be used, if needed (or setting all DFF back to their INIT values).

 

After my last run-in on reset, I will refrain from stating my earlier position, and just say if your design requires resets, do be careful in how you add them.

 

Tags (1)
0 Kudos
Reply
markcurry
Scholar
Scholar
4,952 Views
Registered: ‎09-16-2009

 

 

>UG470 on page 95 talks about the "GSR being asserted safely on startup", but this makes no sense,  since assertion of GSR could change the value of a register from it's initial power on value.  

 

I'm missing this text in UG470 from 8/20/18 -   But in any event, in the context here, it's the de-assertion of GSR that's the critical part.  And the text on page 95 does indicate that the deasserted edge is quite asynchronous.

 

> What does make sense is that GWE is connected to the enable inputs of all the clock buffers in such a way that on GWE assertion, only clean and full clock cycles are emitted from the clock buffers.   If runt clock pulses resulted,  there would be no end of startup corruption problems to deal with.    But this raises the issue of how state machines connected to local clocks without a clock buffer can start up cleanly...   or can they at all?

 

There's too many grey areas to use this reliably.  First it's not clear if GWE actually does gate the BUFGs.  What if clock sources are not stable at the deassertion of GWE?  And as you stated, what if a BUFG isn't used?  And I believe GWE deasserts BEFORE GSR, so it's again moot.  The deassertion of GSR happens last.  It's edge is asynchronous, and slow -> it cannot be used reliably.

 

There's just way too many unspecified grey areas.  And yet we keep hearing from various Xilinx folks - "You're doing it wrong, don't reset, just rely on the GSR".  The advice keeps on being repeated, and repeated, no manner how many times the holes in this methodology are pointed out..

 

Regards,

 

Mark

 

 

0 Kudos
Reply
jmcclusk
Mentor
Mentor
4,947 Views
Registered: ‎02-24-2014

I was a Xilinx FAE for 12 years, from Virtex2 to Virtex7 releases..  and I never had a case where a customer could demonstrate a startup that was unreliable or unrepeatable.... except in one case where the designer had an external signal driving a local reset net across multiple clock domain, and he had omitted the CDC synchronizers, which was an obvious fail.    

 

As long as a clock buffer is used to drive the clock domain, Xilinx devices are absolutely reliable in startup coherency.   What's not completely clear to me is if that still applies to local clocks without a buffer...   those are much much rarer in typical designs, so I'm uncertain of their behavior. 

 

@markcurry  you wrote: The deassertion of GSR happens last.  It's edge is asynchronous, and slow -> it cannot be used reliably.

 

Looking at the startup timing diagrams in UG470,  GSR isn't mentioned at all.   How do you know it's deasserted last?   From a practical standpoint,  GSR  *MUST* be deasserted before GWE is asserted, otherwise all hell would break loose.

Don't forget to close a thread when possible by accepting a post as a solution.
0 Kudos
Reply
markcurry
Scholar
Scholar
4,941 Views
Registered: ‎09-16-2009

 

And I spent 4 months debugging such a reset problem.  And  the root cause was I followed Xilinx advice too closely and "relied on the GSR" for reset.

 

I documented this in a forum post - it's probably 6 years old or so - related to PCIE_CLK and the pcie reset.  Forum search isn't working well now, I can't find the post,  I'll point to it later when I find it.

 

The problem exists - contrary to many other declarations of "I've never seen the problem..  So it must not exists." Just do the analysis, it becomes apparent.  It may cause problem rarely, but it's a problem none-the-less.

 

Regards,

 

Mark

 

  

 

 

 

 

0 Kudos
Reply
jmcclusk
Mentor
Mentor
4,884 Views
Registered: ‎02-24-2014

I stand corrected, @markcurry     I can accept you got bitten by a reset bug like this...    and I'd like details, if you can find the post.

 

 

Don't forget to close a thread when possible by accepting a post as a solution.
0 Kudos
Reply
markcurry
Scholar
Scholar
4,873 Views
Registered: ‎09-16-2009

Ok, I can't find the post - so I'll summarize from memory again.

 

Xilinx goes to a lot of effort to have FPGA's with PCIE endpoints on them configure quickly - in order to meet the PCIE startup time spec.

 

So, the FPGA configures, early on in the PCIE initialization process.  Usually this means the FPGA configures before the deassertion of PERST# signal which (should) control the reset to all the PCIE logic.  It's a standard race condition.

 

And here's the thing, sometimes the PCIE_CLK isn't stable yet when FPGA configuration is done.  That's part of what the PERST# signal's for.

 

But I followed the Xilinx recommendations of using (just) the GSR - for FPGA configuration values - to initialize most of my logic on both PCIE_CLK, and the derived USER_CLK from the PCIE transceivers.

 

And guess what.  It worked.  Most of the time.  About 80-85%.  And when it failed, the failure mode really moved around.  It changed depending on cold boot, versus warm boot.  It changed with host configuration.  It would work "mostly".  The Xilinx PCIE endpoint does weird things when you let it try to initialize with an unstable clock.  It was a DEVIL of a debug session to determine root cause.

 

So, the fix - really reset the FPGA logic with a properly synchronized reset based off of PERST# (and other signals, like PLL lock, etc..)

 

Any Xilinx FPGA design should do the same for any block involving PCIE.  You can't follow the the Xilinx mantra of "relying on the GSR".  You must generate a properly synchronized reset.

 

It doesn't take much thought to see the same principle applies for many other applications - especially when your clock involves a MGT, or MMCM, or other similar device in its path.  I.e. logic clocked on anything other than a raw oscillator clock or crystal direct to the FPGA.  Contrary to what WP272 indicates, it's the RARE exception not the rule, that one can make use of the FPGA configuration time values.

 

Properly synchronizing resets is an OLD digital design topic.  It's quite well understood. and advocated by everyone - including Xilinx.  The problem occurs when someone says, "well, you don't need to follow this advice for me here, I'm the exception because foo/bar/baz...."  And then down the rabbit hole you go.

 

Regards,

Mark

4,864 Views
Registered: ‎01-22-2015

@cvtabc

 

Sometimes its kinda like "where in the world is carmen sandiego" 😊

 

I hope you're finding the answers you need.

 

Mark

0 Kudos
Reply
hgleamon1
Teacher
Teacher
4,834 Views
Registered: ‎11-14-2011

@markcurry

 

Interesting to read your PCIe reset issues.

 

While I will admit upfront that our solution cannot be met by every design, we avoided this issue by having the FPGA hold the system in reset until it was fully configured and then the system could be released and the PCIe enumerated according to the PCIe timing.

 

In this case, the FPGA (as PCIe EP) and the PCIe RC (a ComEx single board computer) were mounted on the same carrier board and the FPGA was designed to be the system reset master from the outset (which drives the software team nuts but there you go!).

----------
"That which we must learn to do, we learn by doing." - Aristotle
0 Kudos
Reply
Contributor
Contributor
4,822 Views
Registered: ‎05-14-2008

First of all. Thank you to all who have weighed in on this discussion. Also thank to those who have posted links to the other sources of information on this topic.

 

I have 1 clock domain in my design on a spartan 3 device. Yeah, yeah it is a small devices and the reason for concern should be small. But I am learning and it is better to struggle and learn the right way right from the beginning. 

 

I have decided to implement the solution proposed in  https://www.eetimes.com/document.asp?doc_id=1278998 

It seems to be the same as in Xilinx WP272 with the addition that the not_LOCKED signal from the DCM drives the reset input to this circuit. Since I have 1 clock domain there is no need fro CDCs. This reset will drive my state machines and will keep them in reset for a couple of clock cycles after the DMC have locked. The reset is then released synchronous to the clock.

 

Thank you for all your inputs and insights.

 

0 Kudos
Reply
markcurry
Scholar
Scholar
4,803 Views
Registered: ‎09-16-2009

That eetimes link isn't coming up for me (Just leads to the eetimes main landing page for me) - but in any event, I'm guessing that link describes one (of the many) methods of generating a proper synchronized (deassertion edge) reset.  Other's have chimed in here with how they do it. 

 

I'm intrigued with the possibility of using the BUFGE CE line as a possible "more optimal" reset synchronizer as markg@prosensing.com and @jmcclusk have hinted at.  I'd not thought of using that as part of my solution.  My solution has always been to generate the "typical" inactive edge reset synchronizer implemented in logic that most digital designers use for both ASIC and FPGA designs.

 

But that's the point - no matter what - you must deal with synchronizing that inactive edge of GSR one way or another - you cannot ignore it.  And the text in WP272, is irresponsible in glossing over this, and implying that you don't need to worry about it "in 99.99% of cases".   There's no global one-size fits all solution.  There's perhaps more optimal solutions that I hadn't thought off.  But WP272 is flat out reckless in the advice given.  

 

This is a common forum topic over the years here.  And it always ends the same.  It peters out with no change from Xilinx. A little later some Xilinx AE points to WP272 again, or a Xilinx post in the forums like the one Avrum pointed to above shows up.  Even in that (very recent) post, that the GSR should be the first thing looked at, and the only difficulty in using it is eliminating the actual reset in legacy code or third party IP.  Wrong again.

 

Regards,

 

Mark

 

 

0 Kudos
Reply
4,786 Views
Registered: ‎01-22-2015

@markcurry

 

I learned from you!   -and what I learned has served me well for many years.

 

In <this> post, you said “configuration != reset ”.   Amen, brother!

 

In <this> post, you OK’d my statement, “So, instead of relying on the GSR, maybe we start with the LOCKED output of the MMCM. Delay it a little (maybe differently for each clock-domain) and run it through a reset-bridge into each clock-domain. Then, maybe we've got the start of a "proper" power-on reset for our FPGA?”   This reset methodology is also proposed by the 08/10/2011 EETIMEs article, “How do I reset my FPGA” (<here>  click “Continue to Site” in landing area) and nicely summarized by the following Figure from that article.

FPGA_reset.jpg

 

Based on the footnote below Table 5-12 in UG470, “It is recommended to reset the design after startup and/or apply some other synchronization technique”, I thought Xilinx was saying that GSR/GWE/GTS alone is not sufficient to properly reset the design.  However, I agree that Xilinx’s often-cited WP272 is reckless in not discussing this further.

 

Mark

0 Kudos
Reply
hgleamon1
Teacher
Teacher
4,768 Views
Registered: ‎11-14-2011

markg@prosensing.com

 

The issue that I have with that diagram is that the reset signal is expected to be positive but, until the MMCM has lock, the output from the AND gate will be 0. As the outputs from the MMCM may toggle anyway before lock is achieved, the downstream circuits can start operation, somewhat awkwardly, before being correctly reset.

 

This may not be a problem but the designer still needs to be aware that this may happen.

 

As the AND gate must be implemented in a LUT, I prefer to fully define the truth table of the reset LUT so that there will a reset if the MMCM has no lock and/or the external reset is active, i.e.

 

ER | L | R

----------

 0 | 0 | 1

 0 | 1 | 0

 1 | 0 | 1

 1 | 1 | 1

 

This can either be done by instantiating the LUT with defined INIT properties, explicitly stating the Boolean function in a combinatorial process or an if-else chain in a combinatorial process (if the external reset is active low the truth table becomes a NAND gate).

 

A simple AND gate just doesn't quite cut it, IMO.

 

----------
"That which we must learn to do, we learn by doing." - Aristotle
0 Kudos
Reply
4,754 Views
Registered: ‎01-22-2015

@cvtabc

 

               I have 1 clock domain in my design on a spartan 3 device.

I remember using the Spartan-3 where the clock modules are called DCMs instead of MMCMs. We inverted the LOCKED output of the DCM and used it for our power-on reset (POR).  I am also recalling a problem that we struggled with for a while.  In short, the external clock sent to the DCM was taking a long time to power-up and stabilize.  The DCM simply could not handle this.  I sorta recall that the LOCKED output was going high but there was no clock output from the DCM.  Anyway, get a good external clock (that stabilizes quickly) or don’t power up the Spartan-3 until the external clock is stable.

 

             Since I have 1 clock domain there is no need fro CDCs.

You will still need a reset bridge to ensure that the POR reset comes OFF synchronously with the clock in your one clock domain.

 

Good luck!

Mark

0 Kudos
Reply
4,753 Views
Registered: ‎01-22-2015

FYI – Authors of WP272 and the referenced EE-Times articles are/were both Xilinx employees.

 

@hgleamon1

 

Thanks for contributing to this discussion. I especially liked your story about using the FPGA as master reset for a large system. I’m going to tell our system manager that we need to do this – just to see his reaction 😊 .

 

Thanks also for comments about the AND gate shown in the conceptual drawing from the EE-Times article.  Although this drawing was a starting point for our power-on reset (POR), we have modified it.  First, we do not use the AND gate and instead base our POR on NOT_LOCKED (inverse of MMCM output, LOCKED).  I think this avoids many of the problems you mentioned.  Second, we either cascade the reset-bridges or otherwise add small delays ahead of some.  The idea being that we want some clock domains to come out of reset before others.  There is a subtle difficulty associated with cascading reset-bridges that is explained in <this> post.

 

Can you share details of your FPGA reset methodology with us?

 

Finally, I somewhat cautiously recommend the paper by C.E. Cummings and D. Mills called “Synchronous Resets? Asynchronous Resets? I am so confused! How will I ever know which to use?” that is found <here>.  Cummings has written many excellent papers.  This particular paper is a good read - but I not sure I agree with all of its recommendations.

 

Cheers,

Mark

 

 

0 Kudos
Reply