By adding support for partial avalon transfers (data width < bus width),
valid data set size (DMA transfer length) will be dependent on the DMA bus
width only.
+ avl_write_transfer_done_s is a redundant net
+ specify the net state explicitly on if statements
+ to define the edge of avl_mem_fetch_wr_address signal,
its register and its second sync register should be used
The ad_mem_asym memory read interface has a 3 clock cycle delay, from the
moment of the address change until a valid data arrives on the bus;
because the dac_xfer_out is going to validate the outgoing samples (in conjunction
with the DAC VALID, which is free a running signal), this module will compensate
this delay, to prevent duplicated samples in the beginning of the
transaction.
+ all net names should have a *_s postfix
+ avl_burstcount is a constant 1, no need for an additional
register for it
+ all CDC should have two synchronization register, add
avl_last_beat_req_m2
The "'b0" constant will be translate as a 32 bit width vector by
ModelSim, and will throw a buswidth mismatch error. Tie the data_b
bus to zero, using its width parameter.
Currently the scripts use 'analog.com' as the vendor property for IP cores,
but 'ADI' for interfaces.
Make things consistent by using 'analog.com' for both interfaces as well
as IP cores.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Make sure that the XML files are re-build when any of the scripts that are
used to generated it are modified.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
All the rules to generate the XML files are the same. Reduce the number of
rules by useing wildcard matching for the rule target.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Convert the FMCOMMS11 project to the ADI JESD204 link layer cores. The
change is very straight forward, but a matching change on the software side
is required.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Convert the FMCJESDADC1 project to the ADI JESD204 link layer core. The
change is very straight forward, but a matching change on the software side
is required.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Convert the FMCADC4 project to the ADI JESD204 link layer core. The change
is very straight forward, but a matching change on the software side is
required.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Convert the FMCADC2 project to the ADI JESD204 link layer core. The change
is very straight forward, but a matching change on the software side is
required.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Convert the DAQ3 project to the ADI JESD204 link layer cores. The change is
very straight forward, but a matching change on the software side is
required.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Convert the DAQ2 project to the ADI JESD204 link layer cores. The change is
very straight forward, but a matching change on the software side is
required.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Convert the ADRV9371 project to the ADI JESD204 link layer cores. The
change is very straight forward, but a matching change on the software side
is required.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Convert the AD6676EVB project to the ADI JESD204 link layer core. The
change is very straight forward, but a matching change on the software side
is required.
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>
The ADI JESD204 link layer cores are a implementation of the JESD204 link
layer. They are responsible for handling the control signals (like SYNC and
SYSREF) and controlling the link state machine as well as performing
per-lane (de-)scrambling and character replacement.
Architecturally the cores are separated into two components.
1) Protocol processing cores (jesd204_rx, jesd204_tx). These cores take
care of the JESD204 protocol handling. They have configuration and status
ports that allows to configure their behaviour and monitor the current
state. The processing cores run entirely in the lane_rate/40 clock domain.
They have a upstream and a downstream port that accept and generate raw PHY
level data and transport level payload data (which is which depends on the
direction of the core).
2) Configuration interface cores (axi_jesd204_rx, axi_jesd204_tx). The
configuration interface cores provide a register map interface that allow
access to the to the configuration and status interfaces of the processing
cores. The configuration cores are responsible for implementing the clock
domain crossing between the lane_rate/40 and register map clock domain.
These new cores are compatible to all ADI converter products using the
JESD204 interface.
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>
The sync_data module can be used to continuously transfer multi-bit signals
like status signals safely from the source to the destination clock
domain. A transfer takes 2 source and 2 destination clock cycles. It is not
guaranteed that all transitions on the source side will be visible on the
target side if the signal is changing faster than this. Logic using this
block should be aware of it. The primary intention is for it to be used for
slowly changing status signals.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The event synchronizer can be used to safely transfer 1-bit 1-clock cycle
event signals from one clock domain to another.
For each event recorded in the source domain it is guaranteed that a event
will be generated in the target domain at a later point in time. It is
possible though that multiple events in the source domain will be coalesced
into a single event in the target domain if events are generated faster
than they can be transferred.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Move the CDC helper modules to a dedicated helper modules. This makes it
possible to reference them without having to use file paths that go outside
of the referencing project's directory.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Currently the name of the newly created IP core is automatically inferred
from the top-level module. This works fine if there is only one top-level
IP. But for an IP core that is a collection of helper modules this fails.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Currently the polarity of the reset signal is always set to negative.
Change this so that the polarity is selected on the suffix of the name. If
it ends with a 'n' or 'N' the polarity will be negative, otherwise it will
be positive.
This allows this function to be used with reset signals that have positive
polarity.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
This patch adds a helper function that allows to create multiple ports for
a single set of underlying signals. This is useful when the number of ports
is a configuration parameter. It sort of allows the emulation of port
arrays without having to have on set of input/output signals for each port,
instead the signals are shared by all ports.
The following snippet illustrates how this can for example be used to
generate multiple AXI-Streaming ports from a single set of signals.
<verilog>
module #(
parameter NUM_PORTS = 2
) (
input [NUM_PORTS*32-1:0] data,
input [NUM_PORTS-1:0] valid,
output [NUM_PORTS-1:0] ready,
);
...
endmodule
</verilog>
<tcl>
adi_add_multi_bus 8 "data" "slave" \
"xilinx.com:interface:axis_rtl:1.0" \
"xilinx.com:interface:axis:1.0" \
[list \
{ "data" "TDATA" 32} \
{ "valid" "TVALID" 1} \
{ "ready" "TREADY" 1} \
] \
"NUM_PORTS > {i})"
</tcl>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Commit 2f023437b4 ("adi_ip- remove adi_ip_constraints") changed the
default processing order of IP core constraint files from late to normal.
This is problematic because some IP core constraint files try to access
clocks that are that are generated by different files with the normal
processing order level. These clock may or may not be available to the IP
core constraint file depending on the (random) order in which the files
were processed.
To avoid this issue change the default processing order back to late.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The clock monitor reports the ratio of the clock frequencies of a known
reference clock and a monitored unknown clock. The frequency ratio is
reported in a 16.16 fixed-point format.
This means that it is possible to detect clocks that are 65535 times faster
than the reference clock. For a reference clock of 100 MHz that is 6.5 THz
and even if the reference clock is running at only 1 MHz it is still 65
GHz, a clock rate much faster than what we'd ever expect in a FPGA.
Add a configuration option to the clock monitor that allows to reduce the
number of integer bits of ratio. This allows to reduce the utilization
while still being able to cover all realistic clock frequencies.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Currently when the monitored clock stops the clock monitor retains the old
frequency ratio value and there is no way to detect that the clock has
stopped and the reported value is indistinguishable form a clock still
running at the right rate.
If a full iteration as elapsed on the monitoring side and there is no
indication that the counter on the monitored side has started running set
the reported clock ratio value to 0 to indicate that the clock has stopped.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Currently the clock monitor features a hold register in the monitored clock
domain. This old register is used to store a instantaneous copy of the
counter register. The value in the old register is then transferred to the
monitoring domain. Since the counter is continuously counting it is not
possible to directly transfer it since that might result in inconsistent
data.
Instead stop the counter and hold the registers stable for a duration that
is long enough for the monitoring domain to correctly capture the value.
Once the value has been transferred the counter is reset and restarted for
the next iteration.
This allows to eliminate the hold register, which slightly reduces
utilization.
The externally visible behaviour is identical before and after the patch.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Istvan Csomortani
Lars-Peter Clausen
Adrian Costina