cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Participant
Participant
15,471 Views
Registered: ‎05-15-2013

Vivado Synthesis does not cope with multi-driven signals

Jump to solution

Hi *,

 

I've run across a (in my eyes unacceptable)  VHDL synthesis issue:

 

When a std_ulogic signal is driven in a concurrent assignment AND from another module, Vivado does not seem to care. There is no error or even warning message, the entire flow completes from start to finish without any problems.There is no message in the logs pointing to this potential problem.

 

In my opinion, driving a std_ulogic signal from two places *MUST* result in an error message during elaboration, synthesis should stop immediately at that point. If it doesn't, there must at least be a (critical) warning message somewhere in the logs.

 

Vivado even performs a "multi_driven_nets"-check during synthesis, but it claims everything is OK:

 

Report Check Netlist: 
+------+------------------+-------+---------+-------+------------------+
|      |Item              |Errors |Warnings |Status |Description       |
+------+------------------+-------+---------+-------+------------------+
|1     |multi_driven_nets |      0|        0|Passed |Multi driven nets |
+------+------------------+-------+---------+-------+------------------+

 

With the same code, Modelsim throws an error message during compilation, as it should. Why doesn't Vivado?

 

I've attached a simple test case inlcuding a Modelsim simulation script to reproduce the issue.

 

Am I missing something or is this behaviour simply wrong?

 

Regards,

Sean

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Xilinx Employee
Xilinx Employee
20,371 Views
Registered: ‎02-14-2014

Hello Sean,

 

Thanks for your patience and highlighting this issue. To address this issue in future Vivado release, I have filed a change request. For your reference, CR number is 820888. As this is the recent CR, I cannot tell the exact Vivado version in which it will be fixed.  

Regards,
Ashish
----------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------------

View solution in original post

0 Kudos
17 Replies
Highlighted
Xilinx Employee
Xilinx Employee
15,460 Views
Registered: ‎02-16-2014

Hi,

 

In the test case you have attached, I suspect as the output is being driven by constant in submodule tool is not considering the XOR assignment.

 

When I made the output port in submodule not constant (connected to some input port), there has been critical warnings issued during synthesis indicating the multi driven nets.Capture.PNG

Vivado will not flag this as an error by default, it will report it as a critical warning.

 

Customer can change this severity to error using the following command.

set_msg_config -id "Synth 8-3352" -new_severity "ERROR"

0 Kudos
Highlighted
Participant
Participant
15,440 Views
Registered: ‎05-15-2013

Hi Manusha,

 

thanks for the quick response.

 

Unfortunately, that is not really helpful. I claim that according to the VHDL Language Reference Manual, Vivado's behaviour is wrong. Driving a std_ulogic signal from two different places MUST result in an error message, that's what the language mandates. std_ulogic is an unresolved type, so the behaviour for a multi-driven net is undefined. Vivado can't simply decide to do whatever it likes.

 

It should not matter if one of the signal sources drives a constant or not. How should I as a user know what the tool decides; which assignment "wins"?

It's actually even worse that Vivado behaves differently if one of the sources drives a constant value; why should that make a difference? There's two assignments, who decides which one "wins"? That's why simulation tools throw an error and make you fix your code.

 

In my case, I cannot change the severity, since I do not even receive a warning, let alone a critical warning! So this issue is totally lost; I end up with a bitfile with undefined behaviour that simply does not work.

 

I further claim that multi-driven signals should by default always be ERRORs, not critical warnings. Usually, what happens is that in the very end, the DRC before bitgen then reports this as an ERROR; but a lof of time is wasted for a completely useless map, place and route run that is destined to fail at the end. This should be caught early during VHDL compilation and it should cause everything to stop. But I'd be happy if I even got a critical warning so I could further investigate. In my case I get nothing, no info, no warning, no critical warning, and that's definitely not OK.

 

Regards,

Sean

Highlighted
Observer
Observer
15,421 Views
Registered: ‎09-19-2012

Hi,

I'm supporting Sean's claim. Please give an error whenever there are multiple drivers to an unresolved net. In fact, for resolved signals, Vivado Synthesis should actually resolve multiple drivers to a signal according to its resolution function. I don't think this is even done by the tool?

 

For unresolved signals, per the LRM, it is illegal to drive them from multiple sources. Hence, Vivado Synthesis should issue an error when this happens.

 

Illegal code should never be synthesised to any netlist. Even this isn't enough. Optimising illegal code is worse, so please issue an error AND don't generate any netlist for multiple drivers to an unresolved net.

 

May I also suggest to Xilinx that you implement the other VHDL unresolved types, such as unresolved_unsigned, for example.

 

Best regards, Daniel

0 Kudos
Highlighted
Moderator
Moderator
15,380 Views
Registered: ‎01-16-2013

Hello @daniel.kho ,

 

Thanks for your suggestion. 

Do you have any specific test case which can help us to understand the problem with Vivado?

If there is really any issue with tool messaging it will help to improve tool messaging.

 

Looking forward for your test case with detail explanation.

 

Thanks,

Yash

0 Kudos
Highlighted
Participant
Participant
15,369 Views
Registered: ‎05-15-2013
Hi yash,

I attached a test case when I started the topic... Included is a Modelsim simulation script showing how this should be handled correctly (Vivado should react just like Modelsim does!).

The problem is not so much Vivado's message reporting, as its in my opinion faulty VHDL implementation when it comes to multiple drivers on unresolved signals. The VHDL standard is clear on what must happen: an error must be issued, compilation must stop, very plain and simple.

But not only is this condition (multiple drivers on an unresolved signal) in some cases not detected at all (see my test case) and is not reported in any way; but when it actually IS detected (see your colleague's test case), it is reported as a critical warning, not an error; this means that the flow simply continues, a user might never notice a potential problem.

As Daniel correctly stated, this is unacceptable, since in the end the user potentially receives a bitfile with undefined and almost certainly undesired behaviour, wasting a lot of time on useless P&R runs and debugging.

This is primarily a VHDL language issue, Vivado's implementation is faulty (whereas XST handles this correctly, IIRC!) and needs to be fixed.

Regards,
Sean
0 Kudos
Highlighted
Moderator
Moderator
15,361 Views
Registered: ‎01-16-2013

Hello,

 

Thanks for you clarification.

I will try your test case and i will update accordingly.

 

Thanks,

Yash

0 Kudos
Highlighted
Historian
Historian
15,345 Views
Registered: ‎02-25-2008

I'll just throw in with Daniel and Sean. They are correct.

 

The standard type std_ulogic is unresolved. In VHDL, if two signals of an unresolved type try to drive the same net, an error results. This is by design in the language. 

 

The standard type std_logic adds a resolution function to the type definition, which allows for the possibility of two signals driving the same net. The resolution function's job is to determine the final strength of the driven signal. This is how the language models tristate and wire-OR and wire-AND connections.

 

If the synthesis tool allows for two (or more) signals of an unresolved type to be connected together, then the tool is BROKEN. This is a serious bug in Vivado.

----------------------------Yes, I do this for a living.
0 Kudos
Highlighted
Participant
Participant
15,213 Views
Registered: ‎05-15-2013

Hi yash,

 

any news on this? As bassman59 stated, this really is a serious bug that should be addressed.

It's not a nice-to-have feature, but a rather fundamental VHDL issue...

 

Regards,

Sean

0 Kudos
Highlighted
Moderator
Moderator
15,206 Views
Registered: ‎01-16-2013
Sorry for the delay...
I will update ASAP.

Thanks,
Yash
0 Kudos
Highlighted
Explorer
Explorer
12,692 Views
Registered: ‎08-14-2007

I also have to agree with Daniel, Sean and bassman.  As bassman said:

 

If the synthesis tool allows for two (or more) signals of an unresolved type to be connected together, then the tool is BROKEN. This is a serious bug in Vivado.

Martin Thompson
martin.j.thompson@trw.com
http://www.conekt.co.uk/capabilities/electronic-hardware
Highlighted
Participant
Participant
12,672 Views
Registered: ‎05-15-2013

Hi *,

 

I've now had time to try it with different tools:

 

- XST throws an error in the HDL elaboration phase right after parsing

- The OEM Synplify included in Lattice Diamond also quits before this even goes to mapping

- Mentor Precision Synthesis also complains and does not finish

- Modelsim stops right at compile time

- Active HDL does as well

- ISIM integrated in Vivado does not even compile the code: "ERROR: [XSIM 43-3249] File E:/xilinx_testcase/top.vhd, line 18. Unresolved signal "internal_sig" is multiply driven." (You could argue about the grammar, but it handles this correctly.)

 

... just to give you an idea how other tools handle this.

 

Regards,

Sean

Highlighted
Moderator
Moderator
12,638 Views
Registered: ‎01-16-2013
Hello,

I agree with you on each and every point.
We have traced down the issue but some internal procedure is going on before filling CR.
Once its done I will update.

Thanks,
Yash
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
20,372 Views
Registered: ‎02-14-2014

Hello Sean,

 

Thanks for your patience and highlighting this issue. To address this issue in future Vivado release, I have filed a change request. For your reference, CR number is 820888. As this is the recent CR, I cannot tell the exact Vivado version in which it will be fixed.  

Regards,
Ashish
----------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------------

View solution in original post

0 Kudos
Highlighted
Participant
Participant
12,599 Views
Registered: ‎05-15-2013
Hi Ashish,

thanks for letting us know. I'll keep looking for that CD number in future relase notes. :)

Regards,
Sean
0 Kudos
Highlighted
Visitor
Visitor
12,455 Views
Registered: ‎12-12-2008

 

bassman59 wrote:

The standard type std_logic adds a resolution function to the type definition, which allows for the possibility of two signals driving the same net. The resolution function's job is to determine the final strength of the driven signal. This is how the language models tristate and wire-OR and wire-AND connections.

 

It is true that std_logic is a resolved signal but if Xilinx has not find a way to make a 9-state signal internally inside the FPGA this should also result in an error as it did in the old XST synthesis tool.

0 Kudos
Highlighted
Adventurer
Adventurer
5,427 Views
Registered: ‎07-09-2014

Hi,

 

I come across this bug in Vivado 2014.2

 

I was updating a custom AXI IP peripheral and forget to comment out constant signal assignments of unused bits of AXI registers. Then I tried to assign those bits from a submodule. I synthesized and no warning, error. I just forget to look to the end of the file where I assigned constant zero values to the registers and it tooks me same hours to find out I actually multi-sourcing a signal and there is no error, even warning.

 

Is this issue fixed in new versions of vivado?

 

Thanks,

 

bbinb

0 Kudos
Highlighted
Visitor
Visitor
4,797 Views
Registered: ‎10-10-2013

Hi,

 

    Would it be possible to add support for resolution functions?  In other synthesis tools it is possible to at least make the tool understand you want a WIRED-OR or WIRED-AND resolution of multi-driven nets, the tool then inserts OR or AND gates into the netlist to merge the multidriven net.  For instance I can use this for a system bus data return:

 

    -- MBIST control interface signals
    type t_mbist_ulogic_vector is array (natural range <>) of std_ulogic;
    function mbist_vector_resolved (s : t_mbist_ulogic_vector) return std_ulogic;

    -- Required for Cadence, NB: WIRED_AND also available
    attribute RESOLUTION : string;
    attribute RESOLUTION of mbist_vector_resolved : function is "WIRED_OR";

    subtype t_mbist_std_logic is mbist_vector_resolved std_ulogic;
    type t_mbist_logic_vector is array (natural range <>) of t_mbist_std_logic;

 

In this case a large number of drivers on signals of type "t_mbist_logic_vector" used for the return data bus are resolved using OR gates.

 

Cheers,

    Mark

0 Kudos