对于design出现的undriven signal，在做formality时该怎么处理呢？
Formality通过变量verification_set_undriven_signals来控制，这个变量可以设置为：
1、BINARY
2、BINARY:X
3、0:X
默认情况下，对于undriven signal，无论是reference还是implementation design，formality都会将其设置为X，这样造成的结果是比较乐观的；
设置为BINARY的话，工具会将reference和implementation design中所有的undriven signal设置被设置为cutpoint；而cutpoint在Formality中可以被视为一个primary input，这样的话，这些cutpoint在compare时会被设置为0或1了，而不会出现X；
在这种情况下，如果在reference design中有matching compare point受这个undriven signal控制，那么在implementation design中，对应的matching compare point也必须受这个undriven signal控制；
如果implementation design中的compare point没有这个undriven signal的话，那么很可能会导致fail；
设置为BINARY:X的话，那么
设置为BINARY:X的话，reference design和implementation design中对undriven signal的处理方式不同；在reference design中，所有的undriven signal会被设置为cutpoint（与BINARY一致），而在implementation design中的undriven signal则会被设置为X value；设置为X的话，就不用担心掩盖了一些潜在的问题；
如果implementation design中有compare point由X控制，只有在reference design中的对应compare point也由X控制的情况下才会pass；
也就是说，在这个mode下，只要reference design中有undriven signals（不是unread或者没有被设置set_dont_verify）控制compare point，那就会产生failing point，即使在implementation design也有undriven signals，还是会导致fail；
这种mode可以用于debug reference design中受undriven signal控制的compare point；
设置为0:X的话，那么reference design中的undriven signal会被设置为0，而implementation design中的undriven signal会被设置为X；
这个mode的设置与DC类似，因为在DC中，undriven signal都会被tie 0；
在做formality时，对于不同的case，分三种情况来设置这个变量：
1.RTL vs RTL
设置 verification_set_undriven_signals为 BINARY
2.RTL vs Netlist
设置verification_set_undriven_signals 为 BINARY:X
3.Netlist vs Netlist
设置verification_set_undriven_signals 为 BINARY:X
使用report_failing_point -input_undriven可以report出由undriven signal控制的failing compare point；
接下来在debug这些failing compare point时，可以使用report_unmatched_points -status undriven来查看compare point的fanin中没有match的undriven signal；
参考文章：
https://solvnetplus.synopsys.com/s/article/Formality-Support-for-Undriven-Signals-1576165779962
为了保证formality的结果不要太乐观，需要设置一些RTL相关的变量让工具变得更严格一点；
Design中