- allow specifying the name of Axi Lite interface from the peripheral were to connect the control bus
- some DDR controllers have an Axi Lite control interface, this creates
a second address segment which causes issues, differentiate the memory
segment from control registers segment
The goal of this commit is to make sure there isn't any significance to
the order in which parameters of ad_connect are specified.
As an example, previously you could only `ad_connect target VCC`, while
`ad_connect VCC target` would fail.
Note: This code intentionally ignores bd_{,intf_}ports, because
these can all be treated as bd_pins.
Signed-off-by: David Winter <david.winter@analog.com>
This will allow building base test harnesses and place on top of them
existing block designs for simulation purposes.
Test harnesses will contain basic functionality like
- clock and reset generators
- AXI master to aid register access of the cores.
- memory model of the DDR
- interrupt controller
Existing procedures (ad_mem_hp0_interconnect, ad_cpu_interconnect, ... ) will
connect to this harness as they do to a real base design.
To support deterministic latency with non-power of two octets per frame
(F=3,6) the interface width towards the transport layer must be resized
to match integer multiple of frames.
e.g Input datapath width = 4; Output datpath width = 6;
for F=3 one beat contains 2 frames
for F=6 one beat contains 1 frame
The width change is realized with a gearbox.
Due the interface width change the single clock domain core is split
in two clock domains.
- Link clock : lane rate / 40 for input datapath width of 4 octets 8b10b
- lane rate / 20 for input datapath width of 8 octets 8b10b
- lane rate / 66 for input datapath width of 8 octets 64b66b
- Device clock : Link clock * input data path width / output datapath width
Interface to transport layer and SYSREF handling is moved to device clock domain.
The configuration interface reflects the dual clock domain.
If Input and Output datapath width matches, the gearbox is no longer
required, a single clock can be connected to both clocks.
When channels are not swapped in groups of four but are completely out of order
the common control channel can't be reordered based on the index of the
channel.
For all the Xilinx base design, define three global clock nets, which
are saved in the following three global variable: $sys_cpu_clk, $sys_dma_clk
and $sys_iodelay_clk.
These clock nets are connected to different clock sources depending of
the FPGA architecture used on the carrier. In general the following
frequencies are used:
- sys_cpu_clk - 100MHz
- sys_dma_clk - 200MHz or 250Mhz
- sys_iodelay_clk - 200MHz or 500Mhz
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.
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>
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>
- 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>
Add a parameter to the ad_xcvrcon function that allows to provide a mapping
between logical and physical lanes. By default if no lane map is provided
the logial and physical lanes are mapped 1-to-1. If a lane map is provided
logical lane $n is mapped onto physical lane $lane_map[$n].
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Let the ad_xcvrcon handle the ADI JESD204 link layer cores. The function
will detect the JESD204 core vendor and connect the appropriate signals
based on it. This means it can still be used with the Xilinx JESD204 core
as well.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
When trying to use ad_cpu_interconnect to connect to a AXI interface that
is a outer port of a hierarchy this will fail at the moment as it kind find
the matching clock and reset signals.
Add support for traversing into the hierarchy and find the final target AXI
port inside the hierarchy. Then find the matching clock and reset and
traverse them back the corresponding hierarchy outer ports.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
In case of axi_interconnects, when just one slave and master interface is
active, the 'Interconnect Optimization Strategy' is disabled. So this
parameter should be set just if there is more than one slave interface.
Morten Jensen
Filip Gherman
Laszlo Nagy
David Winter
sergiu arpadi
Adrian Costina
AndreiGrozav
Istvan Csomortani
Lars-Peter Clausen
Rejeesh Kutty