1024这天爆出来的设计失误，真的很应景啦！
先献上A72的reset结构图吧，虽然最终的解决方案不是按照这个来的，不过也给了一个相对较清晰的reset架构了。
异步复位树
当对整个电路进行复位的时候，使用异步复位，所有的DFF都清楚现在是复位状态，需要输出复位值，此时不需要时钟与复位信号之间进行check。但是当复位信号失效的时候，即reset deassertion时，需要进行recovery time 和 remove time的check，因为此时的DFF需要将D端的值输出给Q端，而不是输出复位值，那么DFF就需要清楚此时是否是复位状态。如果不满足recovery time或者remove time的话，就会产生亚稳态，DFF并不清楚此刻的状态假如现在是一个子系统，那么此时就会出现有一部分DFF是复位的有一部分DFF是解复位的状态，整个子系统可能会出错。
所以我们需要引入同步复位的优点，所有的DFF都是同步的。
使用异步复位同步释放的电路来解决这个问题。
那么问题又来了，当整个系统过于庞大或频率过高的时候，端口处只做2级的sync是不够的，像文章开头ARM A72的设计一样，会对reset进行reset pipeline打拍，从顶层的port口传到下面的Block中，以此来确保整个subsystem的reset时序满足。A72的sdc中会根据上面的结构对reset设置set_multicycle。
铺垫了这么多，理清了为什么需要这么做，以及在设计过程中有什么样的设计方法来解决这些问题。那么当在项目后期了，底层的设计忽略掉了reset 的架构，导致中后端的physical 设计无法实现怎么办呢？
reset详解：异步复位，同步释放 - 大地丶 - 博客园
异步复位和同步释放_异步复位同步释放-CSDN博客
)
问题探讨与实践)
