Inconsistent LabVIEW FPGA compilation errors

[Intaris]

I am receiving a weird error when compiling. What is weird about it is that 2 of 3 parallel cloud compiled create this error, the third compiles no problem.

ERROR: [DRC AVAL-245] Independent_clock_check: The RAMB36E2 cell MacallanWindow/theCLIPs/Lane_3_Protocol_FIFO_CLIP4/protocol_interpreter_bram_inst0/protocol_interpreter_bram_inst/hss1_ser_ctrl_inst/blk_mem_64_in_4_out_inst/U0/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[0].ram.r/prim_noinit.ram/DEVICE_8SERIES.NO_BMM_INFO.SDP.WIDE_PRIM36_NO_ECC.ram has CLOCK_DOMAINS=INDEPENDENT. However the two clock pins, CLKARDCLK and CLKBWRCLK, are driven by the same driver. The expected property value for CLOCK_DOMAINS for this clocking connectivity is COMMON. Improperly setting this attribute can impact simulation, optimization, and timing for the RAM resulting in incorrect simulation behavior, potential loss of performance, and increase in power.

It seems there is a BRAM in the design which is expecting dual-clock interface, but only 2 of 3 compilations raise these errors....

Any ideas why some compilations raise this error and others don't?

[Terry_ALE]

Which hardware is this for?

Confirming that you do not get an error when you compile a shipping example for this hardware.

[Intaris]

Compiling a shipping example won't include the code throwing errors....

I can compile THIS code without errors, it's just that SOMETIMES it throws an error due to a configuration that's set statically. I could set the compiler to ignore these warnings, to downgrade them to warnings, but I'm just wondering what is going on with Vivado to sometimes flag this as an error and sometimes it accepts it just fine....

[Terry_ALE]

It is not ideal but if you get say 1 out of 5 compiles passing then you could use the passing compile's bitfile.  That is, some designs are borderline where they do not always pass.  VST2 FPGA is like that.

[Intaris]

Quite familiar with that problem, but the issue is just that it's not a TIMING issue that's causing the error, that I'm used to dealing with. It's complaining about the static definition of the BRAM. That is the same for each compilation and yet some work and some don't. This (to my knowledge) isn't something that should be subject to variability. Either the BRAM is configured incorrectly or it's not. Why should the relative warning vs Error state change from compilation to compilation.

Maybe it's a known Vivado thing....

It is.... https://support.xilinx.com/s/question/0D52E00006hpQIFSA2/drc-aval245-independentclockcheck-the-ramb3...

[Terry_ALE]

Understood.  I'd send this to NI support.