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.
When we improve timing by modifying the implementation strategies,
the general rule of thumb is "less is always more".
Timing did not fail in synthesis, so we leaving the synthesis
strategy in default.
After several parallel runs with various strategies, the
"Performance_Explore" strategy gave the best result for
implementation.
Each individual link of a multi-link has its own sync signal. The top level
sync port that is created by the ad_xcvrcon function is always a single bit
single though.
This results in only the sync signal of the first link being routed while
others are ignored.
To fix this make sure that for multi-link setups the sync port is a vector
port with the width equal to the number of links.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
If the req_valid asserts faster than the ID gets synchronized over we
assert the xfer request without being ready to accept data.
This can lead to overflow assertion when using a FIFO like interface.
Data mover/ src axis changes
Request rewind ID if TLAST received during non-last burst
Consume (ignore) descriptors until last segment received
Block descriptors towards destination until last segment received
Request generator changes
Rewind the burst ID if rewind request received
Consume (ignore) descriptors until last segment received
If TLAST happened on last segment replay next transfer (in progress or
completed) with the adjusted ID
Create completion requests for ignored segments
Response generator changes
Track requests
Complete segments which got ignored
Length of partial transfers are stored in a queue for SW reads.
The presence of partial transfer is indicated by a status bit.
The reporting can be enabled by a control bit.
The progress of any transfer can be followed by a debug register.
Drive the descriptor from the source side to destination
so we can abort consecutive transfers in case TLAST asserts.
For AXIS count the length of the burst and pass that value to the
destination instead the programmed one. This is useful when the
streams aborts early by asserting the TLAST. We want to notify the
destination with the right number of beats received.
For FIFO source interface reuse the same logic due the small footprint
even if the stream does not got interrupted in that case.
For MM source interface wire the burst length from the request side to
destination.
- refclk and refclk_rst were used for ethernet IDELAY, but are not needed anymore
- muxaddr_out pins overlap with regular GPIOs in the Zed base design. The XADC mux GPIOs can be controlled through that. Cusomters that want to directly control the pins through XADC IP must modify the design
The system_db folder is autogenerated and contains all the files that are
generated by the Platform Designer tool.
The extension for Intel binary bitstreams is rbf.
Add both of those to the .gitignore since they should not be under version
control and just end up as clutter in `git status` otherwise.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The constraint for the synchronizer that synchronizes the sync_status
signal of the link only works correctly for the first link. For other links
no timing exception is applied, which leads to timing failures.
Fix this by using a wildcard constraint for the synchronizer reg number.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
If DDS_DW is equal to DDS_D_DW there is no signal truncation and
consequentially no rounding should be performed. But the check whether
rounding should be performed currently is for if DDS_DW is less or equal to
DDS_D_DW.
When both are equal C_T_WIDTH is 0. This results in the expression
'{(C_T_WIDTH){dds_data_int[DDS_D_DW-1]}};' being a 0 width signal. This is
not legal Verilog, but both the Intel and Xilinx tools seem to accept it
nevertheless.
But the iverilog simulation tools generates the following error:
ad_dds_2.v:102: error: Concatenation repeat may not be zero in this context.
Xilinx Vivado also generates the following warning:
WARNING: [Synth 8-693] zero replication count - replication ignored [ad_dds_2.v:102]
Change the condition so that truncation is only performed when DDS_DW is
less than DDS_D_DW. This fixes both the error and the warning.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The DISPLAY_NAME of a module is supposed to be a short human readable
description of the IP core.
Currently this is set to the name of the IP, which already has its own
property called NAME.
This causes Platform Designer to display the descriptive labels if the IP
core basically as "$ip_core_name ($ip_core_name)".
The value that all current user of ad_ip_create pass for the description
parameter matches this criteria (And not so much the requirements for the
actual DESCRIPTION property).
Change things, so that the DISPLAY_NAME property is set to what is
currently passed as the description parameter.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
In default strategy we having a few path with small negative slack inside of
the MIG, due to the high UI clock (300MHz).
This new strategy solves this issue.
The Xilinx's reset interface expect that every reset have an associated
interface and clock signal. The tool will try to find its clock and interface,
and automatically associated clock signal to it.
The PLL resets are individual asynchronous resets. To simplify the design
and avoid invalid critical warnings all the reset interface inference
for the PLL resets were removed.
Most converters refer to their different operating modes as a "Mode X"
(where X is a number) in their datasheet. Each mode has a specific framer
configuration associated with it.
Provide a set of Platform Designer (previously known as Qsys) preset files
for each mode. This allows to quickly select a specific operating mode
without having to lookup the corresponding framer configuration from the
datasheet.
A preset can be selected either in the Platform Designer GUI or from a tcl
script using the apply_preset command. E.g.
add_instance ad9172_transport ad_ip_jesd204_tpl_dac
apply_preset ad9172_transport "AD9172 Mode 10"
The preset files are generated using the scripts/generate_presets.py
script and the scripts/modes.txt file.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
A converter typically only supports a specific subset of framer
configurations.
Add a configuration parameter to select a specific converter part number.
Based on the selected part a mode validation will be performed and if the
selected framer configuration is not supported by the part an error will be
generated.
This helps to catch invalid configurations early on rather than having to
first build the bitstream and then notice that it does not work.
When using "Generic" for the part configuration parameter no validation
will be done and any framer configuration can be selected.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The exact layout of the input data into the DAC transport layer core
depends on the framer configuration. The number of input channels is
always equal to the NUM_CHANNELS parameter, but the number of samples per
channel per beat depends on the ratio of number of lanes, number of
channels and bits per sample.
It is possible to compute this manually, but this might require in-depth
knowledge about how the JESD204 framer works. Add read-only parameters that
display the number of samples per channel per beat as well as the total
width of the channel data signal.
This information can also be queried in QSys scripts and used to
automatically configure the input pipeline. E.g. like the upack core:
set NUM_OF_CHANNELS [get_instance_parameter_value jesd204_transport NUM_CHANNELS]
set CHANNEL_DATA_WIDTH [get_instance_parameter_value jesd204_transport CHANNEL_DATA_WIDTH]
add_instance util_dac_upack util_upack
set_instance_parameter_values util_dac_upack [list \
CHANNEL_DATA_WIDTH $CHANNEL_DATA_WIDTH \
NUM_OF_CHANNELS $NUM_OF_CHANNELS \
]
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
AndreiGrozav
Istvan Csomortani
Laszlo Nagy
Lars-Peter Clausen
Adrian Costina