On Tue, 18 Sep 2012 07:31:18 -0700 (PDT) Carl <carwer0@gmail.com> wrote:> An article on the local/global and synchronous/asynchronous aspects > of resets: > > http://www.fpga-dev.com/resets-make-them-synchronous-and-local/Something that always seems to be missing when I read articles like this is any mention whatsoever of the FPGA’s built-in reset capabilities. For Xilinx Spartan FPGAs anyway, this is called “GSR” (global set/reset). It’s certainly global, and I believe it’s asynchronous. I don’t know what kind of skew it typically has, but it has one wonderful benefit when it’s usable: it’s absolutely 100% free. The GSR network is built into the chip whether you use it or not, so using it to reset all your FFs costs absolutely nothing in terms of LUTs and routing, something no other solution can claim. When dealing with a nearly-full FPGA, that’s a very attractive property. As far as issues of different FFs leaving reset on different clock cycles are concerned, could one not solve these issues by asserting GSR for long enough to reset all FFs, deassert it, then activate the clocks afterwards? Using BUFGCEs (in Xilinx parlance) one could do this with a very small chunk of logic, far less than the overhead of building synchronous resets by routing the reset signal around the chip and then feeding it into all the LUTs that make up feedback loops (increasing LUT count in, say, one sixth of such cases where the LUT was already populated by six inputs). Driving the ENABLE input of a canned oscillator off a shift register of sufficient length clocked by the internal configuration clock would probably achieve something similar. Am I missing something about this proposed solution? I really wish someone would write one of these articles about system reset that acknowledges the existence of GSR and compares it to other reset mechanisms and points out the advantages and disadvantages of each. Unfortunately “someone” won’t be me, because I’m nowhere near an FPGA expert and couldn’t hope to give it a proper treatment. Maybe someone has written such an article, but I haven’t seen it. Chris
Global Reset using Global Buffer
Started by ●November 27, 2007
Reply by ●September 19, 20122012-09-19
Reply by ●September 19, 20122012-09-19
On Wed, 19 Sep 2012 00:15:52 -0700, Christopher Head wrote:> On Tue, 18 Sep 2012 07:31:18 -0700 (PDT) > Carl <carwer0@gmail.com> wrote: > >> An article on the local/global and synchronous/asynchronous aspects of >> resets: >> >> http://www.fpga-dev.com/resets-make-them-synchronous-and-local/ > > Something that always seems to be missing when I read articles like this > is any mention whatsoever of the FPGA’s built-in reset capabilities. For > Xilinx Spartan FPGAs anyway, this is called “GSR” (global set/reset). > > As far as issues of different FFs leaving reset on different clock > cycles are concerned, could one not solve these issues by asserting GSR > for long enough to reset all FFs, deassert it, then activate the clocks > afterwards?Yes. Perhaps better, activate clock enable(s) afterwards. Either way, you may need a hierarchy of clock activation; after reset, you don't want your main clock generator to wait for several cycles of a (stopped) clock... - Brian
Reply by ●September 19, 20122012-09-19
On Tuesday, September 18, 2012 9:02:29 PM UTC-5, jt_eaton wrote:>If you do that then you will never run an asynchronous reset signal down to the core flops. Read Xilinx WP-231.I've read WP-231, and it best be taken with a big dose of salt, like most generalizations. Please note the date, and the applicable series of FPGAs. If we are trying to avoid religion, "never" is a very long time and is almost certainly untrue. There are many valid reasons to use an asynchronous reset, and many valid reasons to use a synchronous reset. Let's just leave it at that, without all the pontifications invoking "never" (or "always"). Besides, the OP's Q has nothing to do with async vs sync reset; both usually need to meet timing anyway. Andy
Reply by ●September 19, 20122012-09-19
>On Wed, 19 Sep 2012 00:15:52 -0700, Christopher Head wrote: > >> On Tue, 18 Sep 2012 07:31:18 -0700 (PDT) >> Carl <carwer0@gmail.com> wrote: >> >>> An article on the local/global and synchronous/asynchronous aspects of >>> resets: >>> >>> http://www.fpga-dev.com/resets-make-them-synchronous-and-local/ >> >> Something that always seems to be missing when I read articles likethis>> is any mention whatsoever of the FPGA’s built-in reset capabilities.For>> Xilinx Spartan FPGAs anyway, this is called “GSR” (globalset/reset).>> >> As far as issues of different FFs leaving reset on different clock >> cycles are concerned, could one not solve these issues by asserting GSR >> for long enough to reset all FFs, deassert it, then activate the clocks >> afterwards? > >Yes. Perhaps better, activate clock enable(s) afterwards. > >Either way, you may need a hierarchy of clock activation; after reset, >you don't want your main clock generator to wait for several cycles of a >(stopped) clock... > >- Brian >Guys, You don't need to stop the clock at all. The reset deassert to clock edge spec only applies when you are trying to change state. So if you reset the flop to 0 and have a 1 sitting on the D input then you must meet timing or it will go metastable. If you have a 0 on the D input then it doesn't matter if you meet timing. The flop will stay at 0. Most designs already do this. When an ethernet interface comes out of reset it doesn't suddenly start ethernetting, It waits for the CPU to write setup and other data before it does anything. That means that once all of its flops are in reset state then they all have that reset state applied to their D inputs until the first cpu write. You can deassert a asynchronous reset at any time as long as your asynchronous reset system is backed up with a synchronous one provided by the mission mode logic. You do have to be careful with the cpu or any other block that self starts but thats easy to deal with. John Eaton --------------------------------------- Posted through http://www.FPGARelated.com
Reply by ●September 19, 20122012-09-19
On Wed, 19 Sep 2012 09:50:35 -0500, jt_eaton wrote:>>On Wed, 19 Sep 2012 00:15:52 -0700, Christopher Head wrote:>>> As far as issues of different FFs leaving reset on different clock >>> cycles are concerned, could one not solve these issues by asserting >>> GSR for long enough to reset all FFs, deassert it, then activate the >>> clocks afterwards? >> >>Yes. Perhaps better, activate clock enable(s) afterwards. >> >>Either way, you may need a hierarchy of clock activation; after reset, >>you don't want your main clock generator to wait for several cycles of a >>(stopped) clock... >> >>- Brian >> >> > Guys, > > You don't need to stop the clock at all. The reset deassert to clock > edge spec only applies when you are trying to change state.I know. But I was being a little facetious, after one occasion when I shot myself in the foot with a synchronous reset for a DLL... - Brian
Reply by ●September 19, 20122012-09-19
On Wed, 19 Sep 2012 09:50:35 -0500, jt_eaton wrote:>>On Wed, 19 Sep 2012 00:15:52 -0700, Christopher Head wrote:>>> As far as issues of different FFs leaving reset on different clock >>> cycles are concerned, could one not solve these issues by asserting >>> GSR for long enough to reset all FFs, deassert it, then activate the >>> clocks afterwards? >> >>Yes. Perhaps better, activate clock enable(s) afterwards. >> >>Either way, you may need a hierarchy of clock activation; after reset, >>you don't want your main clock generator to wait for several cycles of a >>(stopped) clock... >> >>- Brian >> >> > Guys, > > You don't need to stop the clock at all. The reset deassert to clock > edge spec only applies when you are trying to change state.I know. But I was being a little facetious, after one occasion when I shot myself in the foot with a synchronous reset for a DLL... - Brian
Reply by ●September 19, 20122012-09-19
> >I've read WP-231, and it best be taken with a big dose of salt, like mostgeneralizations. Please note the date, and the applicable series of FPGAs.> >Andy >It's dated 2006. While that is considered old in some parts of this industry it is very modern when it comes to reset systems. The global async assert/sync deassert reset that is prevalent through out the IC world has been around since the 1980's and was derived from the board level reset systems used back in the days of disco. The important thing about WP-231 is that it was written by the engineers that are the experts on the silicon and tools and provides very specific examples of why decades old design practices are not optimal for todays deep submicron processes A lot of advice that you hear from component designers is out of date and should be ignored, but when the people who wear bunny suits at work give you advice then you really need to listen. John Eaton --------------------------------------- Posted through http://www.FPGARelated.com
Reply by ●September 19, 20122012-09-19
jt_eaton <1590@embeddedrelated> wrote: (snip)> You don't need to stop the clock at all. The reset deassert to clock edge > spec only applies when you are trying to change state. So if you reset > the flop to 0 and have a 1 sitting on the D input then you must meet > timing or it will go metastable. If you have a 0 on the D input then > it doesn't matter if you meet timing. The flop will stay at 0.More specifically, if your FFs have a clock enable input, and you can be sure that they are not enabled as they come out of reset, then you don't have to worry about the clock timing.> Most designs already do this. When an ethernet interface comes out of > reset it doesn't suddenly start ethernetting, It waits for the > CPU to write setup and other data before it does anything. > That means that once all of its flops are in reset state then > they all have that reset state applied to their D inputs until > the first cpu write.There has to be at least one FF with the enable determined though outside logic, but that should be usual in the case of a processor.> You can deassert a asynchronous reset at any time as long as your > asynchronous reset system is backed up with a synchronous one provided > by the mission mode logic. You do have to be careful with the cpu or any > other block that self starts but thats easy to deal with.-- glen
Reply by ●September 19, 20122012-09-19
On 19/09/2012 15:38, jonesandy@comcast.net wrote:> On Tuesday, September 18, 2012 9:02:29 PM UTC-5, jt_eaton wrote: >> If you do that then you will never run an asynchronous reset signal down to the core flops. Read Xilinx WP-231. > > I've read WP-231, and it best be taken with a big dose of salt, like most generalizations. Please note the date, and the applicable series of FPGAs. > > If we are trying to avoid religion, "never" is a very long time and is almost certainly untrue. > > There are many valid reasons to use an asynchronous reset, and many valid reasons to use a synchronous reset.Right! http://microelectronics.esa.int/asic/fpga_001_01-0-2.pdf Skip to section 3.1. In a nutshell, the Nasa Wire satellite was lost due to the use of a synchronous reset. Hans www.ht-lab.com> Let's just leave it at that, without all the pontifications invoking "never" (or "always"). > > Besides, the OP's Q has nothing to do with async vs sync reset; both usually need to meet timing anyway. > > Andy >
Reply by ●September 19, 20122012-09-19
In article <47cbefa7-3c40-4131-974e-0a1a09b61d3f@googlegroups.com>, Carl <carwer0@gmail.com> wrote:>An article on the local/global and synchronous/asynchronous aspects of resets: > >http://www.fpga-dev.com/resets-make-them-synchronous-and-local/Okay, long post - this should probably go somewhere else, but here's my reponse - it's some ideas that I've often thought of when seeing this advice like this, but never get "pen to paper" as it were. Thinking about resets are good, and having a good strategy, very important, but I disagree with a lot of this advice. And this type of advice been coming out of the FPGA companies for a while. But here's my 4 cents. (Too long for just 2 cents.) I come from an ASIC background - where logic's cheap. ( I know this is an FPGA newsgroup - bare with me. ) There, for all of our designs we used a global resets streategy, which ASYNCHRONOUSLY reset FFs. i.e. in verilog: Example 1. reg foo; always @( posedge clk or negedge reset_n ) if( ~reset_n ) foo <= 0; else foo <= bar; The reset_n input to the module was generated near the top level of the chip. At the top level, the main system reset would have it's de-assertion edge synchronized to each clock domain - effectively creating a per-clock reset signal. (I'm leaving out a LOT of qualifiers for this including control of reset during test, etc. But the key, the resets are generated at the top-level globally). Furthermore, we reset EVERTHING that could be reset. The requirements for the reset to work: 1. The input reset needs to be appropriately de-glitched to avoid false assertions or de-assertions. 2. It's pulse width large enough to be capture by the async input (on the order of nanoseconds) That's it. You meet the above requirements, you'll safely enter the reset state. You'll succesfully exit the reset state - once the reset de-asserts AND THE CLOCK is running. If the clocks not running, you'll stay reset. The advantage of this approach: Point 1. - You're always right. You can't hurt anything be resetting a FF. Point 2. - Simulating bringup is faster - perhaps MUCH faster. I've spent sometimes weeks chasing the "sea-of-red" bring ups in simulation - the results of X-Pessimism. I've seen all sorts of kludge "demeta" tricks in simulation to work around these issue - and there just that - Kludge testbench work that usually offers nothing towards to the reliability of the design. Point 3. - Reducing X's in simulation (by resetting everything) also reduces the chances of X-Optimism. A much lower occuring problem, but one with a larger penalty if missed (RTL sim vs. gates mismatch). The disadvantages - it's not optimal. You may waste resources distributing the resets, and meeting the timing of the reset recovery path. Note that all modern STA tools have no trouble checking this timing. Ask any business manager if this is the correct priority: 1. Correct, and Reliable. 2. Faster debug and verification. 3. Optimal You won't get much argument. And that 3rd objective will probably be MUCH lower that the first two. The amount of logic "wasted" on this strategy, is tiny in this deep sub-micron age. We even used the same clock tree methodology for distributing the resets. Wasteful - sure. But who cares? After a while of that I came over to FPGAs. FPGA's haven't been designed to waste a global low-skew route on this async reset. So, I switched to using synchronous resets: Example 2. reg foo; always @( posedge clk ) if( ~reset_n ) foo <= 0; else foo <= bar; Again the reset is generated globally, with de-assertion edge synchronized to respective clock. The requirements for reset to work : same as above PLUS: 3. You're clock must be running to enter reset. A normally simple-to-meet requirement, but can lead to perplexing debug in areas around non-free running clocks (i.e. around PLLs, and other clock-management logic). Again, I reset EVERYTHING that can be reset. This strategy is not too different that the first. Some extra head-scratching to be sure we're okay with extra reset requirement. But in general it works. The advantages and disadvantages of this approach are similar to the first case. The back end tools must meet timing on all reset paths. All FPGA tools will check this - the reset's basically just like any other signal, albeit usually with a larger fanout. To alleviate the large fanout - if it's even a problem, I can just pipeline it (at the top level - globally!) a few times. Then allow the tool to do any neccesary register duplication and perhaps register balancing. The back end tools have solved this problem for me. This leads my next evolution in resets: "Selective" reseting. As many designers are apt to point out, EVERYTHING does not need to be reset. This is true. Datapath logic is probably safe to leave un-initialized. Example 3. reg [ 7 : 0 ] foo_data; reg foo_control; always @( posedge clk ) if( ~reset_n ) begin foo_control <= 0; //foo_data <= 0; end else begin foo_control <= bar; foo_data <= some_data; end Here the control signal "foo_control" is reset. The datapath element "foo_data" is not. And I usually code it just as above with the reset clause explicity commented out. The advantage of this approach - we can pick up a lot of optimizations over reseting everything. Especially in targetting delay shift registers (i.e. SRL16s in Xilinx). But the disadvantages - slower coding, and the risk of missing a needed reset. When I'm coding a low-level module - possible one that's going to be shared across many FPGAs- I need to stop and think a bit more on what must be reset, and what's safe to leave uninitialized. Do I know of all use cases of this module? Will it be safe in all cases to not reset this signal? This is often a hard requirement to decide. You aften don't have all the information at the time of the coding to make this decision. So often I punt and leave the reset in - especially when I bringup first testbenches and see that dreaded "sea-of-red". If I suspect its got ANYTHING to do with that uninitialized signal - that reset's going back in. I can always go back in and re-comment out the reset assignement, to be more optimal. But once the design is right how often will a designer be given the time to go back in and make it more "optimal"? Probably only when pushed into a corner. The last style, often touted by FPGA companies, basically boils down to - don't reset at all. The design comes up out of FPGA configuration in a known, default state. Often the synthesis tools can be configured to adjust this default state with init values: Example 4. reg [ 7 : 0 ] foo_data = 0; reg foo_control = 0; always @( posedge clk ) begin foo_control <= bar; foo_data <= some_data; end I.e. the synthesis tool uses the verilog init value as the configuration time value. Here, reset's are the exception not the rule. Only reset those very few elements that explicitly require it, and must see that edge. Advantages of this : an optimal design. The biggest drawback... FPGA Configuration is usaully NOT equal to RESET. Most of my boards have at least some kind of push-button reset, probably another controlled by some sort of processor. This reset is a distinct operation - quite seperate from FPGA "CONFIG". Plus, well, I'm very hesitant with this approach. Reset and initialization problems can lie hidden for a long time. During bringup, often a lot of things are in flux, and a random init problem is often written off as some random event, and ignored. "Hey I just ran it again it worked this time." So the problem lies hidden much longer. Months down the line when my manufacturing line ( or worse - customer ) comes back to be and says, "Hey I sometimes have to reset this thing twice to get it to work". I'd be MUCH more comfortable in this situation knowing that I had a solid reset in my FPGA design. "Correct and Reliable" has priority over "Optimal" for me. Regards, Mark
