useful skew和前端如何定位后端中instance的两个问题

请教两个问题：
(1) 如果发现时序报告中，launch edge是rising edge，capture edge 是falling edge 也就是说这是个half cycle check，
时序报告中的startpoint 和 endpoint 都是网表例化的名字或pin。如果需要向前端确认这里的 half cycle check 是不是正确的
而因为前端代码中没有网表例化的名字，那么前端是如何确认的呢? 他们是如何定位的呢?
(2) 看了手册也看了eetop上相关东西，都有讲到 “useful skew的一个缺点是容易造成其他mode下的新的violation” 请问这是什么原因?
那我觉得在修hold的时候，用的是insert_buffer的方法，这个和useful skew的一个不同是 前者是在data path上插入buffer，后者是在
clock path (到一个DFF ) 上插入buffer，那为什么没人提，用insert_buffer修hold也容易在其他mode下引起时序问题呢?

如上图，中间那个DFF利用useful skew，但只是在它的path上插入了一个buffer，并不影响clock tree的其余结构啊，怎么就容易在其他mode下
带来新的时序问题了呢?

(1)把netlist也发过去
(2)修hold也容易引起setup问题啊。如果说区别，恐怕就是ocv吧

是不是因为在其他MODE下你使用USEFUL SKEW时在clock path上插入的Buffer会导致FF2和FF3之间的set_up 出现violation，因为你这样插入Buffer会导致data path过长吧 不知道对不对 嘿嘿

求“useful skew的一个缺点是容易造成其他mode下的新的violation”的出处。谢谢

你碰到问题了也就知道了， 不需要预防不会出现的问题， 有时候问题来了你自然就知道了，

版大看问题已经上升到哲学的高度了！

标题

很有深刻哲理的话。佩服

主要是问题太多了， 要是都预防会很累，