You'll have to supply a pulse to CONVST_A, CONVST_B, CONVST_C and CONVST_D for all three ADCs to start their conversions. Use an external clock (XCLK) to synchronize the conversions. Check the BUSY/INT output for end-of-conversion:
When bit C27 = 1 (BUSY/INT in CONFIG), this pin is an interrupt output. This pin transitions high after a conversion
has been completed and remains high until the next read access. This mode can only be used if all eight channels
are sampled simultaneously (all CONVST_x tied together). The polarity of the BUSY/INT output can be changed
using bit C26 (BUSY L/H) in the Configuration Register. (page 16)
You then can read the data of the different ADCs into several registers. At that moment timing is no longer relevant to the synchronicity of the conversion.
One case, that probably doesn't apply, is if you're using a standard older than VHDL-2002. Before than, buffer could not connect directly to out. So in a hierarchical design, the signal path would need to be declared as a buffer on all levels. Also, when adhering to these older standards, some tools have problems synthesizing buffers correctly. They may or may not warn you about this.
These should no longer be an issue if you're using a newer standard. From the VHDL-2002 Standard:
a) For a formal port of mode in, the associated actual must be a
port of mode in, inout, or buffer.
b) For a formal port of mode out, the associated actual must be a
port of mode out, inout, or buffer.
c) For a formal port of mode inout, the associated actual must be
a port of mode inout, or buffer.
d) For a formal port of mode buffer, the associated actual must be
a port of mode out, inout, or buffer.
e) For a formal port of mode linkage, the associated actual may be
a port of any mode.
I also often see advice stating that a buffer should never be tri-stated. If you need the ability to tri-state a bus, then you would need to use out. I could find no direct reference to how buffers handled tri-stating in the standard. But it is probably good advice to follow. Again, your tools may or may not complain if you attempt to synthesis a tri-stated buffer.
Best Answer
Adding to @Anonymous's answer, there are designs you can build which can damage the fabric of an FPGA.
For starters if you build a very large design consisting of huge quantities of registers (e.g. 70% of the FPGA) all clocked at nearing the FPGAs maximum frequency, it is possible to heat the silicon considerably. Without sufficient cooling this can cause physical damage. We lost a $13k FPGA because it overheated due to the dev-kit having a terrible cooling system.
Another simpler case can be combinational loops. For example if you instantiate three not gates chained together in a ring, and disable or ignore the synthesizers warnings about such a structure, you can form something which is very bad for an FPGA. In this example you'd make a multi-GHz oscillator which could produce a lot of heat in a very small area, probably damaging the ALM and surrounding logic.