I didn't mention physical implementation (if that's what you mean by "physical design", "physical design" is a term which would describe the process of doing a full custom design directly in schematic/layout without even using design techniques such as Verilog) because async/sync is part of the digital architecture of the hardware.
I feel I don't understand what you are trying to say, you just dismissed by entire comment without address any of the things I mentioned.
> Asynchronous resets are fundamental because they are not dependent of the presence of a working clock.
Yes. And a clock is fundamental because without one, your design wouldn't work either. :-)
So there's little point in worrying about your flip flops not having a defined value before the clock is present.
> Imagine that you have a system working on synchronous reset: if your entire system breaks, including the PLL which generates the clock, and you want to reset it, how are you going to do it if the clock is not working in the first place?
For core logic (which is 99.9999% of your gates), it doesn't matter that they don't get a defined state in the situation that you describe.
For the few signals where you actually care about a defined state (IOs or PLLs or whatever), you still connect the async reset. Problem solved.
> Also, a reset signal is asynchronous by nature, if you wanted to use synchronously to your system's clock, you would need to add extra hardware to bring it to your clock domain. And this would expose it to possible metastability problems.
You use exactly the same reset synchronizer that you use with your asynchronous reset. After all, even when using async resets, you release the reset synchronously as well. The difference between async and sync resets is in the FFs, where the reset is connected to the D input instead of the C input. It's not in the way the reset is generated.
> I didn't mention physical implementation because async/sync is part of the digital architecture of the hardware.
That's interesting, because the async/sync reset decision was almost entirely driven by the backend related considerations.
I already mentioned one of the biggest problems with async resets: it exposes your design to glitches at all times, whereas sync reset only exposes you during a clock edge. In other words: sync resets inherently make your design more resilient against non-digital secondary effects.
> you just dismissed by entire comment without address any of the things I mentioned.
I dismissed them because they are trivial to work around in the front end and they can be simulated. And because once you fix them, they'll never come back during the next layout spin.
On the other hand, a backend issue will reappear: it doesn't matter how many crosstalk related ECOs, you'll have to start all over again if there's a spin.
Choosing between async and reset is matter of trade-offs. They both can work very well. And they each have benefits and disadvantages. You're doing yourself a disservice if you just dismiss one just because it was always done that way.
I feel I don't understand what you are trying to say, you just dismissed by entire comment without address any of the things I mentioned.