The SYNC signal that gets reported through the status interface should be
the output (second stage) of the synchronizer circuit.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Make sure the core_cfg_transfer_en signal is declared before they are used.
Strictly speaking the current code is correct and synthesis correctly, but
declaring the signals make the intentions of the code more explicit.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Be more standard compliant and assign names to generate for-blocks. This is
required for Altera/Intel support.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Make sure the req_gen_valid and req_gen_ready signals are declared before
they are used. Strictly speaking the current code is correct and synthesis
correctly, but declaring the signals make the intentions of the code more
explicit.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
In some cases, the 'core_ilas_config_data' registers will be infered as
FDRE, instead of FDSE. Therefor a max delay definition, which are using
the S pin as its endpoint, it can become invalid, nonexistent.
Generalize the path, using the register itself as endpoint.
Increase the width of wvalid_counter, should be equal with awlen width.
The wvalid_counter needs to count from zero to the required burst
length. The maximum burst length is 255, so the width of the counter
have to be 8 bits. axi_last_beats will get the last axi burst length.
The fifo will ask for a new data from the DDR, if the current
level is lower than the high threshold. This will prevent overflow.
By deleting the lower threshold, we can avoid ocassional underflows,
when the DAC rate is closer to the max DDRx rate.
All verilog file are using the Verilog-2001 standard to define
and/or declare ports. Definin a port width with a local parameter
is a bad practive, when this standard is used. Some simulators
will crash. Try to avoid it.
Fix the dma_ready mux in top module, and the dma_ready_out reset
logic in axi_dacfifo_wr module. Also, both write and read addresses
of the async CDC fifo (inside the axi_dacfifo_wr) should be reset
before a dma transaction starts.
If the streaming bit is set, after the trigger condition is met
data will be continuosly captured by the DMA. The streaming bit
must be set to 0 to reset triggering.
If the streaming bit is set, after the trigger condition is met,
data will be continuosly captured by the DMA. The streaming bit
must be set to 0 to reset triggering.
In non-streaming mode we want direction changes to be applied immediately.
The current code has a typo and checks the wrong signal. overwrite_data
holds the configured output value of the pin, whereas overwrite_enable
configures whether the pin is in streaming or manual mode.
For correct operation the later signal should be used to decide whether a
direction change should be applied. Otherwise the direction change will
only be applied if the output value of the pin is set to logic high.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
When using non-broadcast access to the GT DRP registers lane filtering is
done on both sides. The ready and data signals are filtered in the in the
axi_adxcvr module and the enable signal is filtered in the util_adxcvr
module. This works fine as long as both sides use the same transceiver IDs.
E.g. channel 0 of the axi_adxcvr module is connected to channel 0 of the
util_adxcvr module.
But this is not always the case. E.g. on the ADRV9371 platform there are
two RX axi_adxcvr modules (RX and RX_OS) connected to the same util_adxcvr.
The first axi_adxcvr uses lane 0 and 1 of the util_adxcvr, the second uses
lane 2 and 3.
Non-broadcast access for the first RX axi_adxcvr module works fine, but
always generates a timeout for the second axi_adxcvr module. This is
because lane 0/1 of the axi_adxcvr module is connected to lane 2/3 of the
util_adxcvr and when ID based filtering is done both can't match at the
same time.
To avoid this perform the filtering for all the signals in the axi_adxcvr
module. This makes sure that the same base ID is used.
This also removes the sel signal from the transceiver interfaces since it
is no longer used on the util_adxcvr side.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Always explicitly specify the signal width for constants to avoid warnings
about signal width mismatch.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The buffer delay should be 0 in the default configuration. The current
value of 0xb must have slipped in by accident.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Use a single standalone counter that counts the number of beats since the
release of the SYNC~ signal, rather than re-using the LMFC counter plus a
dedicated multi-frame counter.
This is slightly simpler in terms of logic and also easier for software to
interpret the data.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
There are currently two sysref related events. One the sysref captured
event which is generated when an external sysref edge has been observed.
The other is the sysref alignment error event which is generated when a
sysref edge is observed that has a different alignment from previously
observed sysref edges.
Capture those events in the register map. This is useful for error
diagnostic. The events are sticky and write-1-to-clear.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The internal LMFC offset signals are in beats, whereas the register map is
in octets. Add the proper alignment padding to the register map to
translate between the two.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
For SYSREF handling there are now three possible modes.
1) Disabled. In this mode the LMFC is generated internally and all external
SYSREF edges are ignored. This mode should be used for subclass 0 when no
external sysref is available.
2) Continuous SYSREF. An external SYSREF signal is required and the LMFC is
aligned to the SYSREF signal. The SYSREF signal is continuously monitored
and if a edge unaligned to the previous edges is detected the LMFC is
re-aligned to the new edge.
3) Oneshot SYSREF. Oneshot SYSREF mode is similar to continuous SYSREF mode
except only the first edge is captured and all further edges are ignored,
re-alignment will not happen.
Both in continuous and oneshot signal at least one external sysref edge is
required before an LMFC is generated. All events that require an LMFC will
be delayed until a SYSREF edge has been captured. This is done to avoid
accidental re-alignment.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
If the output pin is not defined as a clock, some of the Vivado IPI
propagation TCL will error out.
Signed-off-by: Matt Fornero <matt.fornero@mathworks.com>
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>
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>
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>
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>
Sort the entries in the library Makefile alphabetical. Keeping it ordered
makes it easier to track changes compared to randomly reshuffling it
every time a new entry is added.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
All the hdl (verilog and vhdl) source files were updated. If a file did not
have any license, it was added into it. Files, which were generated by
a tool (like Matlab) or were took over from other source (like opencores.org),
were unchanged.
New license looks as follows:
Copyright 2014 - 2017 (c) Analog Devices, Inc. All rights reserved.
Each core or library found in this collection may have its own licensing terms.
The user should keep this in in mind while exploring these cores.
Redistribution and use in source and binary forms,
with or without modification of this file, are permitted under the terms of either
(at the option of the user):
1. The GNU General Public License version 2 as published by the
Free Software Foundation, which can be found in the top level directory, or at:
https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html
OR
2. An ADI specific BSD license as noted in the top level directory, or on-line at:
https://github.com/analogdevicesinc/hdl/blob/dev/LICENSE