When a net or signal has two or more sources is referred to as a multiple driver scenario.
Why do we need to resolve multiple driver scenarios?
Having multiple drivers is incorrect design and the final value can be un-deterministic.
This is why the Synthesis tools issue errors/warnings for nets or signals with multiple drivers. In Vivado a Critical Warning is flagged in Synthesis. If this is not attended to, 'opt_design' flags an Error.
Reporting of Multiple Driver scenarios by Vivado:
Vivado identifies nets or signals with multiple drivers during the synthesis phase.
It will flag a Critical Warning (SYNTH 8-6859) for nets with multiple drivers in the design.
It also prints a table with the number of multi-driven nets in the design.
Example 1: Simple Multi-driver
Here out1 is driven in the sequential blocks B1 and B2, resulting in a multiple driver situation.
Similarly, a wire driven by either combinatorial logic or sequential logic or a combination of both results in a multiple driver scenario.
For a bus, if any bit is driven by multiple sources, it results in a multiple driver scenario.
Note: Vivado does not flag multiple drivers if exclusive bits have different sources.
Example 2: Multi-driver, 3-states and hierarchy considerations
If a net has multiple drivers that are 3-states it is not considered to be a multiple driver situation.
Generally, it is understood that at any given point in time only one source will be active.
If 3-state's are present in the submodule they will be pulled out to the top hierarchy.
Example 3: Multiple driver situations where one of the drivers is a user defined constant
In this example, one of the drivers of the net is constant.
In such cases the tool honors the constant driver and ignores the other.
The tool will issue a clear Critical Warning for the same.
Example 4: VIO/ILA mark debug and multi-driver considerations
In Vivado, if different bits of a bus are driven by different sub-modules, they are not considered to be driven by multiple sources. Because each bit has its own exclusive driver, there is no contention.
However, in this example if you apply any of the following or similar hierarchy restrictions, Vivado will sees it as a multiple driver situation
'keep_hierarchy' applied on a submodule
'don’t_touch' attribute applied on a submodule
'mark_debug' attribute applied on any port of a submodule
Any port of a submodule is connected to an ILA/VIO debug core
This happens because there is a strict guideline for the user to maintain the boundary of the submodule instantiation.
Instance U1 drives only out1, out1 is connected to GND.
Instance U2 drives only out1, out1 is connected to GND.
Because each bit of out1 has two drivers, Vivado sees this as a multiple driver situation.
Sometimes the exact names of multiple drivers are not easy to determine from the message given.
This happens when the drivers are for tool-generated nets and not user-defined nets.
You will need to check for drivers of multi-driven nets by searching for nets that have more than 1 driver.
Also it is sometimes useful to run opt_design, as if there are multiple drivers in synthesis, 'opt_design' will flag Errors. However, because the design is more optimized and all blocks (DCPs, debug modules) are now available, the multi-driver error in opt could be more precise.
Due to the limited scope of this blog, not all scenarios are covered. Some more scenarios are listed below, and if required they can be elaborated on in future.
Asymmetric 3D RAM: In TDP 3D RAM, an unsupported template could result in a multiple drivers scenario.
Interface modport: Signals defined in the interface and not defined as modports are treated as inout. This can lead to multiple driver situations.
You should now be more aware of situations where multiple drivers can occur, and of the need to modify RTL to proceed further in the flow.