With this, we can select which data source to acquire.

This is a initial implementation of the
Post-Mortem functionality.

For now, this module does exactly
the same as ACQ, but this could change
in the future.

Either way, it's good to differentiate
between them, as the software part will
build upon them differently.

the generic g_acq_num_cores were not being passed
to the inner modules, causing it to use only the
default value.

This will force the synthesis tool to use
distributed RAM style, which will possibly
improve timing for this small FIFO.

In this way, we can use sparse structures
(instead of FIFO/RAM primitives) to help
synthesis/implementation tools achieve better
timing.

This mainly works as the FIFO is small (in depth
and width) and could be placed near the source/receiving
FFs.

To be certain that the synthesis tools will use distributed
structure for the FIFO/RAM , it's better to use the following
constraint in your .xdc file:

set_property RAM_STYLE DISTRIBUTED [
    get_cells -hier -filter {
        NAME =~ */cmp_fmc_adc_iface/*/cmp_adc_data_async_fifo/mem_reg*
    }
]

For future use, it's good to fix the area constraints
to ease testing.

This way, we don't need to change the top
SDB bridge layout to differentiate between
FMC130M and FMC250M designs.

Hdlmake can now takes care of this, so no need
for this file.

hdlmake release-3.0 commit 034553408a
implements this new feature.

This is generated by running the hdlmake
command.

Now, we rely on hdlmake 3.0 project generation,
which is easier to maintain.

The previous approach on using the syn_pre_cmd
in Manifest.py was not working very well, and
the hdlmake was not including the synthesis_descriptor_pkg
in the .xpr project.

In this way, we guarantee that we will have
the same environment for both platforms with the
only difference being the FMC-specfic files

This reverts commit 30c9e00f.

The IODELAY group was in fact correct.
Only the dbe_bpm design exhibits an error.
The dbe_bpm2 (FMC250M) is fine and
synthesized normally.

Xilinx MIG DDR core 4.0 (Vivado 2016.3) changed
the default generic for the IODELAY CTRL name.
So, we need to change it in our designs so
we can reuse the same iodelay controls as the
DDR MIG design, without having to worry about
replicating it by hand.

This path are slow by design and only
used after the acq_start_i signal, which
is asserted in software.

This is also important as we have changed
the topmost component of the design to
dbe_bpm_gen.

Previously we were using address different than
0x0, as LM32 required DPRAM in address 0x0.

However, this requirement is not existent anymore
and we are not using LM32 as of today.

Now, both designs use the generic
dbe_bpm_gen top design.

This is used by both FMC130 and
FMC250 top designs by modifying the
generic.