--- Quote Start ---
I cannot say which is "better", but since your question is what other people would do... I'd use the second approach.
The first approach puts an OR-gate into the reset, and this would basically make my reset de-assert asynchronous again. Well, not exactly completely asynchronous, it depends on whether rst and local_rst were generated using a register or not, so I think the timing would be safe. However, I like the idea that there is one global reset signal, which is properly synchronized, and resets the complete FPGA. If any entity can be put back into default state, then this usually happens via some "clear" signal or so, which comes from synchronous logic, and then it just makes sense to me to treat it as a regular, synchronous signal. Keeps the structure nice and clean (one reset and one clock per process).
When I have to OR some resets (e.g. a push-button reset and a PLL-not-locked reset), I put a synchronizer after the OR. Same reason: one reset and one clock per process, no hidden funky features.
--- Quote End ---
This is kind of what I was thinking. local_reset would always be the output of a flop, but I was concerned about adding delay to the async reset signal, which could cause recovery violations. I just wondered if this would be any better/worse than the equivalent setup violation. But fixing setup is just a case of adding more regs/reducing logic.
Honored Contributor
