In general, FPGA clocks should not be used in combinatorial logic. Clock buses are specially routed through the FPGA and using them for non-clocking purposes can create unexpected problems in timing closure for other portions of your design.
The primary issue in your case though, is that you will almost always end up with a signal which either begins, or ends, with a fraction of a single clock pulse.
Without clocking your output, you are relying on your two signals DAC_SHIFTOUT_EN_H and SYS_CLK to be perfectly aligned, which they will likely never be - due to fanout and routing delays.
First, check to see if your FPGA has a clock buffer with an enable - a tri-state. This will be your easiest solution.
Short of that, you can create two signals and toggle them on alternate clock edges: one on the rising edge and one on the falling. Then xor the two results. Like so:
If (en = '0') then
a <= '0';
b <= '0';
if (rising_edge(clk)) then
a <= not a;
if (falling_edge(clk)) then
b <= not b;
dac_clk <= a xor b;
It is likely that your second attempt is failing, for the same reason your first attempt is. As demonstrated by your simulation, your DAC_SHIFTOUT_EN_H signal is delayed very slightly with respect to your SYS_CLK. The glitch occurs in your output with asynchronous logic (in both cases), since your output signal includes the very small portion of the SYS_CLK which is held until your DAC_SHIFTOUT_EN_H finally falls - maybe picoseconds too late.
The fact that your second simulation didn't show the same issue is probably because the layout of the new synthesis didn't cause problems for a behavioral simulation. This doesn't mean problems don't exist though.
Here I have simulated your second attempt. But I manually added a small delay in the DAC_SHIFTOUT_EN_H signal. You can see that it yields the same result as your first attempt. I made the delay large enough to be seen - making it easier to visualize.
Hope this helps.