All projects have been updated to use the new pack/unpack infrastructure.
The old util_cpack and util_upack cores are now unused an can be removed.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The util_cpack2 core is similar to the util_upack core. It packs, or
interleaves, a data from multiple ports into a single data. Ports can
optionally be enabled or disabled.
On the input side the cpack2 core uses a multi-port FIFO interface. There
is a single data write signal (fifo_wr_en) for all ports. But each port can
be individually enabled or disabled using the enable signals.
On the output side the cpack2 core uses a single port FIFO interface. When
data is available on the output interface the data write signal
(packed_fifo_wr_en). Data on the packed_fifo_wr_data signal is only valid
when packed_fifo_wr_en is asserted. At other times the content is
undefined. The cpack2 core offers no back-pressure. If data is not consumed
when it is made available it will be lost.
Data from the input ports is accumulated inside the cpack2 core and if
enough data is available to produce a full output vector the data is
forwarded.
This core is build using the common pack infrastructure. The core that is
specific to the cpack2 core is mainly only responsible for generating the
control signals for the external interfaces.
The core is accompanied by a test bench that verifies correct behavior for
all possible combinations of enable masks.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The util_upack2 core is similar to the util_upack core. It unpacks, or
deinterleaves, a data stream onto multiple ports.
The upack2 core uses a streaming AXI interface for its data source instead
of a FIFO interface like the upack core uses.
On the output side the upack2 core uses a multi-port FIFO interface. There
is a single data request signal (fifo_rd_en) for all ports. But each port
can be individually enabled or disabled using the enable signals.
This modified architecture allows the upack2 core to better generate the
valid and underflow control signals to indicate whether data is available
in a response to a data request.
If fifo_rd_en is asserted and data is available the fifo_rd_valid signal
are asserted in the following clock cycle. The enabled fifo_rd_data ports
will be contain valid data during the same clock cycle as fifo_rd_valid is
asserted. During other clock cycles the output data is undefined. On
disabled ports the data is always undefined.
If no data is available instead the fifo_rd_underflow signal is asserted in
the following clock cycle and the output of all fifo_rd_data ports is
undefined.
This core is build using the common pack infrastructure. The core that is
specific to the upack2 core is mainly only responsible for generating the
control signals for the external interfaces.
The core is accompanied by a test bench that verifies correct behavior for
all possible combinations of enable masks.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
For most of the DACs that use JESD204 as the data transport the digital
interface is very similar. They are mainly differentiated by number of
JESD204 lanes, number of converter channels and number of bits per sample.
Currently for each supported converter there exists a converter specific
core which has the converter specific requirements hard-coded.
Introduce a new generic core that has the number of lanes, number of
channels and bits per sample as synthesis-time configurable parameters. It
can be used as a drop-in replacement for the existing converter specific
cores.
This has the advantage of a shared and reduced code base. Code improvements
will automatically be available for all converters and don't have to be
manually ported to each core individually.
It also makes it very easy to introduce support for new converters that
follow the existing schema.
Since the JESD204 framer is now procedurally generated it is also very
easy to support board or application specific requirements where the lane
to converter ratio differs from the default (E.g. use 2 lanes/2 converters
instead of 4 lanes/2 converters).
This new core is primarily based on the existing axi_ad9144.
For the time being the core is not user instantiatable and will only be
used as a based to re-implement the converter specific cores. It will be
extended in the future to allow user instantiation.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
For most of the ADCs that use JESD204 as the data transport the digitial
interface is very similar. They are mainly differentiated by number of
JESD204 lanes, number of converter channels and number of bits per sample.
Currently for each supported converter there exists a converter specific
core which has the converter specific requirements hard-coded.
Introduce a new generic core that has the number of lanes, number of
channels and bits per sample as synthesis-time configurable parameters. It
can be used as a drop-in replacement for the existing converter specific
cores.
This has the advantage of a shared and reduced code base. Code improvements
will automatically be available for all converters and don't have to be
manually ported to each core individually.
It also makes it very easy to introduce support for new converters that
follow the existing schema.
Since the JESD204 deframer is now procedurally generated it is also very
easy to support board or application specific requirements where the lane
to converter ratio differs from the default (E.g. use 2 lanes/2 converters
instead of 4 lanes/2 converters).
This new core is primarily based on the existing axi_ad9680.
For the time being the core is not user instantiatable and will only be
used as a based to re-implement the converter specific cores. It will be
extended in the future to allow user instantiation.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The standard Makefile output is very noisy and it can be difficult to
filter the interesting information from this noise.
In quiet mode the standard Makefile output will be suppressed and instead a
short human readable description of the current task is shown.
E.g.
> make adv7511.zed
Building axi_clkgen library [library/axi_clkgen/axi_clkgen_ip.log] ... OK
Building axi_hdmi_tx library [library/axi_hdmi_tx/axi_hdmi_tx_ip.log] ... OK
Building axi_i2s_adi library [library/axi_i2s_adi/axi_i2s_adi_ip.log] ... OK
Building axi_spdif_tx library [library/axi_spdif_tx/axi_spdif_tx_ip.log] ... OK
Building util_i2c_mixer library [library/util_i2c_mixer/util_i2c_mixer_ip.log] ... OK
Building adv7511_zed project [projects/adv7511/zed/adv7511_zed_vivado.log] ... OK
Quiet mode is enabled by default since it generates a more human readable
output. It can be disabled by passing VERBOSE=1 to make or setting the
VERBOSE environment variable to 1 before calling make.
E.g.
> make adv7511.zed VERBOSE=1
make[1]: Entering directory 'library/axi_clkgen'
rm -rf *.cache *.data *.xpr *.log component.xml *.jou xgui
*.ip_user_files *.srcs *.hw *.sim .Xil .timestamp_altera
vivado -mode batch -source axi_clkgen_ip.tcl >> axi_clkgen_ip.log 2>&1
...
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Currently the individual IP core dependencies are tracked inside the
library Makefile for Xilinx IPs and the project Makefiles only reference
the IP cores.
For Altera on the other hand the individual dependencies are tracked inside
the project Makefile. This leads to a lot of duplicated lists and also
means that the project Makefiles need to be regenerated when one of the IP
cores changes their files.
Change the Altera projects to a similar scheme than the Xilinx projects.
The projects themselves only reference the library as a whole as their
dependency while the library Makefile references the individual source
dependencies.
Since on Altera there is no target that has to be generated create a dummy
target called ".timestamp_altera" who's only purpose is to have a timestamp
that is greater or equal to the timestamp of all of the IP core files. This
means the project Makefile can have a dependency on this file and make sure
that the project will be rebuild if any of the files in the library
changes.
This patch contains quite a bit of churn, but hopefully it reduces the
amount of churn in the future when modifying Altera IP cores.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
This module upscale an n*sample_width data bus into a 16 or 32*n data
bus. The samples are right aligned and supports offset binary or two's
complement data format.
The ADI JESD204 link layer cores are a implementation of the JESD204 link
layer. They are responsible for handling the control signals (like SYNC and
SYSREF) and controlling the link state machine as well as performing
per-lane (de-)scrambling and character replacement.
Architecturally the cores are separated into two components.
1) Protocol processing cores (jesd204_rx, jesd204_tx). These cores take
care of the JESD204 protocol handling. They have configuration and status
ports that allows to configure their behaviour and monitor the current
state. The processing cores run entirely in the lane_rate/40 clock domain.
They have a upstream and a downstream port that accept and generate raw PHY
level data and transport level payload data (which is which depends on the
direction of the core).
2) Configuration interface cores (axi_jesd204_rx, axi_jesd204_tx). The
configuration interface cores provide a register map interface that allow
access to the to the configuration and status interfaces of the processing
cores. The configuration cores are responsible for implementing the clock
domain crossing between the lane_rate/40 and register map clock domain.
These new cores are compatible to all ADI converter products using the
JESD204 interface.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Move the CDC helper modules to a dedicated helper modules. This makes it
possible to reference them without having to use file paths that go outside
of the referencing project's directory.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Sort the entries in the library Makefile alphabetical. Keeping it ordered
makes it easier to track changes compared to randomly reshuffling it
every time a new entry is added.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The read and write interfaces of a AXI bus are independent other than that
they use the same clock. Yet when connecting a single read-only and a
single write-only interface to a Xilinx AXI interconnect it instantiates
arbitration logic between the two interfaces. This is dead logic and
unnecessarily utilizes the FPGAs resources.
Introduce a new helper module that takes a read-only and a write-only AXI
interface and combines them into a single read-write interface. The only
restriction here is that all three interfaces need to use the same clock.
This module is useful for systems which feature a read DMA and a write DMA.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
A synchronization signal generator for AD9361 running on TDD mode.
If the associated device is master, the module generates a pulse in a defined interval. Otherwise receives the sync signal from outside.
Lars-Peter Clausen
AndreiGrozav
Adrian Costina
Istvan Csomortani
Rejeesh Kutty