[rev2.bof.gz, r2dbe_top, r2dbe_vdif_lib] Tied data valid to enable signal, DSP48E for counters in snap block improved timing

First, in addressing the 4 us.  We notice this occurs when toggling
the enable signal, and when I had originally designed the vdif
packetization system, i did not have the toggling of this line in
mind.

Firstly, when turned on data packets flow into a FIFO as 64 bit
words, every other clock.  The depth of this FIFO is 1024.  In normal
operation, this FIFO will oscillate between empty and 50 % full. When
the enable is turned off, however, data continues to flow into the fifo,
and thus a whole packet is written to the Fifo and all subsequent data
on the line is just discarded.

Thus when enable turns back on a second time, the first data to
leave is a full OLD packet of data from the start
of the second after it turned off.  Thus looking for a PPS impulse on the
data line in our pps-input experiment resulted in still seeing it in
this very first packet (however, it was from OLD data!).  While that
stale packet is taking up space in the FIFO, exactly HALF a packet of
fresh data is lost, thus every subsequent frame in this enable is delayed
from its header by exactly 4 us.  The FIFO is oscillating here between
full and 50 % full.  When enable turns off, again half a packet is
written to the fifo and subsequent data is discarded.

When enable is turned on any subsequent time after this, a full packet
of stale data (4us off) is expelled with all subsequent data 4us off.
The 4us offset will persist forever now.

To fix this, I tied the data valid signal to the enable signal, thus
no data will flow into the FIFO after enable shuts off.  This should
keep us on schedule.

Additionally, this change resulted in a design that failed timing.
The failed paths are the same 4 that give us trouble, and are located
within the 8 bit snap blocks.  I checked the box in simulink entitled
"Use DSP48Es for counters" as the instructions mentioned this would
save resources.  Compiling after this change produced this fully routed
bitcode that meets timing.

Next to try would be to go into the opb_bram pcore and uncomment a
line that will insert extra latency in the bram block to help timing efforts.