Conflicts:
	hdl/modules/dbe_common/reset_synch/reset_synch.vhd
	hdl/top/afc_v3/vivado/dbe_bpm/dbe_bpm.xdc
	hdl/top/afc_v3/vivado/dbe_bpm_dsp_fmc130m_4ch_2_to_1_mux_ddr_2_3/pcie_core.xdc

Version v0.2

This is important as of now. Hdlmake does not
currently generate correct Vivado project files.

Because of this, we add the common hdlmake Makefile
to just call our custom-edited Vivado dbe_bpm.xpr
project.

This is our current fork. The one located at
lerwys/general-cores is my personal fork.

Now, the necessary files are located in
platform/<FPGA model>/<board model>

This is necessary as we had a hold violation on a
net. It's necessary to properly study the cause
of this violation, but this directive solves the
problem keeping the same number of resources and
implementation time

Previously, we could only transfer 8MB (typically
1000000 samples for 16-bit data or 500000 for a
32-bit data) of data at a time. This would impose
a huge limitation as we eventually want more
than that amount of continuous data.

The fix is somewhat simple. We just need to:

1) Reissue the AXIS command each time the
packet transaction reaches its maximum using
the previously calculated address

2) Generate a TLAST signal for the corresponding
PLD stream

3) Reset the TLAST counter for each new transaction

These steps ensure that no limitation will occur
due to size issues.

The maximum BTT is, in fact, 8MB and not 8GB.

This is necessary as AXI datamover indeterminate
BTT mode uses 32 bits os STS. Even though we don't
use it, VHDL requires consistency between modules
declarations.

This reduces the impact on AXI infrastructure and
stills maintains a good throughput for our cases.

This is necessary to acquire the desired alignment.
Otherwise, we can end up with the problem describe on
github issue #52.

This fixes #52 github issue.

This is related to github issue #52, in that
the fifo_fc_mux_cnt signal is different than 0, after
the transaction ends. This points to an alignment
problem in the acquisition (typically trigger acquisitions)
and subsequent transactions could be wrong (first sample
belonging to the previous transaction).

Previously we were counting up to lmt_pkt_size, but after
the FIFOs, we aggregate the data. So, we should be counting
up to lmt_pkt_size_aggd. Although the end of transaction
flags were still correctly asserted (acq_cnt module was still
receiving the correct limit lmt_pkt_size_aggd), this could led
to miscounting on subsequent acquisitions.

We were asserting the trigger aligned with the
first atom of the sample. This is wrong as the trigger
belong to the last atom of the PRE TRIGGE state.

Thus, it belongs to the last atom of the sample.

This is necessary as commit e9d94f97 introduced
a new DDR size payload (g_ddr_payload_width) generic

This was causing a bug in that, on trigger modes,
the trigger sample was detected on a unaligned number
of atoms (DDR size / channel atom size). This causes
the FIFO module (acq_fc_fifo) to finish the previous
transaction on a undefined FIFO (0, 1, 2 or 3) number.

In that case, the next transaction would wrongly assume
that new data was already present in some FIFO and read
the FIFOs prematurely, causing either a missing sample
for the DDR3 interface module or simply data belonging
to the previous acquisition.

This is useful on acquisition core
data_checker module, in which we print large
(more than 32-bit) std_logic_vector values.

If we are not using internal trigger detection,
we should not be holding the trigger to the
delayed valid sample.

Now, ddr_core and AXI interconnect modules were
added to the waveform for better understanding of
the dataflow.

We need this for our new acq_ddr3_axis_write module,
supporting trigger and multishot transactions.

Now, we use the datamover in indeterminate BTT mode,
in which we can send only one packet to transfer up
to 2^23-1 bytes. If we need to abort it earlier, we can
by asserting the TLAST signal ahead of time.

For the trigger cases, in which, we must write new data
for an indeterminate period of time (until the trigger
actually comes), we just detect the end of the 2^23-1 bytes
and start another one. When the trigger indeed happens,
we send a TLAST signal on the data stream buffer and the
current transaction is finished.

This is already being checked inside
acq_ddr3_axis_write module.

Now g_ddr_interface_type and g_max_burst_size
both are connected to the top level wb_acq_core_plain
module

Instead of producing data at 0.5 data valid
probability, use 1.0. This means that, at every clock
cycle we have new valid data.

It is more adequate to use a single
command packet for each transaction,
instead of issuing a new command packet
for each, for instance, 32 bytes.

Now, we use the lmt_valid signal to mean the start
of a new transaction. So, each new transaction the
SOF/EOF flags are cleared to the correct values.

As we have a modest throughput requirement, we
need to increase the maximum burst size.
For a convenience, we selected the maximum value,
128.

As we will use a single command packet to transfer
all of our data, we need to have a up to 2GB of
address range. With BTT equal to 16, we only had
64KB.

This is a minor issue as we didn't rely on
the reset signal to zero it.

In our real project we have a cascaded AXI interconnect. So,
we mimic this structure here.

Ths is probably related to VHDL <-> Verilog
mixed compilation.

As we changed the Thread ID width, we need to
update it here.