IO类型选择

主要考虑四个方面，首先当然是继承上颗优秀芯片的选择，毕竟是经过量产保证的。由于人员流动，很多技术方面的考虑不一定能够完整继承下来。能弄清楚的错误当然可以改过来，很多貌似不合理的选择有时候隐藏着很偏僻的考虑，一不小心就在某种 corner case 下摔个跟头。好吧，大家哈哈一笑算了，谁让俺是个阴谋论者呢，哈哈！

如果是 input IO 的话，需要考虑一下是否是毛刺敏感的信号，是否需要用带有施密特功能的 IO，例如芯片的外部复位。这种 IO 的其它功能可能会受限。

再有就是 output IO 的驱动能力的考虑。驱动能力小了当然有问题，可能无法正常驱动外设；大了可能会增大 SSN，即所谓同时翻转噪声，也叫 SSO 效应，会增加 IO 电源的负担。驱动能力的评估要考虑 IO 上的负载大小，查查外设芯片的相关pin的负载可以计算出来。评估SSN，一是可以建立spice模型做个仿真（数字前端工程师真是万能啊，连spice都得会），二是简单计算一下 sum of driving factor （SDF），具体计算过程就是些加减乘除，可以参考 IO 的 app note，相比 spice 计算是简单多了。一般来说，除了 SDR/DDR 等高速数字接口外，其它不那么快的用 excel 做个表格把 SDF 计算计算也就行了。

最后一点就是 IO 内部的上拉、下拉选择。IO 内部之所以有这些 pull电阻，主要是防止 PIN/PAD 浮空时，从 IO 输出到芯片内的信号可以有个固定值，防止内部逻辑乱掉。有些库的 IO 的电阻是可以使能的，有些不可以。但一般都是只能选择有上拉电阻或者下拉电阻，在这两种之间选择时，需要考虑芯片将来安装到 PCB 上时，这个 IO 外部会有哪种 pull，保持一致就好了。

打住，一个 IO 的选择搞得跟找对象一样，太离谱了，其实合适最好。

写到最后忽然想起来个事情，就是在 IO mux 中，曾经有个同事把这些 mux 组合逻辑全部改写成了 always block，看起来 code 清爽了许多，貌似比 assign 后面跟若干层嵌套的？（）：（）好看？这就是仁者见仁智者见智了。