Hi, all: The FFs can be reset synchronously or asynchronously. And in ASIC design, the FFs with asynchronous reset will be "smaller". But in FPGA design, will the FFs with asynchronous reset perform better than the ones with synchronous reset? Or, is the kind of reset just an "option" for the FFs instantiated?
I am not sure why you put it into quotes but this statement is almost definitely false. I've never seen an ASIC library where the async reset flops were not larger in area than non-reset flops from which one usually makes the sync flops. Non-reset flops are also usually faster and the resulting design is faster again because one usually has a path in the logic which resets the flop so the sync reset gets merged with that path.
mk =E5=86=99=E9=81=93=EF=BC=9A
Thank you for your answer, and what you say is about ASIC or FPGA? I want to know the performance of the two kind of FFs in FPGA.
Thank you once again.
'Better' I'm assuming to mean clock performance. If that's the case, then from what I've seen performance is not usually affected. Mike Tressler has also captured some performance numbers with a single design using various tools targetting a couple different devices (see link below, then click on 'Reference Design Source' and scroll down to the bottom). He has a bit of a problem in his methodology of obtaining the performance numbers but even there it seems to be a mixed bag as to whether synchronous or asynchronous is better. The important thing though is that it is attempting to fairly measure different techniques.
A lot of times, the logic preceeding a flip flop inside an FPGA can accomodate an extra input (i.e. reset) without impacing performance in any way simply because the final LUT has an otherwise unused input. In those cases, sync performance would be the same as async. On the other hand if there were no spare inputs into the final LUT (and nowhere upstream where it could be added either) than an extra level of logic would be required which would impact performance.
On the async side, you're basically chewing up a routing resource and dedicating it exclusively to resetting flip flops. Generally this will tend to happen on some global routing resource so it won't much matter but other times that is not the case and it will impact performance for selected flops.
From the perspective of timing analysis, since the reset input almost always needs to be synchronized to the clock(s) anyway (unless the clock is guaranteed to not be running at the conclusion of reset) then now you have the situation where the output of a flip flop can occur at two distinct times: one being the clock to output delay of the flop, the second being the reset to output delay of the flop....presumably the timing analysis software analyzes both paths.
Over the years, I've also noticed that designers who perfer to use async resets tend to misuse them more than those who use sync resets. Misuse meaning not syncing reset up to the appropriate clock or not paying careful attention to how it is routed on a printed circuit board and picking up noise that resets things, or forgetting about the timing path through the flop in response to this reset signal (again from a board design perspective, inside an FPGA the timing analysis software 'should' know this). Since a designer can misuse a sync reset almost as easily, I'm not really sure why I've noticed this trend but I have.
Even from the perspective of just writing the code, using async method and the generally used template presents some challenges that in certain cases can result in gated clocks being generated. The 'certain cases' being if you have a single VHDL process where some of the outputs are asynchronously resetable and other outputs are not. Peruse the comp.lang.vhdl discussion titled 'alternate synchronous process template' (starting on June 15, 2006) for more. The generally used template for synchronous resets does not have this problem.
In most cases, there is no actual functional performance reason for using async or sync so either can be used. Some will argue that if there is no clock then you must use async but that is not really true...'specially when you remember that you'll probably have some form of shift register for synchronizing reset to the clock anyway. Then you can have the shift register be async resetable but the entire rest of the design be sync reset. Again, in that same comp.lang.vhdl thread you can read some back and forth about using one versus the other.
Bottom line from what I've seen over the years is that in FPGAs, as a general rule it doesn't much matter. In a specific instance it might...but which way will be better in that specific instance is a coin toss.
KJ
Yes, it is a collection of benchmarks from volunteers. Some is incomplete and some is from synthesis estimates, but I prefer to publish what I have, and verify it as I can. I agree that the reset pulse must be synchronized in any case and that utilization and performance has no strong correlation to reset style.
-- Mike Treseler
I think what you are asking is why the maximum clock frequency is higher with an async reset than it is for a synchronous reset using the sync reset pin of the Xilinx FPGA ff's. If so, it is because of two things: first, the async resets are not included in the static timing analysis, so they are not limiting the clock performance when you've used async resets, and second the reset pin on the ff's is quite a bit slower than the path through the LUT and the D input. If you absorb the sync reset into your D input logic, (and take the steps to make sure the synthesizer isn't pulling it out and using the reset pin) you'll probably see the clock performance match the async performance unless adding the reset pushes the logic to more than 4 inputs.
This is for ASIC. For FPGAs all the cells are already hard-wired. I haven't looked carefully but I doubt the timing of the DFFs in any FPGA depends on whether it's configured for async/sync or no reset. In a way you can assume that the async input is still there but it's tied to in-active always and that doesn't change the timing of the cell. In an ASIC, you use a different cell.
Ummm....regardless of the technology the timing depends totally on whether or not the async inputs are used or not.
If only sync resets are used then the output of the flip flops will occur after some 'clock to output' delay after the appropriate edge of the clock.
For async resetable flip flops, the output can change at TWO distinct times, the first being the above mentioned 'clock to output delay', the other being the 'reset to output' delay.
You certainly can't count on the clock and reset routing delays and the 'xxx to output' delays to happen to add up to be the same, you have to do the timing analysis. No matter how you slice it, using async inputs to a synchronous element will always cause you to analyze the path that leads through the clock input and the other that leads through the async input, there are no shortcuts.
KJ
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.