On outputting '1' to trigger, we must
drive the FPGA iobuf to '0', as this means
output to FPGA. The same for outputting '0'
to trigger.

Note that we use the direction pin as data
so as to implement a wired-OR logic.

This is important as some acquisition modes
(e.g., triggered) may leave dirty buffers
along the way. So, we flush all of this
on each new acquisition.

This reverts commit 7789ba36.

This avoids having old parameters set
by a previous acquisition.

Instead of comparing to the byte sized pre/full
packet we should be comparing transmitted words.

This is safer as we could have some "old"
data fro a previous acquisition in the
AXI datamover or AXI interconnect buffers.
This would concatenate with the new data.

The received init/end DDR address are already
in bytes. So, we don't want to shift it again.

Previously we were relying on the calculated
full BTT value to be always '1' at the LSBs,
but there are cases in which this is not true:
1<0000000>. This would be cropped to 0, but
instead we would want the clip to the maximum BTT
value.

On long running acquisitions, BTT was not
reseting to the maximum permitted to the
memory region, so only the first pass would
succeed.

Previously, we were always setting the BTT as
2^22. If we needed to finish early, we just ended
the transaction with TLAST.

This posed a problem for long-running acquisition
(triggered), in that the AXI datamover would
continue to write even after the memory region,
because the BTT was set to 2^22.

Now, we always set it to the maximum of the memory
region.

Previously we were comparing the end address
with '=', but in most cases the ddr end address
is not multiple of the internal address. So, the
comparison would never trigger and never wrapping
the counter to the initial address, but to 0.

This caused long running acquisitions (e.g., external
trigger) to overwrite results of other channels.

Previously, on wrapping the AXI transaction
counter we would possibly reissue the transaction
2 times in row, the first one at the end of the
current transaction and the second one at the
beginning of the next one.

The module gc_ext_sync_pulse requires the generic
g_min_pulse_width to be at least the number of "ns"
of one input clock cycle. Otherwise, it may not
function properly, loosing input signals.

Previously we had an extra path to decode the
current state and output the FSM outputs.

This incurred longer long timing paths.
Now, we output the FSM outputs before
changing the state. This , in effect,
exhibits the same behaviour for other
modules, but improves timing closure.

In order to use the wired-OR logic of the
MLVDS standard, we need to output data only
when sending data.

If we are in output state we drive the data
pin to HI and use the direction pin as data,
so we can release the bus when not sending.

If we are in input state, we just use the data/
direction pins as usual.

This is safe to use with AFCv3 boards
and delivers fast boot times.

This file should be generated by hdlmake
tool every synthesis and not hardcoded as
it was before.

Now, all bitstreams are generated with:

 - SPI buswidth of 4
 - SPI fall edge = true
 - 3 MHZ SPI flash configuration
 - 32-bit support as we use 256Mb SPI flash

IOBUF primitives always have the "input"
signal available for further use. This means
that even when transmitting signals (buffer
is output) the input signal will have a copy
of the transmitted pulse.

This is principle is not a problem, but we
were using this signal to count received events,
so we changed this to use this signal only if
the buffer direction is set to input.

This is important as if the FMC1 does not
supply any clock we won't be able to send/
recv trigger events.

Also, it doesn't really matter to have
triggers with a local clk_sys clock,
as the triggers are treated as asynchronous
signal anyway.

The acquisition properties were inverted.

When using FMC250 @~250MHz, with 4 samples, 32-bits,
we don't have enough bandwidth to acquire all of this.

Instead, we just acquire exactly the amount
of bits this ADC provides and treat how to
split the data array in software.

This fixes #33 github issue.

This code was received by CAEN ELS under, relicensed
under MIT license.

AFCv3 doesn't work well with faster rates, like
50MHz. So, 12MHz should be OK.

dsp-cores added another generate statement, which chahge the
hierarchy of position_calc component. So, we change it here.