zcy
/
pluto_hdl_adi
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
pluto_hdl_adi/library/Makefile

230 lines
7.1 KiB
Makefile
Raw Normal View History

makefile: added
2015-04-01 20:26:23 +00:00
####################################################################################
####################################################################################
## Copyright 2011(c) Analog Devices, Inc.
## Auto-generated, do not modify!
####################################################################################
####################################################################################
Add quiet mode to the Makefile system 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>
2018-03-25 07:21:37 +00:00
include ../quiet.mk
Makefile: Added top level Makefile. Modified behavior of clean and clean-all Clean ran for a project will clean only the project files. Clean-all ran for a project will clean also the library files on which the project depends. The clean commands will only remove specific files and directories. The top Makefile allows several options(per suggestion from jameyhicks): make fmcomms1.zed will run "make all" in projects/fmcomms1/zed/ make clean will run "make clean" for all the projects make clean-all will run "make clean" for all the projects and libraries make lib will run "make all" for the library files
2015-04-17 14:22:38 +00:00
.PHONY: all lib clean clean-all
makefile: added
2015-04-01 20:26:23 +00:00
all: lib
clean:
Move Altera IP core dependency tracking to library Makefiles 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>
2018-03-27 09:21:09 +00:00
$(MAKE) -C altera/adi_jesd204 clean
$(MAKE) -C altera/avl_adxcfg clean
$(MAKE) -C altera/avl_adxcvr clean
$(MAKE) -C altera/avl_adxcvr_octet_swap clean
$(MAKE) -C altera/avl_adxphy clean
$(MAKE) -C altera/avl_dacfifo clean
$(MAKE) -C altera/axi_adxcvr clean
$(MAKE) -C altera/common/alt_ifconv clean
$(MAKE) -C altera/common/alt_mem_asym clean
$(MAKE) -C altera/common/alt_mul clean
$(MAKE) -C altera/common/alt_serdes clean
$(MAKE) -C altera/jesd204_phy clean
Make: Use $(MAKE) for recursive make commands This commit should resolve the issue #64. Recursive make commands should always use the variable MAKE, not the explicit command name ‘make’.
2018-03-06 12:36:06 +00:00
$(MAKE) -C axi_ad5766 clean
$(MAKE) -C axi_ad6676 clean
$(MAKE) -C axi_ad7616 clean
$(MAKE) -C axi_ad9122 clean
$(MAKE) -C axi_ad9144 clean
$(MAKE) -C axi_ad9152 clean
$(MAKE) -C axi_ad9162 clean
$(MAKE) -C axi_ad9250 clean
$(MAKE) -C axi_ad9265 clean
$(MAKE) -C axi_ad9361 clean
$(MAKE) -C axi_ad9371 clean
$(MAKE) -C axi_ad9434 clean
$(MAKE) -C axi_ad9467 clean
$(MAKE) -C axi_ad9625 clean
$(MAKE) -C axi_ad9671 clean
$(MAKE) -C axi_ad9680 clean
$(MAKE) -C axi_ad9684 clean
$(MAKE) -C axi_ad9739a clean
$(MAKE) -C axi_ad9963 clean
$(MAKE) -C axi_adc_decimate clean
$(MAKE) -C axi_adc_trigger clean
jesd204: Update Makefiles Fix jesd204 library build.
2018-06-11 07:35:13 +00:00
$(MAKE) -C axi_adrv9009 clean
Make: Use $(MAKE) for recursive make commands This commit should resolve the issue #64. Recursive make commands should always use the variable MAKE, not the explicit command name ‘make’.
2018-03-06 12:36:06 +00:00
$(MAKE) -C axi_clkgen clean
$(MAKE) -C axi_dac_interpolate clean
$(MAKE) -C axi_dmac clean
$(MAKE) -C axi_fmcadc5_sync clean
$(MAKE) -C axi_generic_adc clean
$(MAKE) -C axi_gpreg clean
$(MAKE) -C axi_hdmi_rx clean
$(MAKE) -C axi_hdmi_tx clean
$(MAKE) -C axi_i2s_adi clean
$(MAKE) -C axi_intr_monitor clean
$(MAKE) -C axi_logic_analyzer clean
$(MAKE) -C axi_mc_controller clean
$(MAKE) -C axi_mc_current_monitor clean
$(MAKE) -C axi_mc_speed clean
axi_pulse_gen: Initial commit The axi_pulse_gen is a generic PWM generator, which can be configured through an AXI Memory Mapped interface. The current register map look like follows: 0x00 - VERSION 0x04 - ID 0x08 - SCRATCH 0x0C - IDENTIFICATION - 0x504c5347 which stands for 'PLSG' in ASCII 0x10 - CONFIGURATION - contains reset and load bits 0x14 - PULSE_PERIOD 0x18 - PULSE_WIDTH Also update all the other modules, which instantiate the util_pulse_gen.
2019-03-19 16:38:32 +00:00
$(MAKE) -C axi_pulse_gen clean
Make: Use $(MAKE) for recursive make commands This commit should resolve the issue #64. Recursive make commands should always use the variable MAKE, not the explicit command name ‘make’.
2018-03-06 12:36:06 +00:00
$(MAKE) -C axi_rd_wr_combiner clean
$(MAKE) -C axi_spdif_rx clean
$(MAKE) -C axi_spdif_tx clean
$(MAKE) -C axi_usb_fx3 clean
$(MAKE) -C cn0363/cn0363_dma_sequencer clean
$(MAKE) -C cn0363/cn0363_phase_data_sync clean
$(MAKE) -C cordic_demod clean
library: Add a generic JESD204 ADC receiver core 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>
2017-05-05 16:53:39 +00:00
$(MAKE) -C jesd204/ad_ip_jesd204_tpl_adc clean
library: Add a generic JESD204 DAC receiver core 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>
2017-05-05 16:54:09 +00:00
$(MAKE) -C jesd204/ad_ip_jesd204_tpl_dac clean
Make: Use $(MAKE) for recursive make commands This commit should resolve the issue #64. Recursive make commands should always use the variable MAKE, not the explicit command name ‘make’.
2018-03-06 12:36:06 +00:00
$(MAKE) -C jesd204/axi_jesd204_common clean
$(MAKE) -C jesd204/axi_jesd204_rx clean
$(MAKE) -C jesd204/axi_jesd204_tx clean
$(MAKE) -C jesd204/jesd204_common clean
$(MAKE) -C jesd204/jesd204_rx clean
$(MAKE) -C jesd204/jesd204_rx_static_config clean
Move Altera IP core dependency tracking to library Makefiles 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>
2018-03-27 09:21:09 +00:00
$(MAKE) -C jesd204/jesd204_soft_pcs_rx clean
$(MAKE) -C jesd204/jesd204_soft_pcs_tx clean
Make: Use $(MAKE) for recursive make commands This commit should resolve the issue #64. Recursive make commands should always use the variable MAKE, not the explicit command name ‘make’.
2018-03-06 12:36:06 +00:00
$(MAKE) -C jesd204/jesd204_tx clean
$(MAKE) -C jesd204/jesd204_tx_static_config clean
$(MAKE) -C spi_engine/axi_spi_engine clean
$(MAKE) -C spi_engine/spi_engine_execution clean
$(MAKE) -C spi_engine/spi_engine_interconnect clean
$(MAKE) -C spi_engine/spi_engine_offload clean
$(MAKE) -C util_adcfifo clean
$(MAKE) -C util_axis_fifo clean
$(MAKE) -C util_axis_resize clean
util_axis_upscale: Initial commit 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.
2017-10-16 09:43:20 +00:00
$(MAKE) -C util_axis_upscale clean
Make: Use $(MAKE) for recursive make commands This commit should resolve the issue #64. Recursive make commands should always use the variable MAKE, not the explicit command name ‘make’.
2018-03-06 12:36:06 +00:00
$(MAKE) -C util_bsplit clean
$(MAKE) -C util_cdc clean
$(MAKE) -C util_cic clean
$(MAKE) -C util_clkdiv clean
$(MAKE) -C util_dacfifo clean
$(MAKE) -C util_delay clean
$(MAKE) -C util_extract clean
$(MAKE) -C util_fir_dec clean
$(MAKE) -C util_fir_int clean
$(MAKE) -C util_gmii_to_rgmii clean
$(MAKE) -C util_i2c_mixer clean
$(MAKE) -C util_mfifo clean
Add util_cpack2 core 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>
2018-03-30 08:37:45 +00:00
$(MAKE) -C util_pack/util_cpack2 clean
Add util_upack2 core 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>
2018-10-07 12:39:27 +00:00
$(MAKE) -C util_pack/util_upack2 clean
Make: Use $(MAKE) for recursive make commands This commit should resolve the issue #64. Recursive make commands should always use the variable MAKE, not the explicit command name ‘make’.
2018-03-06 12:36:06 +00:00
$(MAKE) -C util_pulse_gen clean
$(MAKE) -C util_rfifo clean
$(MAKE) -C util_sigma_delta_spi clean
$(MAKE) -C util_tdd_sync clean
$(MAKE) -C util_var_fifo clean
$(MAKE) -C util_wfifo clean
$(MAKE) -C xilinx/axi_adcfifo clean
$(MAKE) -C xilinx/axi_adxcvr clean
$(MAKE) -C xilinx/axi_dacfifo clean
$(MAKE) -C xilinx/axi_xcvrlb clean
$(MAKE) -C xilinx/util_adxcvr clean
makefile: updated
2015-04-07 20:32:01 +00:00
Make: Use $(MAKE) for recursive make commands This commit should resolve the issue #64. Recursive make commands should always use the variable MAKE, not the explicit command name ‘make’.
2018-03-06 12:36:06 +00:00
$(MAKE) -C interfaces clean
Make: Update Makefiles
2017-02-10 14:32:58 +00:00
makefile: updated
2015-04-07 20:32:01 +00:00
clean-all:clean
makefile: added
2015-04-01 20:26:23 +00:00
lib:
Move Altera IP core dependency tracking to library Makefiles 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>
2018-03-27 09:21:09 +00:00
$(MAKE) -C altera/adi_jesd204
$(MAKE) -C altera/avl_adxcfg
$(MAKE) -C altera/avl_adxcvr
$(MAKE) -C altera/avl_adxcvr_octet_swap
$(MAKE) -C altera/avl_adxphy
$(MAKE) -C altera/avl_dacfifo
$(MAKE) -C altera/axi_adxcvr
$(MAKE) -C altera/common/alt_ifconv
$(MAKE) -C altera/common/alt_mem_asym
$(MAKE) -C altera/common/alt_mul
$(MAKE) -C altera/common/alt_serdes
$(MAKE) -C altera/jesd204_phy
Make: Use $(MAKE) for recursive make commands This commit should resolve the issue #64. Recursive make commands should always use the variable MAKE, not the explicit command name ‘make’.
2018-03-06 12:36:06 +00:00
$(MAKE) -C axi_ad5766
$(MAKE) -C axi_ad6676
$(MAKE) -C axi_ad7616
$(MAKE) -C axi_ad9122
$(MAKE) -C axi_ad9144
$(MAKE) -C axi_ad9152
$(MAKE) -C axi_ad9162
$(MAKE) -C axi_ad9250
$(MAKE) -C axi_ad9265
$(MAKE) -C axi_ad9361
$(MAKE) -C axi_ad9371
$(MAKE) -C axi_ad9434
$(MAKE) -C axi_ad9467
$(MAKE) -C axi_ad9625
$(MAKE) -C axi_ad9671
$(MAKE) -C axi_ad9680
$(MAKE) -C axi_ad9684
$(MAKE) -C axi_ad9739a
$(MAKE) -C axi_ad9963
$(MAKE) -C axi_adc_decimate
$(MAKE) -C axi_adc_trigger
jesd204: Update Makefiles Fix jesd204 library build.
2018-06-11 07:35:13 +00:00
$(MAKE) -C axi_adrv9009
Make: Use $(MAKE) for recursive make commands This commit should resolve the issue #64. Recursive make commands should always use the variable MAKE, not the explicit command name ‘make’.
2018-03-06 12:36:06 +00:00
$(MAKE) -C axi_clkgen
$(MAKE) -C axi_dac_interpolate
$(MAKE) -C axi_dmac
$(MAKE) -C axi_fmcadc5_sync
$(MAKE) -C axi_generic_adc
$(MAKE) -C axi_gpreg
$(MAKE) -C axi_hdmi_rx
$(MAKE) -C axi_hdmi_tx
$(MAKE) -C axi_i2s_adi
$(MAKE) -C axi_intr_monitor
$(MAKE) -C axi_logic_analyzer
$(MAKE) -C axi_mc_controller
$(MAKE) -C axi_mc_current_monitor
$(MAKE) -C axi_mc_speed
axi_pulse_gen: Initial commit The axi_pulse_gen is a generic PWM generator, which can be configured through an AXI Memory Mapped interface. The current register map look like follows: 0x00 - VERSION 0x04 - ID 0x08 - SCRATCH 0x0C - IDENTIFICATION - 0x504c5347 which stands for 'PLSG' in ASCII 0x10 - CONFIGURATION - contains reset and load bits 0x14 - PULSE_PERIOD 0x18 - PULSE_WIDTH Also update all the other modules, which instantiate the util_pulse_gen.
2019-03-19 16:38:32 +00:00
$(MAKE) -C axi_pulse_gen
Make: Use $(MAKE) for recursive make commands This commit should resolve the issue #64. Recursive make commands should always use the variable MAKE, not the explicit command name ‘make’.
2018-03-06 12:36:06 +00:00
$(MAKE) -C axi_rd_wr_combiner
$(MAKE) -C axi_spdif_rx
$(MAKE) -C axi_spdif_tx
$(MAKE) -C axi_usb_fx3
$(MAKE) -C cn0363/cn0363_dma_sequencer
$(MAKE) -C cn0363/cn0363_phase_data_sync
$(MAKE) -C cordic_demod
library: Add a generic JESD204 ADC receiver core 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>
2017-05-05 16:53:39 +00:00
$(MAKE) -C jesd204/ad_ip_jesd204_tpl_adc
library: Add a generic JESD204 DAC receiver core 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>
2017-05-05 16:54:09 +00:00
$(MAKE) -C jesd204/ad_ip_jesd204_tpl_dac
Make: Use $(MAKE) for recursive make commands This commit should resolve the issue #64. Recursive make commands should always use the variable MAKE, not the explicit command name ‘make’.
2018-03-06 12:36:06 +00:00
$(MAKE) -C jesd204/axi_jesd204_common
$(MAKE) -C jesd204/axi_jesd204_rx
$(MAKE) -C jesd204/axi_jesd204_tx
$(MAKE) -C jesd204/jesd204_common
$(MAKE) -C jesd204/jesd204_rx
$(MAKE) -C jesd204/jesd204_rx_static_config
Move Altera IP core dependency tracking to library Makefiles 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>
2018-03-27 09:21:09 +00:00
$(MAKE) -C jesd204/jesd204_soft_pcs_rx
$(MAKE) -C jesd204/jesd204_soft_pcs_tx
Make: Use $(MAKE) for recursive make commands This commit should resolve the issue #64. Recursive make commands should always use the variable MAKE, not the explicit command name ‘make’.
2018-03-06 12:36:06 +00:00
$(MAKE) -C jesd204/jesd204_tx
$(MAKE) -C jesd204/jesd204_tx_static_config
$(MAKE) -C spi_engine/axi_spi_engine
$(MAKE) -C spi_engine/spi_engine_execution
$(MAKE) -C spi_engine/spi_engine_interconnect
$(MAKE) -C spi_engine/spi_engine_offload
$(MAKE) -C util_adcfifo
$(MAKE) -C util_axis_fifo
$(MAKE) -C util_axis_resize
util_axis_upscale: Initial commit 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.
2017-10-16 09:43:20 +00:00
$(MAKE) -C util_axis_upscale
Make: Use $(MAKE) for recursive make commands This commit should resolve the issue #64. Recursive make commands should always use the variable MAKE, not the explicit command name ‘make’.
2018-03-06 12:36:06 +00:00
$(MAKE) -C util_bsplit
$(MAKE) -C util_cdc
$(MAKE) -C util_cic
$(MAKE) -C util_clkdiv
$(MAKE) -C util_dacfifo
$(MAKE) -C util_delay
$(MAKE) -C util_extract
$(MAKE) -C util_fir_dec
$(MAKE) -C util_fir_int
$(MAKE) -C util_gmii_to_rgmii
$(MAKE) -C util_i2c_mixer
$(MAKE) -C util_mfifo
Add util_cpack2 core 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>
2018-03-30 08:37:45 +00:00
$(MAKE) -C util_pack/util_cpack2
Add util_upack2 core 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>
2018-10-07 12:39:27 +00:00
$(MAKE) -C util_pack/util_upack2
Make: Use $(MAKE) for recursive make commands This commit should resolve the issue #64. Recursive make commands should always use the variable MAKE, not the explicit command name ‘make’.
2018-03-06 12:36:06 +00:00
$(MAKE) -C util_pulse_gen
$(MAKE) -C util_rfifo
$(MAKE) -C util_sigma_delta_spi
$(MAKE) -C util_tdd_sync
$(MAKE) -C util_var_fifo
$(MAKE) -C util_wfifo
$(MAKE) -C xilinx/axi_adcfifo
$(MAKE) -C xilinx/axi_adxcvr
$(MAKE) -C xilinx/axi_dacfifo
$(MAKE) -C xilinx/axi_xcvrlb
$(MAKE) -C xilinx/util_adxcvr
hdlmake- updates
2017-04-27 19:11:01 +00:00
Make: Use $(MAKE) for recursive make commands This commit should resolve the issue #64. Recursive make commands should always use the variable MAKE, not the explicit command name ‘make’.
2018-03-06 12:36:06 +00:00
$(MAKE) -C interfaces
Make: Update Makefiles
2017-02-10 14:32:58 +00:00
makefile: added
2015-04-01 20:26:23 +00:00
####################################################################################
####################################################################################