Add support for specifying a set of parameter value pairs when
instantiating an IP core to the ad_ip_instance command. This has the
convenience of not having to repeatedly call ad_ip_parameter with the name
of the core that got just created for each parameter that needs to be set.
It is also useful for cases where some parameters have mutually exclusive
values and both (or more) have to be set at the same time.
This also slightly speeds things up. Whenever a parameter is changed the
core needs to be updated and post configuration scripts might run. When
setting all parameters at the same time this only happens once instead of
once for each parameter.
For example the following sequence
ad_ip_instance axi_dmac axi_ad9136_dma
ad_ip_parameter axi_ad9136_dma CONFIG.DMA_TYPE_SRC 0
ad_ip_parameter axi_ad9136_dma CONFIG.DMA_TYPE_DEST 1
ad_ip_parameter axi_ad9136_dma CONFIG.DMA_DATA_WIDTH_SRC 64
ad_ip_parameter axi_ad9136_dma CONFIG.DMA_DATA_WIDTH_DEST 256
can now be replaced with
ad_ip_instance axi_dmac axi_ad9136_dma [list \
DMA_TYPE_SRC 0 \
DMA_TYPE_DEST 1 \
DMA_DATA_WIDTH_SRC 64 \
DMA_DATA_WIDTH_DEST 256 \
]
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The loopback on the unused gpio inputs consumes routing resources
while does not gives any value for the software.
Connect these lines to zero instead.
Some projects use the ad_iobuf on IOs that are not bidirectional
producing synthesis warnings.
The change fixes warnings like:
[Synth 8-6104] Input port 'gpio_bd_i' has an internal driver
[Synth 8-6104] Input port 'gpio_status' has an internal driver
- connect unused GPIO inputs to loopback
- connect unconnected inputs to zero
- complete interface for system_wrapper instantiated in all system_top
fixes incomplet portlist WARNING [Synth 8-350]
fixes undriven inputs WARNING [Synth 8-3295]
The change excludes the generated system.v and Xilinx files.
- remove interrupts from system_top
- for all suported carriers:
- remove all interrupt bd pins
- connect to GND all initial unconnected interrupt pins
- update ad_cpu_interrupt procedure to disconnect a interrupt from GND
before connectiong it to another pin.
Just one VCC or GND xlconstant will be generated for each width. This
way we can avoid having a lot of xlconstant instances with the same
configuration.
Some FMC boards do utilize more than one transceiver quad but do not
necessarily use all transceivers in a quad. On such board is the
AD9694-500EBZ. Which uses two transceivers each in two adjacent quads.
This board can not be supported by instantiating a util_adxcvr with only 4
lanes. Since those 4 lanes would be packed into the same quad. Instead it
it is necessary to instantiate a util_adxcvr with 6 lanes. 4 lanes for the
first quad and 2 for the second.
To still to be able to connect such a util_adxcvr to a link layer with only
4 lanes allow to specify sparse lane mappings. A sparse mapping can have
less lanes than the util_adxcvr and some lanes will be left unconnected.
For example for the AD9694-500EBZ the lane mapping looks like the following:
ad_xcvrcon util_ad9694_xcvr axi_ad9694_xcvr ad9694_jesd {0 1 4 5} rx_device_clk
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Sometimes the output clock of the transceiver should not be used for the
device clock.
E.g. for deterministic latency with no uncertainty the device clock needs
to be sourced directly from a clock or transceiver reference clock input
pin.
Add an option to the ad_xcvrcon command to specify the device clock.
In case the same device clock is used for multiple JESD204 links, e.g. a TX
and a RX link only one reset generator is created.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
This change adds the TLAST signal to the AXI streaming interface
of the source side for Intel targets.
Xilinx based designs already have this since the tlast is part of the
interface definition.
In order to make the signal optional and let the tool connect a
default value to the it, the USE_TLAST_SRC/DEST parameter is
added to the configuration UI. This conditions the tlast port on
the interface of the DMAC.
Xilinx handles the optional signals much better so the parameter
is not required there.
There are random timing violations on the A10GX board using the
DAQ3 and DAQ2 projects.
Setting the synthesis/implementation strategy to "HIGH PERFORMANCE
EFFORT" increases the success rate of the timing closure significantly.
In the system top of the FMCOMMS5 projects, there are several GPIO lines, which
can not find in the constraint file, respectively gpio_open_15_15,
gpio_open_44_44 and gpio_45_45.
These are floating GPIO pins, as their names suggest. Delete all these wires and
update IOBUF instances.
AndreiGrozav
Lars-Peter Clausen
Laszlo Nagy
Istvan Csomortani
Adrian Costina