数字设计新人简单直接点，我一般看这几个关键指标：
WNS和TNS是首要关注点，告诉我问题有多严重。
然后看违例路径数量，如果就几条，手动优化；如果成百上千条，得考虑架构调整。
分析关键路径时，我重点看LUT和布线延迟的比例。理想情况下LUT延迟占主导，如果布线延迟超过50%，说明布局有问题。
时钟偏斜要小，特别是高速设计。如果偏斜接近时钟周期的10%，就得优化时钟树了。
最后检查时序约束覆盖率，确保所有路径都被正确约束，没有漏网之鱼。
经验告诉我，早期发现时序问题比后期修复容易得多。所以在设计阶段就要预估时序，写代码时注意逻辑级数控制，而不是等实现完了再补救。
我主要关注三个方面：时序报告本身、约束质量、以及设计特征。
时序报告里，除了常见的那些，我会特意看“最差路径拓扑”。有时候最差路径不是逻辑路径，而是时钟路径。如果时钟路径延迟大，会影响所有相关寄存器。
约束质量方面，检查输入输出延迟约束是否合理。很多时序问题其实源于错误的IO约束。还有生成时钟（Generated Clock）的约束，这个容易出错。
设计特征方面，看设计是否对时序特别敏感。比如有没有很长的组合逻辑链？有没有高扇出网络？有没有跨die的信号？这些特征需要特别处理。
另外，我会评估时序收敛的稳定性。有些设计虽然这次编译通过了，但稍微改点无关逻辑时序就崩了，这说明裕量太小。好的设计应该有一定的时序冗余度。
面试时可以问面试官他们公司的典型时钟频率和器件型号，然后针对性地谈该器件系列的特性，比如Xilinx UltraScale+的时钟结构和7系列有什么不同，体现你的器件知识。
除了静态时序分析报告，我还会结合其他工具和报告来综合评估。
比如看布局布线后的资源利用率热图。如果某个区域逻辑密度很高，那块的时序肯定紧张。可能需要手动布局或者调整层次结构。
还有功耗分析报告。功耗大的区域温度高，温度影响晶体管速度，高温下时序可能失效。所以高温区域的路径要留更多裕量。
对于高速设计，我会关注信号完整性分析。串扰（Crosstalk）会影响实际延迟，这个在标准时序分析里可能没充分建模。
面试时可以提到，有经验的设计师会在时序约束里加额外裕量，比如设置20%的时钟不确定性，而不是只用工具推荐的最小值。这是为了应对芯片老化、电压波动等实际因素。
最后强调，时序收敛不是一次性的，要在不同PVT条件下验证。尤其是工业级、汽车级芯片，要检查高温低压等最差情况下的时序。
关注点可以按设计层次来组织回答。
架构层：看时钟结构是否合理。多个时钟域？同步还是异步？PLL输出时钟的相位关系？这些高层决策对时序收敛影响最大。
模块层：看各个模块的时序裕量分布。是不是某个模块特别差？可能是那个模块的代码风格有问题，或者逻辑太复杂需要重构。
路径层：深入关键路径，看是组合逻辑太长还是布线延迟太大。组合逻辑长就插寄存器；布线延迟大就加位置约束或者复制驱动。
器件层：看是否用到了器件的特殊资源。比如UltraRAM、DSP块这些硬核的时序特性与普通逻辑不同，需要特别关注。
另外，我会检查时序约束的完整性。有没有漏约束的时钟？输入输出延迟约束是否合理？假路径和多周期路径约束是否正确？约束文件的质量直接影响时序分析结果。
从工程实践角度，我会这样回答：
首先强调时序收敛是个迭代过程，不能只看最终报告。我会介绍我在项目中的实际流程——先跑一次初始实现，看时序违例情况，然后根据违例类型采取不同策略。
如果是局部违例，比如就几条路径违例，我会手动优化这些路径的RTL代码，或者添加位置约束。
如果是全局性违例，WNS和TNS都很大，那就要考虑降低时钟频率、重新划分流水线、或者优化架构了。
面试时可以举个具体例子：曾经有个设计时序不收敛，分析报告发现关键路径都在一个复杂的状态机里。后来把状态机拆分成两个小状态机，用流水线方式协作，时序就收敛了。这样的实际案例比理论分析更有说服力。
还要提一下不同优化策略的取舍。比如用更多流水线寄存器会改善时序但增加延迟；用更大扇出驱动会减少线延迟但可能增加功耗。要根据设计需求权衡。
我补充几个容易忽略的点。
一个是时钟门控（Clock Gating）检查。如果设计里用了门控时钟，要确保时序工具能正确分析这些路径。有些工具需要特殊约束才能分析门控时钟的时序。
另一个是异步复位恢复时间检查。异步复位路径的恢复时间（Recovery）和移除时间（Removal）违例，会导致寄存器进入亚稳态。这个在时序报告里是单独的部分，很多人只看同步路径。
还有最大延迟约束（Max Delay）。除了建立保持时间，有些路径对最大延迟也有要求，比如某些控制信号。我会检查这些约束是否满足。
最后说下报告的可读性技巧。时序报告通常很长，我会用工具的命令行选项过滤出感兴趣的部分，比如只显示某个模块的路径，或者只显示延迟大于特定值的路径。这样分析效率高。
我觉得体现经验的关键在于，不仅知道看什么，还知道怎么看背后的原因。
比如看到一条关键路径，我会先看它的逻辑级数（Logic Levels）。如果级数太多，比如超过10级LUT，那就要考虑流水线化。如果级数很少但延迟还是大，那很可能是布线问题。
然后看路径上的单元类型。是不是用了很多进位链（Carry Chain）？进位链虽然快但资源特殊，可能会引起布局拥塞。是不是用了三态缓冲？三态的内部延迟比较大。
还要关注路径的起点和终点。如果是寄存器到寄存器，那相对好优化。如果是IO到寄存器或者寄存器到IO，那受引脚位置限制大，优化空间小。
面试时如果能结合具体元件类型分析，比单纯说“看延迟数字”要专业得多。
说点实际的，除了那些标准指标，我还会特别关注跨时钟域路径（CDC）的时序报告。
虽然CDC路径通常设为false path，但面试时可以提一下，有经验的工程师会检查这些约束是否正确，避免漏掉该约束的路径。
还有IO时序，这个容易被忽略。FPGA和外部器件接口的时序是否满足？建立保持时间够不够？需要结合板级延迟一起分析。
另外，我会看时序报告里有没有大量的互连延迟（Interconnect Delay）。如果线延迟占比太高，说明布局不好，逻辑太分散。这时候优化代码效果有限，得从布局约束入手。
最后提一下多周期路径（Multicycle Path）的约束检查。如果设计里用了多周期路径，要确保约束写对了，否则工具会按单周期去优化，白白浪费资源。
我一般会分三步走：看全局、抓重点、定策略。
第一步看全局总结报告，关注WNS（最差负裕量）和TNS（总负裕量）。如果TNS很大但WNS不大，说明违例路径很多但都不严重，可能通过提升布局布线质量就能解决。如果WNS很大，那必须找到那条关键路径重点优化。
第二步深入关键路径细节。我会逐级看路径上的每个元件延迟和线延迟，找出瓶颈在哪里。是LUT级数太多？还是布线绕远了？有时候高扇出导致线延迟暴增，这时候就要考虑插入寄存器或者复制逻辑。
第三步结合其他报告交叉验证。比如看资源利用率报告，如果某些区域利用率超过80%，那块的布线延迟肯定大，时序难收敛。这时候就要考虑面积约束或者重新划分模块了。
这样回答能体现你是有方法论而不仅仅是看报告。
除了Setup/Hold，我会重点关注时序报告里的这几个部分。
首先是时钟网络的质量，看时钟偏斜（Clock Skew）大不大。如果Skew太大，说明时钟树没做好，即使逻辑路径时序够了也可能出问题。
然后是时钟不确定性（Clock Uncertainty），这个值包含了时钟抖动（Jitter）和额外裕量。面试时可以说，我会评估这个值是否合理，过大的Uncertainty会吃掉宝贵的时序裕量。
关键路径（Critical Path）的分析不能只看最差的一条。我会把前10条或前20条违例路径都拉出来看，分析它们是否有共同模式，比如都经过某个高扇出网络，或者某个特定的模块。这样修复起来更有针对性。
最后别忘了看时序裕量（Slack）的分布。整体负Slack有多大？是集中在少数路径还是广泛存在？这决定了修复时序的难度和策略。
