Having a bd.tcl script in every IP is redundant.
adi_ip.tcl:
- add adi_init_bd_tcl - creates a blanch bd.tcl and a
parameters temporary_case_dependencies.mk when compiling an IP.
Its main purpose is to generate the bd.tcl, which will be included in
the IP's file-set.
- adi_auto_fill_bd_tcl will populate the empty bd.tcl based on the
top IP parameters and the presence of these parameters in
auto_set_param_list and auto_set_param_list_overwritable lists.
This task can not be performed by the first described procedure since
the file-set is not yet defined.
adi_xilinx_device_info_enc.tcl:
Split auto_set_param_list_overwritable from auto_set_param_list. As
the name states, some of the parameters are overwritable, this will help
when generating the bd.tcl script.
library.mk:
Include the temporary_case_dependencies.mk if it exists in the
IP root folder. The mentioned *.mk file contains non generic
dependencies for makefiles like targets to clean.
Common basic steps:
- Include/create infrastructure:
* Intel:
- require quartus::device package
- set_module_property VALIDATION_CALLBACK info_param_validate
* Xilinx
- add bd.tcl, containing init{} procedure. The init procedure will be
called when the IP will be instantiated into the block design.
- add to the xilinx_blockdiagram file group the bd.tcl and common_bd.tcl
- create GUI files
- add parameters in *_ip.tcl and *_hw.tcl (adi_add_auto_fpga_spec_params)
- add/propagate the info parameters through the IP verilog files
axi_clkgen
util_adxcvr
ad_ip_jesd204_tpl_adc
ad_ip_jesd204_tpl_dac
axi_ad5766
axi_ad6676
axi_ad9122
axi_ad9144
axi_ad9152
axi_ad9162
axi_ad9250
axi_ad9265
axi_ad9680
axi_ad9361
axi_ad9371
axi_adrv9009
axi_ad9739a
axi_ad9434
axi_ad9467
axi_ad9684
axi_ad9963
axi_ad9625
axi_ad9671
axi_hdmi_tx
axi_fmcadc5_sync
Xilinx:
When calling adi_auto_fpga_spec_params in the x_ip.tcl, parameters like
- FPGA_TECHNOLOGY
- FPGA_FAMILY
- SPEED_GRADE
- DEV_PACKAGE
- XCVR_TYPE
- FPGA_VOLTAGE
will be automatically detected and constrained to predefined pairs of values
from adi_xilinx_device_info_env.tcl
The parameters specified in the blobk diagram of the IP(bd.tcl), will be
automatically assign when the IP is added to a block design.
The "adi_auto_assign_device_spec $cellpath" is called in the init
hook (bd.tcl).
https://www.xilinx.com/products/technology/high-speed-serial.html
Intel:
Info parameters are set in the VALIDATION_CALLBACK according to
adi_intel_device_info_env.tcl
Fix the following warning:
WARNING: [Synth 8-2611] redeclaration of ANSI port up_es_reset is not allowed
Also make sure, that in all configurations, the register has a diver.
Add support for 8 bit resolution for the transport layer.
Fix parameter BITS_PER_SAMPLES propagation to all the internal modules, in
several cases this variable was hard coded to 16.
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.
To prevent the case, when after an invalid configuration, the generated
output PWM signal is constant HIGH, change the counter to a
down-counter. In this way the pulse will be placed at the end of the
PWM period, and if the configured width value is higher than the
configured period the output signal will be constant LOW.
Write code to pipeline data path for better DSP utilization on the
color space conversion.
In the old method the addition operations were performed outside the
DSPs
The FIFO functions in 'first fall through' mode, adjust the fifo level
generation so it take into account the valid data which sits on the bus,
waiting for ready, too.
Current implementation does not supports updated versions of Vivado
e.g. 2017.4.1 or 2018.2.1
This fix ignores the update number from the version checking.
Registers from this component can fit in the 2k address range.
Since Vivado's minimal address range is 4k, use that instead.
This will allow placing the independent TPLs to base addresses
that mach the addresses from the monolithic blocks ensuring no software
intervention.
The DMAC has the requirement that the length of the transfer is aligned to
the widest interface width. E.g. if the widest interface is 256 bit or 32
bytes the length of the transfer needs to be a multiple of 32.
This restriction can be relaxed for the memory mapped interfaces. This is
done by partially ignoring data of a beat from/to the MM interface.
For write access the stb bits are used to mask out bytes that do not
contain valid data.
For read access a full beat is read but part of the data is discarded. This
works fine as long as the read access is side effect free. I.e. this method
should not be used to access data from memory mapped peripherals like a
FIFO.
This means that for example the length alignment requirement of a DMA
configured for a 64-bit memory and a 16-bit streaming interface is now only
2 bytes instead of 8 bytes as before.
Note that the address alignment requirement is not affected by this. The
address still needs to be aligned to the width of the MM interface that it
belongs to.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>