The ad_pps_receiver is instantiated at the top of core.
The rcounter is placed into adc/dac_common registers space, at the
address 0x30 (word aligned).
The interrupt mask is placed into adc/dac_common, at the address 0x04
(word aligned). Because the core has an instance of both modules, the
interrupt masks are OR-ed together.
Add a module to receive 1PPS signal from a GPS module. The module has a
free running counter, which runs on the device's interface clock. The
counter value is latched into a register each time when a 1PPS arrives.
An interrupt signal is also generated in every 1PPS.
Add a check to RX register map to confirm that the ILAS memory registers
return the correct values after the ILAS data has been received.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The MSB of the d_count signal is used as a overflow marker to stop the
counter from incrementing in the monitored clock domain. It is not exported
through the register map and truncated when assigned to the up_d_count
signal.
Make the truncation explicit to make it clear that this is not a mistake
and to avoid warnings about implicit truncation.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The generic Altera clock monitor constraints expect the instance to be
called i_clock_mon. Adjust the code accordingly.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
In this particular case the behaviour is the same with non-blocking and
blocking assignments, but that could change if the code is modified in the
future. To avoid any potentially issue due to this consistently use
non-blocking assignments.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The axi_dmac can issue up to FIFO_SIZE read and write requests in parallel.
This is done in order to maximize throughput and compensate for for
latency.
Set the {read,write}IssuingCapability properties accordingly on the AXI
master interfaces. Otherwise qsys might decide to insert bridges that
artificially limit the number of requests, which in turn might affect
performance.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Qsys allows to query to query the clock domain that is associated with a
clock input of a peripheral. This allows to automatically detect whether
the different clocks of the DMAC are asynchronous and CDC logic needs to be
inserted or not.
Auto-detection has the advantages that the configuration parameters don't
need to be set manually and the optional configuration will be choose
automatically. There is also less chance of error of leaving the settings
in a wrong configuration when e.g. the clock domains change.
In case the auto-detection should ever fail configuration options that
provide a manual overwrite are added as well.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Group configuration parameters by function, provide human readable labels
as well as specify the allowed ranges for each parameter.
This prevents accidental misconfiguration and also makes it easier to
inspect (or change) the configuration in the Qsys GUI.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
In this particular case the behaviour is the same with non-blocking and
blocking assignments, but that could change if the code is modified in the
future. To avoid any potentially issue due to this consistently use
non-blocking assignments.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Use the ad_ip_intf_s_axi helper function to create the axi4lite slave
interface for memory mapped peripherals. This slightly reduces the amount
of boilerplate code in the peripheral's *hw.tcl
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The address width of the AXI interface depends on the size of the register
and can differ from peripheral to peripheral. Add a parameter to the
function that allows to specify the address width, this allows to use the
function for more peripherals.
Keep the current value of 16 bits as the default if the parameter is not
specified.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The axi_adxcvr register map only uses a single 4k page, make this explicit.
This will allow for tighter packaging in the limited available total
register map space.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
This partially reverts commit a8ade15173.
Remove the nonsensical Makefile dependencies that got added by accident.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The MSB of the d_count signal is used as a overflow marker to stop the
counter from incrementing in the monitored clock domain. It is not exported
through the register map and truncated when assigned to the up_d_count
signal.
Make the truncation explicit to make it clear that this is not a mistake
and to avoid warnings about implicit truncation.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The generic Altera clock monitor constraints expect the instance to be
called i_clock_mon. Adjust the code accordingly.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
In this particular case the behaviour is the same with non-blocking and
blocking assignments, but that could change if the code is modified in the
future. To avoid any potentially issue due to this consistently use
non-blocking assignments.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The axi_dmac can issue up to FIFO_SIZE read and write requests in parallel.
This is done in order to maximize throughput and compensate for for
latency.
Set the {read,write}IssuingCapability properties accordingly on the AXI
master interfaces. Otherwise qsys might decide to insert bridges that
artificially limit the number of requests, which in turn might affect
performance.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
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
There are devices which have a asynchronous data ready signal. (asynchronous
with the spi clock) The CDC stages can be enabled by setting up
the ASYNC_TRIG parameter.
In case of high precision devices with just a simple SPI interface
for control and data, the effective data rate can be significatly
lower than the SPI clock, and more importantly there isn't any relation
between the two clock domain.
The rate is defined by a SOT (start of transfer) generator, which
initiates a SPI transfer. Taking the fact that the generator runs
on system clock (100 MHz), and the device can require smaller rate (in kHz domain),
the 7 bit dac_datarate register is just too small.
Therefor increasing to 16 bit.
This core can be used in conjunction with the SPI_ENGINE, will work
as an offload module, forwarding a data stream to the SPI excecution,
received from a DMA.
Calculate the output clock frequencies based on the input clock frequencies
and the default divider settings and configure the output clock pins
accordingly. This allows connected peripherals to infer the frequency of
the clock.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Instead of having to manually specify the input clock period infer the
values from the block design. This means that less configuration parameters
need to be changed if the clock input frequency changes.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Add interface definition for the input and output clocks. This will allow
the tools to recognize them as clocks and enable things like clock
frequency propagation.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The secondary clock inputs and outputs of the axi_clkgen are rarely used.
Add enable parameters that need to be explicitly set before they are
available. This allows to hide the secondary clock pins when they are not
used in the block design.
There are currently no projects which use the secondary clock inputs or
outputs so there is no need to set these new parameters anywhere.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Vivado infers the type of floating point type parameters as integer if the
value can be expressed as an integer (i.e. decimal places are 0). To
correctly infer them as floating point parameters add types to the
parameter declaration.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Istvan Csomortani
Adrian Costina
Lars-Peter Clausen
Rejeesh Kutty
Matthew Fornero
AndreiGrozav