The new REG_PRBS_CNTRL and REG_PRBS_STATUS registers expose controls of internal
PRBS generators and checkers allowing the testing the multi-gigabit serial link
at the physical layer without the need of the link layer bringup.
parameters with same names were duplicated with transceiver specific
names due different default values.
This does not scales very well.
Use same name for the parameters as for other parameters and do the
default value handling in the IP configuration layer.
These parameters must be overwritten when the link is at 15Gbps.
The parameters have a GTY4_ prefix since the same parameters are shared
between GTY4 and GTH4 having different default values.
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
Expose the TX configurable driver ports, more specifically the
TX_DIFFCTRL, TX_POSTCURSORE and TX_PRECURSORE for software. This
provides a soft tunning capability of the transmit side of the
transceivers, in cases where the insertion loss of the channel is too
high or low, comparing to the default value supported by the default
configuration of the GTs.
You can find information about these configuration ports under the
section called 'TX Configurable Driver' in the GT transceivers user
guide. (UG476, UG576)
This commit does not contain any functional modification.
Because the wizard generates the attributes in binary, we should use
binary mode too, so we can compare different configurations more easily.
Some designs choose to swap the positive and negative side of the of the
JESD204 lanes. One reason for this would be because it can simplify the
PCB layout. The polarity is in most cases also only applied to a subset of
the used lanes.
Add support for this to the util_adxcvr module. This done by adding new
parameter to the modules that allows to specify a per lane polarity
inversion. Each bit in the parameter corresponds to one lane. If the bit is
set the polarity is inverted for his lane. E.g. setting the parameter to
0xc will invert the 3rd and 4th lane.
The setting is forwarded to the Xilinx transceiver for the corresponding
lane.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
When using non-broadcast access to the GT DRP registers lane filtering is
done on both sides. The ready and data signals are filtered in the in the
axi_adxcvr module and the enable signal is filtered in the util_adxcvr
module. This works fine as long as both sides use the same transceiver IDs.
E.g. channel 0 of the axi_adxcvr module is connected to channel 0 of the
util_adxcvr module.
But this is not always the case. E.g. on the ADRV9371 platform there are
two RX axi_adxcvr modules (RX and RX_OS) connected to the same util_adxcvr.
The first axi_adxcvr uses lane 0 and 1 of the util_adxcvr, the second uses
lane 2 and 3.
Non-broadcast access for the first RX axi_adxcvr module works fine, but
always generates a timeout for the second axi_adxcvr module. This is
because lane 0/1 of the axi_adxcvr module is connected to lane 2/3 of the
util_adxcvr and when ID based filtering is done both can't match at the
same time.
To avoid this perform the filtering for all the signals in the axi_adxcvr
module. This makes sure that the same base ID is used.
This also removes the sel signal from the transceiver interfaces since it
is no longer used on the util_adxcvr side.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
All the hdl (verilog and vhdl) source files were updated. If a file did not
have any license, it was added into it. Files, which were generated by
a tool (like Matlab) or were took over from other source (like opencores.org),
were unchanged.
New license looks as follows:
Copyright 2014 - 2017 (c) Analog Devices, Inc. All rights reserved.
Each core or library found in this collection may have its own licensing terms.
The user should keep this in in mind while exploring these cores.
Redistribution and use in source and binary forms,
with or without modification of this file, are permitted under the terms of either
(at the option of the user):
1. The GNU General Public License version 2 as published by the
Free Software Foundation, which can be found in the top level directory, or at:
https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html
OR
2. An ADI specific BSD license as noted in the top level directory, or on-line at:
https://github.com/analogdevicesinc/hdl/blob/dev/LICENSE
Laszlo Nagy
Adrian Costina
Istvan Csomortani
AndreiGrozav
Lars-Peter Clausen
Rejeesh Kutty