UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Adventurer
Adventurer
7,211 Views
Registered: ‎02-06-2012

Vivado 2014.2 synthesis buggy

Hello,

 

I have a problem with synthesizing my project, and I'm pretty sure this is a bug Vivado.

First of all: it's a project that was working just fine! And yet when I woke up yesterday Vivado decided that it won't synthesize it properly no matter what!

 

I have now two kind of problems:

1. Multiple drivers bug.

In one of the modules I get critical warnings like this:

[Synth 8-3352] multi-driven net ctrl_reg[30] with 1st driver pin 'ipb_sl0/ctrl_reg_reg[30]/Q' ["/home/adrian/vhdl/k7/mtf7_control/mtf7_control.srcs/sources_1/imports/rtl/ipbus_ctrlreg.vhd":64]
[Synth 8-3352] multi-driven net ctrl_reg[30] with 2nd driver pin 'ipb_sl0/ctrl_reg_reg[30]__0/Q' ["/home/adrian/vhdl/k7/mtf7_control/mtf7_control.srcs/sources_1/imports/rtl/ipbus_ctrlreg.vhd":43]

And quick look at the code:

ipb_read: process(clk)
begin
    if rising_edge(clk) then
        case ipbus_in.ipb_addr is
        when x"00000000" =>
            ipbus_out.ipb_rdata <= C_ID_REG;
        when x"00000001" =>
            ipbus_out.ipb_rdata <= ctrl_reg; --LINE 43
            if ipbus_in.ipb_strobe='1' and ipbus_in.ipb_write='1' then
                ctrl_reg <= ipbus_in.ipb_wdata;
            end if;
        when x"00000002" =>
            ipbus_out.ipb_rdata <= c2c_status;
        when others =>
            ipbus_out.ipb_rdata <= (others => '0');
        end case;
        
        ack <= ipbus_in.ipb_strobe and not ack;

    end if;
end process;

ipb_write: process(clk)
begin
    if rising_edge(clk) then
        if ipbus_in.ipb_strobe='1' and ipbus_in.ipb_write='1' then
            case ipbus_in.ipb_addr is
            when x"00000001" =>
                ctrl_reg <= ipbus_in.ipb_wdata; --LINE 64
            when x"00000002" =>
                c2c_timeout <= ipbus_in.ipb_wdata(1);
            when others =>
                null;
            end case;
        end if;
        
        --latch C2C timeout
        if c2c_stat.timeout = '1' then
            c2c_timeout <= '1';
        end if;
    end if;
end process;

 

This code worked just fine and compiled without problem just a few days ago. It also compiles fine with ISE.

 

2. Module inputs mistakenly treated as floating and connected to GND.

In another modules I have situation where Vivado mistakenly treats some ports of instantiated components as floating, and then connects them to GND. Even ports with hardcoded '1' ! This code is in VHDL, so it isn't just some stupid Verilog typo.

 

I've tested it on both Linux and Windows machines - no difference.

I've also tried synthesis options "-flatten_hierarchy none, -no_lc, -keep_equivalent_registers". Also no difference at all.

And to reiterate: this is a project that was working fine just two days ago.

 

I'm willing to share my code with Xilinx employee for debugging.

 

Cheers!

 

0 Kudos
4 Replies
Explorer
Explorer
7,198 Views
Registered: ‎09-07-2011

Re: Vivado 2014.2 synthesis buggy

Vivado might be right  -  check out line 45. 

 

 

Historian
Historian
7,187 Views
Registered: ‎01-23-2009

Re: Vivado 2014.2 synthesis buggy

I am not sure why you think this isn't an error - you clearly have the same signal "ctl_reg" assigned in both processes. Yes, the line number appears to be off by 2 in the error message, but your "read" process is clearly also doing a write

 

(in ipb_read - lines 44, 45, and 46)

 

if ipbus_in.ipb_strobe='1' and ipbus_in.ipb_write='1' then
                ctrl_reg <= ipbus_in.ipb_wdata;
end if;

 

Avrum

Historian
Historian
7,183 Views
Registered: ‎01-23-2009

Re: Vivado 2014.2 synthesis buggy

As for the 2nd - are you sure this is a bug?

 

When an instance pin is tied to a constant, the tools will propagate the constant into the instance and reduce the logic accordingly. Therefore, the port of the module is no longer necessary, and will be ignored inside the instance. However, the port has to remain (since hierarchy is preserved), so outside the module it needs to be tied to something - VCC or GND are fine.

 

I am sure if you do a post-synthesis simulation, you will find that the functionality is correct, and so this isn't a problem.

 

Avrum

Adventurer
Adventurer
7,180 Views
Registered: ‎02-06-2012

Re: Vivado 2014.2 synthesis buggy

Aaaahh, yes! Thank you guys! Both of you are right, and I was blind not to see this obvious error.

Thank you very much for spotting this.

 

But my second problem still persists - I see a strange synthesis results which completely don't match the VHDL.

Below is a fragment of module in question:

mac_addr <= x"D4DEB96291A0";
ip_addr <= x"C0A801DD"; --192.168.1.221

eth_device_i: eth_device port map (
   gtrefclk => gtrefclk,
   txp => txp,
   txn => txn,
   rxp => rxp,
   rxn => rxn,
   txoutclk => txoutclk,
   resetdone => resetdone,
   mmcm_locked => mmcm_locked,
   userclk => userclk,
   userclk2 => userclk2,
   independent_clock => independent_clock,
   rx_axi_clk => mac_clk,
   rx_reset_out => rx_reset_out,
   rx_axis_mac_tvalid => rx_axis_mac_tvalid,
   rx_axis_mac_tlast => rx_axis_mac_tlast,
   rx_axis_mac_tuser => rx_axis_mac_terror, --Yep, tuser is actually terror
   rx_axis_mac_tdata => rx_axis_mac_tdata,
   tx_axi_clk => mac_clk,
   tx_reset_out => tx_reset_out,
   tx_axis_mac_tready => tx_axis_mac_tready,
   tx_axis_mac_tvalid => tx_axis_mac_tvalid,
   tx_axis_mac_tlast => tx_axis_mac_tlast,
   tx_axis_mac_tdata => tx_axis_mac_tdata,
   tx_axis_mac_tuser(0) => tx_axis_mac_tuser,
   pause_req => pause_req,
   pause_val => pause_val,
   speed_is_100 => speed_is_100,
   speed_is_10_100 => speed_is_10_100,
   tx_ifg_delay => tx_ifg_delay,
   rx_statistics_vector => rx_statistics_vector,
   tx_statistics_vector => tx_statistics_vector,
   rx_statistics_valid => rx_statistics_valid,
   tx_statistics_valid => tx_statistics_valid,
   mac_addr => mac_addr,
   status_vector => status_vector_int,
   reset => mmcm_reset,
   signal_detect => '1'
);

(...)

process(userclk2)
begin
    if rising_edge(userclk2) then
        link_up <= status_vector_int(0);
    end if;
end process;

 

And here's a fragment of generated schematic:

vivado_mtf7_control.jpeg

 

As you can see, some of the ports are assigned '0' even if they are explicitly connected to something else. For example please look at ports signal_detect, mac_addr, or link_up_reg and it's description in VHDL.

'reset' signal is also connected to the MMCM and I can see in schematic that it's connected correctly, so why the very same signal is replaced with constant '0' in eth_device?

0 Kudos