Clear the reference checkpoint if the incremental compilation is not
selected through the make option. Other case the scripts will silently
use the reference.dcp checkpoint if that exists.
The scripts are looking for a previous run result, a routed design
checkpoint to use it as a reference during the incremental build flow.
Before clearing the project files, the scrips will save the reference dcp
file in the project folder.
If the reference dcp does not exists the build continues normally.
Proposed workflow:
1. Build your project normally with 'make' or place manually a
reference.dcp file in the Vivado project folder.
2. Do some minor modifications
3. Run the make with the following option:
make MODE=incr
4. Repeat steps 2-3
Using a common IP cache location for all the project will speed up
compile time of common blocks used in base designs. Example a MicroBlaze
core for VCU118 once compiled it will be reused on other projects.
Using a common IP cache will speed up re-compiles of every project in OOC
mode since the cache won't be cleared as with normal compile flow.
Having a clock assigned manually to the clk output pin of the axi_ad9361
let the Vivado timing engine to not ignore the clock insertion delay when
analyzing paths between clk_0 and the manually created clock that has
the same source (clk_0), resulting in timing failure.
In the current form, when connecting a master to the HP ports all
available slave address spaces are mapped to the master (DDR_*, PCIE*, OCM,
QSPI)
Let the PL masters have access only to the DDR_LOW and DDR_HIGH address
spaces to avoid unnecessary resource usage and increase timing margin.
Create the dacfifo/adcfifo infrastructure with procedures.
This will allow moving the parameters of the dac/adcfifo inside
the block design so it can be calculated based on other parameters.
Use the new util_cpack2 and util_upack2 cores. They have lower utilization
that the old util_cpack and util_upack cores.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Use the new util_cpack2 and util_upack2 cores. They have lower utilization
that the old util_cpack and util_upack cores.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Use the new util_cpack2 and util_upack2 cores. They have lower utilization
that the old util_cpack and util_upack cores.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Use the new util_cpack2 and util_upack2 cores. They have lower utilization
that the old util_cpack and util_upack cores.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Use the new util_cpack2 and util_upack2 cores. They have lower utilization
that the old util_cpack and util_upack cores.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Use the new util_cpack2 and util_upack2 cores. They have lower utilization
that the old util_cpack and util_upack cores.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Use the new util_cpack2 and util_upack2 cores. They have lower utilization
that the old util_cpack and util_upack cores.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Use the new util_cpack2 and util_upack2 cores. They have lower utilization
that the old util_cpack and util_upack cores.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Use the new util_cpack2 and util_upack2 cores. They have lower utilization
that the old util_cpack and util_upack cores.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Use the new util_cpack2 and util_upack2 cores. They have lower utilization
that the old util_cpack and util_upack cores.
Signed-off-by: Matt Fornero <matt.fornero@mathworks.com>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Use the new util_cpack2 and util_upack2 cores. They have lower utilization
that the old util_cpack and util_upack cores.
Signed-off-by: Matt Fornero <matt.fornero@mathworks.com>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Use the new util_cpack2 and util_upack2 cores. They have lower utilization
that the old util_cpack and util_upack cores.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Use the new util_cpack2 and util_upack2 cores. They have lower utilization
that the old util_cpack and util_upack cores.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Use the new util_cpack2 and util_upack2 cores. They have lower utilization
that the old util_cpack and util_upack cores.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
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>
- 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
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.
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.
Moved XCVR related connections to HP0, where the HP shares the MUX with the Video DMA
HP1 and HP2 are used for RX OS and RX DMAs, sharing the MUX. Usually they shouldn't run at the same time.
HP3 is used for TX DMA, sharing the MUX with the FPD DMA controller
All HPx and DMA buswidths have been increased to 128 bits
The HPx-DMA clock has been increased to 300 MHz
DAC FIFO address size has been increased to 17
In DUAL mode half of the data ports are unused and the unused inputs need
to be connected to dummy signals.
Completely hide the unused ports in DUAL mode to remove that requirement.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Connect the DAC data underflow pin (fifo_rd_underflow) of the DMA
to the dunf pin of the device core. This way the software can detect
underflows in the DAC data path.
Connect the DAC data underflow pin (fifo_rd_underflow) of the DMA
to the dunf pin of the device core. This way the software can detect
underflows in the DAC data path.
Connect the DAC data underflow pin (fifo_rd_underflow) of the DMA
to the dunf pin of the device core. This way the software can detect
underflows in the DAC data path.
Laszlo Nagy
Adrian Costina
AndreiGrozav
Lars-Peter Clausen
Matt Fornero
Istvan Csomortani