上文提到，进行最小/最大延迟约束时，set_max_delay和set_min_delay命令要设置-from和-to选项。但是如果起点和终点设置的不合理（具体见第33篇），便会导致出现路径分割（Path Segmentation）。
非法的起点
下面举一个例子说明，如果-from设置了一个非法的起点，时序引擎会阻止经过该节点的时序的传递，从而这个“非法的”起点变得“合法”。如下图：
FD1单元中唯一合法的起点只有C端口，即“set_max_delay 5 -from [get_pins FD1/C]”。但如果将起点设置为Q端口，时许引擎便会阻止通过C->Q的时序弧，从而Q变成了一个合法的起点。这个阻止时序传递并创建一个合法起点的过程便是路径分割。
路径分割并不是一个好的现象，它会影响到最大和最小延迟分析，以及所有经过这些节点的时序约束。如下图所示：
对于以Q为起点的路径，启动时钟不会考虑时钟插入延迟。但是在路径终点处（FD2/D）仍会计算插入延迟，这就可能导致比较大的时钟斜率。总之，应该尽量避免出现路径分割现象，如果不得不必须使用也要非常小心。如果出现了路径分割，Vivado会提示一个严重警告。
路径分割会导致该路径上没有保持时间需求，如果需要的话，可以使用set_min_delay命令为该路径设置一个保持时间需求（在没有用-datapath_only的情况下）。一般来说，路径分割总是能避免的，比如上例中，如果只是不想考虑时钟斜率而把FD1/Q作为起点，完全可以用-datapath_only选项达到此目的：
set_max_delay 5 -from [get_pins FD1/C] -datapath_only
非法的终点
与上例相同，如果-to设置了一个非法的终点，时序引擎会阻止该节点之后的传递，从而这个“非法的”终点变得“合法”。如下图：
如果约束为“set_max_delay 5 -to [get_pins LUTA/O]”，LUTA/O作为组合逻辑单元的数据输出管脚并不是一个合法的终点。但是时序引擎会阻止LUTA/O之后的传递，使其成为一个合法终点。
所有经过LUTA/O的时序路径的建立和保持都会受到影响。从上图看到，计算时只会考虑从REGA/C到LUTA/O之间的时钟插入延迟，这同样也会导致比较大的斜率。
路径分割的影响
再次举例强调一下路径分割的缺点，由于路径分割会阻止时序弧的传递，所有经过这些节点的路径都会受到影响，如下图：
假设在LUTA/O和REGB/D之间设置了最大延迟“set_max_delay 6 -from [get_pins LUTA/O] -to [get_pins REGB/D]”，如上图蓝线。
由于LUTA/O是一个非法的起点，发生了路径分割，所有从LUTA/I*到LUTA/O之间的时序弧都被打断。尽管上面设置的最大延迟约束可以起作用，但是其它经过此节点的路径（REGA/C到REGC/D；REGA/C到REGB/D）由于路径分割的影响也被打断了。
路径分割与时序异常
第33篇中也简单提到过set_max_delay约束会被set_clock_groups约束替代的问题。当发生路径分割时，可能会导致感觉上时序异常的优先级发生了改变，但事实上并非如此。考虑如下两个约束：
#情景1
set_max_delay <ns> -datapath_only -from <instance> to <instance>
#情景2
set_max_delay <ns> -datapath_only -from <pin> to <pin | instance>
第一个情景中，-from和-to提供实例名称，set_max_delay约束总会被set_clock_groups -asynchronous约束替代。这是因为在给出实例的情况下，Vivado总会优先选择合法的起点。
第二个情景中，如果-from提供的管脚名称导致路径分割现象出现，此时set_max_delay约束不会被set_clock_groups -asynchronous约束替代。这是因为路径分割将该管脚名称强制作为路径起点，Vivado无需自己选择，导致set_max_delay不会被set_clock_groups覆盖。