Here's some Xilinx forum post claiming it's harmless. I think we should just add the SIM_DEVICE parameter. I have no special insight on why this is an appropriate solution but it seems unlikely to break anything.

SIM_DEVICE enables the correct sim model for the target device as there have been slight behaviour changes, it doesn't actually change anything in synthesis but creates a warning due to being a possible sim/synth mismatch.

My ancient Vivado version doesn't have the warning, can you check that #444 fixes this for you?

it does not; I used this guide https://nmigen.info/nmigen/latest/install.html#editable-development-snapshot to setup a newer version of nmigen, still nothing. furthermore , I discovered that this is not the only primitive it got wrong: here are a few more primitives it got wrong:

WARNING: [Netlist 29-345] The value of SIM_DEVICE on instance 'cd_sync/U$$1' of type 'BUFGCTRL' is 'ULTRASCALE'; it is being changed to match the current FPGA architecture, '7SERIES'. For functional simulation to match hardware behavior, the value of SIM_DEVICE should be changed in the source netlist. 
WARNING: [Netlist 29-345] The value of SIM_DEVICE on instance 'cd_sync/U$$1' of type 'BUFGCE' is 'ULTRASCALE'; it is being changed to match the current FPGA architecture, '7SERIES'. For functional simulation to match hardware behavior, the value of SIM_DEVICE should be changed in the source netlist. 
WARNING: [Netlist 29-345] The value of SIM_DEVICE on instance 'cd_sync/U$$1' of type 'BUFGCTRL' is 'ULTRASCALE'; it is being changed to match the current FPGA architecture, '7SERIES'. For functional simulation to match hardware behavior, the value of SIM_DEVICE should be changed in the source netlist. 

#444 not working kinda seems like a vivado bug, looking at the log, it correctly reads in the SIM_DEVICE attribute of the BUFGCE as 7SERIES:

INFO: [Synth 8-6157] synthesizing module 'BUFGCE' [/data/opt/Xilinx/Vivado/2019.2/scripts/rt/data/unisim_comp.v:1085]
        Parameter CE_TYPE bound to: SYNC - type: string
        Parameter IS_CE_INVERTED bound to: 1'b0
        Parameter IS_I_INVERTED bound to: 1'b0
        Parameter SIM_DEVICE bound to: 7SERIES - type: string
        Parameter STARTUP_SYNC bound to: FALSE - type: string

but then transforms the BUFGCE into a BUFGCTRL during which the attribute seems to get lost:

WARNING: [Netlist 29-345] The value of SIM_DEVICE on instance 'cd_sync/U$$1' of type 'BUFGCTRL' is 'ULTRASCALE'; it is being changed to match the current FPGA architecture, '7SERIES'. For functional simulation to match hardware behavior, the value of SIM_DEVICE should be changed in the source netlist.
[...]
INFO: [Project 1-111] Unisim Transformation Summary:
  A total of 1 instances were transformed.
  BUFGCE => BUFGCTRL: 1 instance

Full build directory: build.zip

This is for the following design:

from arty_z7 import ArtyZ720Platform

from nmigen import *
from nmigen.back.rtlil import convert

class Blinky(Elaboratable):
    def __init__(self):
        self.led = Signal(reset=0)

    def elaborate(self, platform):
        m = Module()

        counter = Signal(range(int(platform.default_clk_frequency+1)))

        m.d.sync += counter.eq(
            Mux(counter==int(platform.default_clk_frequency),
                0, counter+1))

        m.d.sync += self.led.eq(self.led ^ (counter==0))
        # if counter is zero, flip the led

        return m


class top_level(Elaboratable):
    def elaborate(self, platform):
        m=Module()
        m.submodules.blink = Blinky()

        led = platform.request("led", 2)
        m.d.comb += led.eq(m.submodules.blink.led)
        return m

ArtyZ720Platform().build(top_level(), do_program=True)

This is using vivado 2019.2, so it could have been fixed in the newest version of vivado (2020.1).

@rroohhh Thanks for investigation. I think I'm going to merge the PR, since it seems to be a clear improvement, even if it doesn't fully fix the problem at the moment.

(Reopening as upstream bug.)

One way to avoid this would be using BUFGCTRL directly instead of BUFGCE. Going after UG472 BUFGCE is implemented in terms of BUFGCTRL anyways:

Unlike BUFG, BUFGCE is a clock buffer with one clock input, one clock output and a clock
enable line. This primitive is based on BUFGCTRL with some pins connected to logic High
or Low.

Ah, I'm fine with that solution too.

@rroohhh Something like this? #460

@DaKnig Could you check if this fixes the issue with your Vivado version?

Technically switching to BUFGCTRL is only needed for 7series (as SIM_DEVICE defaults to ultrascale (atleast currently)).
Furthermore on ultrascale BUFGCE and BUFGCTRL are actually two different primitives. The equivalent to BUFGCE on 7series seems to be BUFGCE_1 which is implemented in terms of BUFGCTRL on ultrascale. Now which one to prefer I don't know.

Also this is missing setting SIM_DEVICE = "7SERIES" again, so it doesn't remove the warning.

Sorry if what I wrote was misleading, I wanted to say if you use BUFGCTRL and set SIM_DEVICE="7SERIES it actually works, as then vivado doesn't perform the transformation of BUFGCE to BUFGCTRL which seems to internally loose the SIM_DEVICE attribute.

@rroohhh Does this work? #490

It works for me for 7series on vivado 2019.2. (Can't test ultrascale as I don't have the ultrascale device support installed)

Just to mention, I'm hitting this as a bug when using Vivado 2018.2 (which is the version recommended to use for fuzzing 7 series).

Output from Vivado is:

ERROR: [Synth 8-3438] module 'BUFGCTRL' declared at '.../Vivado/2018.2/scripts/rt/data/unisim_comp.v:663' does not have any parameter 'SIM_DEVICE' used as named parameter override [.../build/top.v:90939]

The relevant section of top.v is:

  BUFGCTRL #(
    .SIM_DEVICE("7SERIES")
  ) \U$$1  (
    .CE0(ready),
    .CE1(1'h0),
    .I0(clk12_0__i),
    .I1(1'h1),
    .IGNORE0(1'h0),
    .IGNORE1(1'h1),
    .O(clk),
    .S0(1'h1),
    .S1(1'h0)
  );

I can work around this by removing the line with .SIM_DEVICE("7SERIES") manually and restarting the build.

I don't think you're hitting this bug because Xilinx support has been completely rewritten in the meantime. Provided this happens on the main branch, could you open a new issue please?

Will do!