01-24-2019 08:55 PM
My FPGA device is Zynq MPSoC, and using over 300MHz clock on PL.
Some timing issues in my design now, but its difficult to solve this because logic resource is over 80% now.
So now I want to shrink logic, and improve performance.
In this document said, sync reset is improve performance.
But this document is legacy document.
In MPSoC, sync-reset or async-reset, which reset type is the best for performance?
01-25-2019 04:22 AM
Regardless of any performance increase, synchronous resets always should be used insted of asynchronous resets. Every input to FPGA logic has a window of time (setup/hold) in which that input can safely change. An asynchronous input (even a reset) can lead to unexpected operation when if changes outside of the safe window. In the case of the reset, the problem could occur when the reset de-asserts. An IP that indicates its reset can be asynchronous actually contains logic to synchronize that reset input to the IP's clock before using it.
However, vast designs running at a very high speed often have timing trouble with global synchronous resets. One remedy is to pipeline resets such that different sections of the design are reset (and un-reset) in stages, using a chained synchronous reset to affect different sections at different times.
01-25-2019 04:39 AM
If your goal is to reduce the logic within your design, I don't think the difference between synchronous and asynchronous resets will help much. Instead, consider only applying the reset to those pieces of logic that actually need it, breaking various processes up as necessary to make that happen.
01-28-2019 06:22 AM
Thankyou for reply.
I understand about asynchronous reset issue.
My design is asynchronous reset, but reset de-assert is syncronous to clock.
In this document says, synchronous reset can decrease logic resources than synchronous.
I want to decrease logic utilization, so I want to know this document's methods is available in MPSoC.
01-28-2019 06:27 AM
Thankyou for advice.
That is good idea, because my desing has many calculation modules, but this module doesn't need reset.
I remove reset from my design later, and check utilization.
01-28-2019 06:48 AM
Most of that whitepaper discusses strategies to increase system performance. The benefits to overall area aren't as profound.
Page 5 of that WP shows how the synthesizer can incorporate the reset signal into its optimization of logic, thereby reducing the resources needed to implement the synchronous reset. There's nothing special about the MPSoC logic when it comes to the effectiveness of Vivado to optimize properly-coded HDL--considered against comparable Ultrascale+ devices. You can expect consistent behavior from the tools.
I assume you're now also talking about this statement below Figure 5 on page 7:
"Because most of the logic in a design is synchronous, using synchronous or no reset at all allows for further design optimizations, reduced area, and optimal performance."
Using a synchronous reset removes the need to synchronize it locally, which additionally can save an entire CLB worth of synchronization registers. That's not a lot. The bigger bang comes from using no reset where one is not really necessary. @dgisselq has a link above to a very good page that discusses this matter. (I added a Kudos to that, to encourage you to check it out.) If you omit resets on your data pipe, and use minimal synchronous resets in your control structures, you will achieve optimum area for a given level of performance.
01-28-2019 08:20 AM
No reset at all,
As the FPGA fabric (programmable logic or PL) is set to the desired initial states by configuring, a reset is only needed if you wish to restore/reload values to a bock of logic (like a state machine).
So, best to not reset anything that doesn't actually require a reset, but to rely on the built in reset/set which is part of the PL.
A contraversial subject, as some few do not use the configuration reset/set, and instead create their own solution which clogs up the design, and makes meeting timing far more difficult. No doubt we will see a conflicting comment in a few hours of this posting.