多重驅動定義：

具有兩個或更多個源的網絡或信號被稱為多重驅動場景。

為何需要解決多重驅動場景？

多重驅動的存在屬于設計錯誤，最終值可能難以確定。

因此綜合工具會針對具有多重驅動的網絡或信號發(fā)出錯誤或警告。在 Vivado 綜合工具中將標記“嚴重警告 (Critical Warning)”。如果不加以解決，那么“opt_design”會標記“錯誤 (Error)”。

Vivado 報告多重驅動場景的方式如下：

Vivado 會在綜合階段識別具有多重驅動的網絡或信號。

它會針對設計中具有多重驅動的網絡標記 Critical Warning (SYNTH 8-6859)。

它還會打印一個表，其中包含設計中多重驅動網絡的數量。

例如：

示例 1：多重驅動樣本

此處 out1 是在順序塊 B1 和 B2 中驅動的，這就導致出現了多重驅動狀況。

同樣，由組合邏輯和/或順序邏輯驅動的連線也會導致出現多重驅動場景。

對于總線，由多個源驅動的任意比特都會導致出現多重驅動場景。

注：對于具有不同源的專用比特，Vivado 不會標記多重驅動。

示例 2：多重驅動、三態(tài)和層級注意事項

具有三態(tài)多重驅動的網絡不被視作為多重驅動狀況。

通常，任意給定時間點只能有單一源處于活動狀態(tài)。

子模塊中存在的三態(tài)驅動將被提取出來并劃歸最高層級。

示例 3：其中一個驅動屬于用戶定義的常量的多重驅動場景

在此示例中，其中一個網絡驅動為常量。

在此類情況下，該工具會遵循常量驅動運行而忽略另一個驅動。

該工具仍然會發(fā)出清晰的 Critical Warning。

示例 4：VIO/ILA 標記調試和多重驅動注意事項

在 Vivado 中，如果不同的總線比特由不同子模塊驅動，則不會將其視為由多個源驅動。由于每個比特都有自己的專用驅動，因此不存在爭用。

但在此示例中，如果應用以下任一層級限制或類似限制，Vivado 就會將其視作為多重驅動狀況。

在子模塊上應用“keep_hierarchy”

在子模塊上應用“don’t_touch”屬性

在子模塊的任意端口上應用“mark_debug”屬性

將子模塊的任意端口連接到 ILA/VIO 調試核

發(fā)生此狀況的原因是用戶未嚴格遵循相關準則來保持子模塊例化的邊界。

實例 U1 僅驅動 out1[0]，out1[1] 連接到 GND。

實例 U2 僅驅動 out1[1]，out1[0] 連接到 GND。

由于 out1 的每個比特都具有兩個驅動，因此 Vivado 將此視作為多重驅動狀況。

調試方法：

有時根據生成的消息難以確定多重驅動的準確名稱。

當驅動適用于工具生成的網絡而不是用戶定義的網絡時，就會發(fā)生此類狀況。

您需要通過搜索具有多個驅動的網絡來查找多重驅動網絡的驅動。

您可以使用以下 Tcl 命令：

get_nets -hierarchical -top_net_of_hierarchical_group -filter { DRIVER_COUNT > 1 }

并且有時最好運行 opt_design，因為只要綜合中存在多重驅動，“opt_design”就會發(fā)出 Errors 標記。但由于設計經過進一步優(yōu)化，并且當前所有塊（DCP、調試模塊）都可用，因此 opt 中的多重驅動錯誤可能更精確。

受篇幅所限，本文并未涵蓋所有場景。以下列出部分其他場景，將來可根據需要進一步詳細講解。

非對稱 3D RAM：在 TDP 3D RAM 中，不受支持的模板可能導致出現多重驅動場景。

接口 modport：接口中已定義信號但未將其定義為 modport，此類信號將被作為 inout 來處理。這可能會導致出現多重驅動場景。

總結：

至此，相信您應該已經了解了可能發(fā)生多重驅動的各種場景，并且已清楚認識到需要修改 RTL 才能繼續(xù)運行流程。