Teledyne SP Devices ADQ3 Series User manual

ADQ3 Series FWDAQ
Development Kit
User Guide
Author(s): Teledyne SP Devices
Document ID: 20-2507
Classification: Public
Revision: B
Print date: 2022-03-31

Classification Revision
Public B
Document ID Print date
20-2507 2022-03-31
Contents
1 Introduction 4
1.1 Definitions and Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Prerequisites 5
3 Development Environment and Tools 6
3.1 Unpacking the Development Kit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2 OpeningtheDevelopmentKit.................................. 7
3.3 SettingUptheProject ...................................... 7
3.3.1 Configuration....................................... 7
3.4 BuildingtheDesign........................................ 8
3.5 WorkingwiththeDesign..................................... 8
3.5.1 TypicalDesignFlow ................................... 8
3.6 Analyzing the Implemented Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4 General Concepts 13
4.1 ParallelDigitalDesign ...................................... 13
4.2 DataFlow............................................. 13
4.3 Clock Domain Crossing Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3.1 CDC Synchronization of a 1-bit Signal . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3.2 CDC Synchronization of a Multi-Bit Signal . . . . . . . . . . . . . . . . . . . . . . . 17
4.4 AXIControlBus ......................................... 18
4.4.1 ControlBusSignals ................................... 18
4.5 DataBus ............................................. 18
4.5.1 TwoBusDefinitions ................................... 18
5 Data Bus Signals 20
5.1 Timestamp ............................................ 21
5.2 TimestampSynchronization................................... 21
5.2.1 SampleIndex....................................... 21
5.2.2 Count ........................................... 21
5.2.3 Event ........................................... 22
5.3 Trigger............................................... 22
5.3.1 SampleIndex....................................... 22
5.3.2 SampleIndexFraction.................................. 22
5.3.3 Rising........................................... 22
5.3.4 Event ........................................... 22
5.3.5 Inhibit ........................................... 22
5.4 Overrange............................................. 23
5.5 GeneralPurpose......................................... 23
5.6 SampleData ........................................... 23
5.7 Valid................................................ 23
5.8 Record .............................................. 23
ADQ3 Series FWDAQ Development Kit spdevices.com Page 1 of 38

Classification Revision
Public B
Document ID Print date
20-2507 2022-03-31
5.8.1 Start, Start Index, Stop and Stop Index . . . . . . . . . . . . . . . . . . . . . . . . 23
5.8.2 Number.......................................... 25
5.9 UserID .............................................. 25
5.10 Differences relative to ADQ14, ADQ7 and ADQ8 . . . . . . . . . . . . . . . . . . . . . . . 25
6 User Logic 1 26
6.1 DefaultContents ......................................... 26
6.2 RegisterFile ........................................... 26
6.3 DefaultRegisterFile....................................... 27
7 User Logic 2 29
7.1 DefaultContents ......................................... 29
7.2 RegisterFile ........................................... 30
7.3 DefaultRegisterFile....................................... 30
7.4 PortControl............................................ 33
7.4.1 PortImpedance ..................................... 33
7.4.2 ADQ32-PCIe,ADQ33-PCIe............................... 33
7.4.3 ADQ36-PXIe ....................................... 34
8 Timing Closure 35
9 Troubleshooting 36
9.1 DebuggingonHardware..................................... 36
9.1.1 CreatingtheDebugCore ................................ 36
9.1.2 Connecting to the Debug Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
ADQ3 Series FWDAQ Development Kit spdevices.com Page 2 of 38

Classification Revision
Public B
Document ID Print date
20-2507 2022-03-31
Document History
Revision Date Section Description Author
B 2022-03-31 - Updated for ADQ36-PXIe release TSPD
2021-11-16 7.4 Add section on user logic 2 port control TSPD
A 2021-06-21 - Initial revision TSPD
ADQ3 Series FWDAQ Development Kit spdevices.com Page 3 of 38

Classification Revision
Public B
Document ID Print date
20-2507 2022-03-31
1 Introduction
This document is the user guide for the development kit of the data acquisition firmware for ADQ3 series
digitizers. There are different versions of the development kit depending on the device-to-host interface
and the target number of channels. Make sure the development kit matches the target hardware.
The development kit centers around the user logic areas. These areas target strategic points in the
data path and are specifically intended to contain custom HDL designs.
The first user logic area, UL1, described in Section 6, operates on the full-rate data stream—before
the trigger information has been decoded to create records. The second user logic area, UL2, described
in Section 7, operates on complete records, potentially with a reduced sampling rate.
1.1 Definitions and Abbreviations
Table 1lists the definitions and abbreviations used in this document.
Table 1: Definitions and abbreviations used in this document.
Item Description
ADC Analog-to-digital converter
CDC Clock domain synchronization
Devkit Development kit
DBT1 Data bus type 1
DBT2 Data bus type 2
FWDAQ The data acquisition firmware
GiB Gibibyte (10243bytes)
PCB Printed circuit board
RTL Register transfer level
Tcl Tool command language—scripting language used in Vivado.
UL1 User logic 1—the first open FPGA area, see Section 6.
UL2 User logic 2—the second open FPGA area, see Section 7.
VHDL VHSIC hardware description language
Verilog Hardware description language
Vivado Xilinx FPGA design suite
ADQ3 Series FWDAQ Development Kit spdevices.com Page 4 of 38

Classification Revision
Public B
Document ID Print date
20-2507 2022-03-31
2 Prerequisites
The development kit has the following prerequisites:
•A license for the development kit purchased from Teledyne SP Devices.
•A license for the Xilinx design tools. For current versions of the development kit, a license for
Vivado 2020.2 is required.
–Minimum tooling is the Vivado Design Edition.
–The Vivado WebPack does not support this development kit.
–Xilinx ISE cannot be used.
•Previous experience with defining custom logic using Verilog or VHDL.
ADQ3 Series FWDAQ Development Kit spdevices.com Page 5 of 38

Classification Revision
Public B
Document ID Print date
20-2507 2022-03-31
3 Development Environment and Tools
This section describes the development kit workflow and the associated tools.
3.1 Unpacking the Development Kit
The development kit is delivered as a .zip archive containing the project files, source files and doc-
umentation. The first level of the archive contains a README file and another archive that is password
protected. By unpacking the password protected archive, the user agrees to the terms of the develop-
ment kit license. Make sure to extract the archive to a directory where the current user has read and
write permissions.
Important
By unpacking the password protected archive, the user agrees to the terms of the development kit
license.
The extracted archive is organized as follows:
<Extract root>/
constraints/ Contains the constraint files for the design.
documentation/ Contains the documentation for the development kit.
framework/ Contains the files representing the base design along with header files
to interact with the data bus. Apart from the file config.vh (see Sec-
tion 3.3.1, the files in this directory should not be modified by the user.
user_logic/ Contains the Verilog source files for the user logic areas.
license.txt Development kit license file.
devkit.tcl The Tcl file that is sourced to enable the development kit.
Note
Apart from the file config.vh (see Section 3.3.1, the files in the framework directory are not intended
to be edited by the end user.
ADQ3 Series FWDAQ Development Kit spdevices.com Page 6 of 38

Classification Revision
Public B
Document ID Print date
20-2507 2022-03-31
3.2 Opening the Development Kit
To open the development kit in Vivado, follow the steps outlined below.
1. Start Vivado
2. In the menu bar, select Tools > Run Tcl Script...
3. Open the file <Extract root>/devkit.tcl. The Tcl console will output message similar to this:
*** ADQ3 Series Development Kit ***
Revision: r59529
Usage:
devkit_setup - Create project
devkit_build - Build project
devkit_analyze - Analyze implemented design
devkit_mcs - Generate .mcs firmware file.
(Not needed if devkit_build is used.)
At this point, the Tcl commands specific to the development kit have been defined and are available in
the Tcl console. The project is now ready to be set up for first-time use.
Note
The development kit for ADQ3 series digitizers works differently compared to previous products since
building the user logic areas no longer requires special Tcl commands. See Section 3.5 for details.
3.3 Setting Up the Project
To set up the development kit, execute the command
devkit_setup
in the Tcl console. The process may take a moment to finish. Once the setup is complete, a Vivado
project has been created and the design is ready to be built. This step only has to be completed once,
after which the following directories will have been created:
<Extract root>/
artifacts/
latest/ Contains firmware files from the most recent build.
log/ Contains firmware files from previous builds.
build/ Contains all generated project files.
reports/ Contains the results from the development kit analyzer tool (see Section 3.6).
3.3.1 Configuration
The file framework/config.vh contains parameters that influence the base design. Some parameters
should not be changed by the user—these are clearly marked. Other parameters may be modified and
ADQ3 Series FWDAQ Development Kit spdevices.com Page 7 of 38

Classification Revision
Public B
Document ID Print date
20-2507 2022-03-31
serve as a way to remove modules in the base design to free up FPGA resources, provided that the
application does not require the features they provide. For example, the parameter REMOVE_FILTER
removes the built-in FIR filter if set to a nonzero value. This frees up DSP and routing resources in the
FPGA fabric.
3.4 Building the Design
To build the entire design, execute the command
devkit_build
in the Tcl console. Depending on the computer specifications and the complexity of the design as a whole,
i.e. the precomplied design and the user logic together, this may take several hours. Once the process
is complete, an .mcs file has been generated in the artifacts/latest/ directory. This file represents
a new firmware for the digitizer and may be uploaded using the ADQUpdater application. Refer to the
ADQUpdater user guide [1] for instructions on how to manage the digitizer’s firmware.
3.5 Working with the Design
This section describes the workflow of adding customized logic functions to the digitizer firmware.
3.5.1 Typical Design Flow
This section outlines the typical design flow for the development kit.
1. Set up the development kit project as described in Section 3.3.
2. Modify or insert new Verilog code into user_logic1.v or user_logic2.v. This operation can be
broken down into four steps:
(a) Extract data,data valid and other relevant bus signals using the bus extraction macros (see
Section 5).
(b) Process the extracted signals, i.e. stimulate the custom user design.
(c) Insert the processed data, data valid and relevant bus signals using the bus insertion macros
(see Section 5).
(d) Set the correct value for the BUS_PIPELINE delay parameter to keep the correct time relation
between signals that were not manually inserted.
3. Generate the FPGA configuration file (.mcs file) by using one of the two methods outlined below:
•Automatic
(a) Execute the command
devkit_build
in the Tcl console.
•Manual
ADQ3 Series FWDAQ Development Kit spdevices.com Page 8 of 38

Classification Revision
Public B
Document ID Print date
20-2507 2022-03-31
(a) Start the build by selecting Generate Bitstream in Vivado. This action will rebuild the
design and end with the bitstream generation.
(b) Once the bitstream is available, generate the FPGA configuration file by executing the
command
devkit_mcs
in the Tcl console. The configuration (.mcs) file can be found in the artifacts/latest/
directory after the process is complete.
4. Analyze the design for potential problems by executing the command
devkit_analyze
in the Tcl console and then open the HTML report in the reports/ folder. See Section 3.6 for
details.
5. Program the configuration file representing the custom design into the digitizer using the ADQUp-
dater application. Refer to the corresponding user guide [1] for details on the programming process.
6. Test the custom firmware using either
•one of the software examples available in the ADQAPI library or
•a custom user application.
3.6 Analyzing the Implemented Design
When the implementation step has completed it is highly recommended to analyze the design to detect
the most common issues. To do this, execute the command
devkit_analyze
in the Tcl console. This will run a set of checks and summarize the results into a report. The generated
report includes the current results and the difference with respect to the previous report. To keep track of
design parameter trends, it is encouraged to generate the report after every run even if no timing errors
occurred. The report is saved as an HTML file that should be opened in a web browser, see Fig. 1. There
are also several log files produced and placed in the reports/ folder that offers additional details on the
reported issues.
Tip
If a continuous integration tool is used to automate the workflow, consider integrating the output from
devkit_analyze as a part of the process.
The report is divided into six different sections. Each section has several parameters and result values.
For parameters with a maximum value the format is
Percentage[Value/Maximum value] (Difference)
ADQ3 Series FWDAQ Development Kit spdevices.com Page 9 of 38

Classification Revision
Public B
Document ID Print date
20-2507 2022-03-31
Figure 1: The HTML report from devkit_analyze rendered in a web browser.
and values without an upper boundary are formatted as
Value (Difference)
The difference is calculated by subtracting the value from the previous report from the current value.
Each parameter also has a trend graph that provides a quick overview of the result. Fig. 2shows a
section from the report. A value displayed in red indicates an error that must be addressed. Warnings
that may require investigation are shown in orange.
Figure 2: Excerpt of the utilization section from the devkit_analyze report.
The report contains the following sections:
Critical warnings
These warnings must be fixed, or at least, well understood.
CDC Critical
Check the reports/post_impl.rpt for details.
Synth Critical
Check the reports/synth_runme.log for details.
ADQ3 Series FWDAQ Development Kit spdevices.com Page 10 of 38

Classification Revision
Public B
Document ID Print date
20-2507 2022-03-31
Impl Critical
Check the reports/impl_runme.log for details.
No Clock Critical
Check the reports/post_impl_no_clock.rpt for missing clock constraints.
Warnings
These warnings may cause problems and require investigation. Check the corresponding report
file listed in the section for critical warnings for additional details.
Utilization
The total utilization of available instances of LUT, flip-flop (register), block RAM and DSP. This
includes both the framework and user logic designs.
Timing
The importance of timing closure should be well known when working with an HDL designs. Any
failing timing requirements must be fixed before uploading the firmware to the digitizer to avoid
unexpected behavior.
Key values
These parameters are indicators that should be observed to avoid unwanted and/or unexpected
results.
Congestion
Congestion is a measure of shortage of routing resources. A value of 5 or greater indicates
shortage and will lead to significant problems with fulfilling the timing constraints. Please
refer to UltraFast Design Methodology [2] for resolutions.
Maximum fanout
Fanout is the number of nodes driven by a register. The reported number is the maximum
fanout in the design. Fanout are in most cases not a problem since Vivado automatically
replicates registers with high fanout.
Note
Use of KEEP,KEEP_HIERARCHY,DONT_TOUCH,MARK_DEBUG or ASYNC_REG properties will
prevent the replication of registers.
Control sets
A control signal is a signal to the set/reset and clock enable pin on a register. Registers
that share a common control signal constitute a control set. The report provides the per-
centage of the recommended acceptable value given as a guideline in UltraFast Design
Methodology [2]. Excessive usage may lead to difficulty in reaching the timing goals.
Route CPU time
Route CPU time is the process time used during route.
ADQ3 Series FWDAQ Development Kit spdevices.com Page 11 of 38

Classification Revision
Public B
Document ID Print date
20-2507 2022-03-31
Place CPU time
Place CPU time is the process time used during place.
Note
An unexpected increase in the of place and/or route build time may indicate a potential
problem in the design that may require intervention.
Excessive logic level
This report checks that the number of combinatorial instances between clocked primitives (regis-
ters in most cases) are reasonable with respect to the clock frequency. It is highly recommended
to add pipelining to logic that is reported as “excessive” to avoid problems in timing closure. The
following critical clocks are checked.
pcie_axi_aclk
AXI control bus clock. Check reports/exlogic_pcie_axi_aclk.rpt for details.
clk_datapath
Data path clock. Check reports/exlogic_clk_datapath.rpt for details.
data_clk_2x
Framework trigger logic clock. Check reports/exlogic_data_clk_2x.rpt for details.
c0_dram_app_clk
Framework DRAM logic clock. Check reports/exlogic_c0_dram_app_clk.rpt for de-
tails.
c1_dram_app_clk
Framework DRAM logic clock. Check reports/exlogic_c1_dram_app_clk.rpt for de-
tails.
Note
Under normal circumstances, the internal clocks should not report any excessive logic
levels. However, due to Vivado’s optimization efforts, there may be reports if significant
timing issues are introduced in the user logic. If the user logic is well timed and excessive
logic levels are still reported, please contact TSPD support.
ADQ3 Series FWDAQ Development Kit spdevices.com Page 12 of 38

Classification Revision
Public B
Document ID Print date
20-2507 2022-03-31
4 General Concepts
This section introduces concepts surrounding the development kit based on FWDAQ for ADQ3 series
digitizers. Please refer to the ADQ3 Series FWDAQ User Guide [3] for the base knowledge on how the
digitizer operates. The reader is assumed to be familiar with digital design in general and this section
only serves to highlight some important aspects of digital design with respect to the development kit.
4.1 Parallel Digital Design
More often than not, the FPGA cannot be clocked at the same rate as the incoming data. To handle this
scenario, the logic needs to be implemented to handle several data words per clock cycle, i.e. several
data words in parallel. Parallel design is more challenging than its counterpart, where one data word is
processed per clock cycle. Instructing the reader on parallel design is outside the scope of this document
but moving forward, some familiarity with the concept is expected.
4.2 Data Flow
This section provides a brief description of each block in the data path. Fig. 3shows an overview of
the data path of FWDAQ for the ADQ3 series digitizers. The data propagates between the modules in
the data path using a bus interface with custom insertion and extraction macros for convenience (see
Section 5). Additionally, each module can be accessed from the AXI control bus. These two buses do
not exist in the same clock domain, meaning any signals transferred from one domain to the other must
be synchronized to the receiving clock. Refer to Sections 4.3 and 4.4 for additional details.
Important
Any signals transferred from the control bus clock domain to the data bus clock domain or vice versa
must be synchronized to the receiving clock.
Trigger control
This module is tasked with inserting events on the data bus. The data bus has a single bit indicating
the event itself and bits with additional information such as the position of the event within the
parallel data words (samples).
Gain and offset
The digital gain and offset module is primarily intended for factory calibration but it may also be
accessed by the user, and offers a way of scaling the signal.
Test pattern
This module may be configured to substitute the ADC samples with a synthetically generated
pattern.
DBS
The digital baseline stabilizer, DBS, is designed for pulse signal measurement where high accu-
racy relative to a known baseline is required. Note that DBS is not enabled by default.
ADQ3 Series FWDAQ Development Kit spdevices.com Page 13 of 38

Classification Revision
Public B
Document ID Print date
20-2507 2022-03-31
Figure 3: A block diagram of the data path of FWDAQ. The two user logic areas are highlighted in green.
ADQ3 Series FWDAQ Development Kit spdevices.com Page 14 of 38

Classification Revision
Public B
Document ID Print date
20-2507 2022-03-31
User logic 1
This user logic area is intended to be used to process the incoming samples before any data
reduction has been applied. Refer to Section 6for a more detailed description of the module.
FIR filter
The base design contains a FIR filter module able to subject the data from each channel to a
digital filter function. The FPGA resources used by this module can be reclaimed by the user.
See Section 3.3.1 for more information.
Sample skip
The sampling rate can be reduced by the sample skip module. For example, setting the sample
skip factor to 4 means that every fourth sample is kept and the others are discarded.
Level trigger
This module is used to insert events on the data bus based on the signal level within the data bus
channels.
Acquisition
The acquisition module is tasked with framing the channels on the data bus into records based
on a trigger event. The starting point and stopping point of the record is marked by a logic-high
pulse on the record start and record stop data bus signals, respectively.
Barrel shifter
This module rearranges the parallel samples on the bus so that the first entry is the first sample
in the record.
User logic 2
This user logic area is intended for processing data after the record framing and any data reduction
has occurred. Refer to Section 7for a more detailed description of the module.
Peer-to-peer packer
The peer-to-peer packer is tasked with converting the information on the data bus into packets
that is suitable for the intended endpoint and application.
DRAM FIFO
Before the packets are dispatched to their endpoint, they pass through the on-board DRAM. This
allows the digitizer to buffer packets in the event of a temporary stall on the physical interface or
a short period where the acquisition rate is higher than the readout rate.
DMA
The DMA engine transports packets from the DRAM to a receiving endpoint.
4.3 Clock Domain Crossing Synchronization
A clock domain crossing, CDC, is a boundary where digital signals pass from one clock domain to another.
This boundary constitutes a critical point in the design and care must be taken to synchronize signals
ADQ3 Series FWDAQ Development Kit spdevices.com Page 15 of 38

Classification Revision
Public B
Document ID Print date
20-2507 2022-03-31
passing through the boundary to the receiving clock.
There are several techniques to choose from depending on the type of signal that should be synchro-
nized, e.g. a multi-bit signal is not handled in the same way as a signal that is 1 bit wide. The reader is
expected to be familiar with CDC synchronization techniques. The paper by Clifford E. Cummings [4] is
a good place to start if the reader’s knowledge needs to be refreshed.
In each of the user logic areas, there is one clock domain crossing in the default design—between the
control bus clock and the data bus clock. This boundary joins the control bus register values, representing
the current configuration, and the data bus logic, tasked with processing the data. To aid the user, there
are two CDC helper modules available in the development kit framework, listed in Table 2.
Table 2: CDC modules available in the development kit framework.
Module Description
cdc_bit CDC synchronization module for a 1-bit signal (see Section 4.3.1).
cdc_bus CDC synchronization of a multi-bit signal using a strobe (see Sec-
tion 4.3.2).
These modules should cover most CDC needs and should be used whenever CDC synchronization is
called for. Refer to Section 4.4 for details on the control bus and to Sections 6and 7for examples of
CDC synchronization and logic making use of these register values.
4.3.1 CDC Synchronization of a 1-bit Signal
The module cdc_bit should only be used for a signal that is unrelated to other signals since the propa-
gation of each bit may be different for parallel instances. Below is a description of the instantiation.
cdc_bit #(
.ENABLE_OUTPUT_REGISTER(”true”) // String; ”true” or ”false”.
// Adds register on data output.
) cdc_bit_reset (
.src_clk_i(src_clk), // 1-bit input: Source clock.
.dest_clk_i(dest_clk), // 1-bit input: Destination clock.
.src_data_i (src_data), // 1-bit input: Data driven by src_clk_i
.dest_data_o(dest_data) // 1-bit output: Data syncronized to dest_clk_i
);
Important
In most cases it is recomended to keep the default value of ”true” for the parameter
ENABLE_OUTPUT_REGISTER since the registers used for the CDC synchronization will prevent the auto-
matic replication performed by Vivado to reduce fanout. By adding the additional register, this situation
is avoided.
ADQ3 Series FWDAQ Development Kit spdevices.com Page 16 of 38

Classification Revision
Public B
Document ID Print date
20-2507 2022-03-31
4.3.2 CDC Synchronization of a Multi-Bit Signal
The module cdc_bus must be used when it is critical that each bit in a signal is propagated simultaneously.
cdc_bus #(
.WIDTH(WIDTH) // DECIMAL: Number of data bits.
) cdc_bus_datard (
.src_clk_i(src_clk), // 1-bit input: Source clock.
.dest_clk_i(dest_clk), // 1-bit input: Destination clock.
.src_rst_i(src_rst), // 1-bit input: Reset dest_data to zero.
// NOTE: It is recommeded to tie src_rst_i low
// unless there is a specific reason to use it.
.src_data_i(src_data), // WIDTH-bit input: Data to be synchronized.
.src_valid_i(src_valid), // 1-bit input: When asserted src_data_i will
// be synchronized to dest_clk_i.
// NOTE: This signal is ignored while
// src_ready_o is deasserted.
.src_ack_o(src_ack), // 1-bit output: Asserted when the data has
// been transferred to the destination clock.
.src_ready_o(src_ready), // 1-bit output: While asserted the module is
// ready to accept new data.
.dest_valid_o(dest_valid), // 1-bit output: Asserted when the data has
// been transferred to the destination clock.
.dest_data_o(dest_data) // WIDTH-bit output: Data synchronized
// to dest_clk_i.
);
Important
In most cases there is no need to clear the output registers in cdc_bus and it advised to tie src_rst_i
low. It shall not be connected to a global reset as this will have negative impact on timing.
ADQ3 Series FWDAQ Development Kit spdevices.com Page 17 of 38

Classification Revision
Public B
Document ID Print date
20-2507 2022-03-31
4.4 AXI Control Bus
Each user logic area can be accessed via the AXI control bus which provides a connection between
the custom logic and the software running on the host computer. A transaction cannot be started from
a user logic area and thus, communicating between the two modules using the control bus is not sup-
ported. Instead, transactions are initiated by the host interface which in turn is initiated from the ADQAPI,
specifically by using the functions to read or write user registers:
•ReadUserRegister()
•WriteUserRegister()
Refer to the ADQ3 series user guide [3] for the API documentation.
Note
Transactions on the control bus cannot be initiated from the user design, only from calling specific
functions in the ADQAPI.
4.4.1 Control Bus Signals
The control bus interface follows the AXI4-Lite format. The user logic needs to implement an AXI4-Lite
slave instance.
4.5 Data Bus
The stream of ADC data, its associated control signals and other metadata all propagate on the data
bus. The various signals are intricately related to each other and it is crucial that their relation in time is
kept intact while they are processed by the custom logic.
Important
The bus signals are closely related to each other and it is crucial that their relation in time is kept intact
through the user logic areas.
The development kit includes predefined functions to simplify the bus operations. There are two points
where the user design interfaces with the data bus: extraction and insertion. As the names suggest,
targeted signals are extracted from the bus and input to the custom logic to create a response. The
logic’s output signals are inserted back into the data bus and continues to propagate through the design
(see Fig. 3). Signals that are not inserted back into the data bus will be subjected to pipelining with a
delay equal to the value of the BUS_PIPELINE parameter. This parameter must be defined in the same
HDL source file as the bus operations. Fig. 4outlines the principle of working with the bus signals in the
user space.
4.5.1 Two Bus Definitions
The design has two different data bus definitions that are labeled data bus type 1 (DBT1) and data
bustype 2 (DBT2). The first user logic area uses the DBT1 bus definition while the second user logic
area uses the DBT2 definition. The two bus definitions each have their own set of functions to support
ADQ3 Series FWDAQ Development Kit spdevices.com Page 18 of 38

Classification Revision
Public B
Document ID Print date
20-2507 2022-03-31
bus operations. These are available in Verilog header (.vh) files in the framework/ directory and are
specified in Section 5. The user must only include the file matching the bus definition in the target user
logic area, i.e.
•databus_type1_functions.vh for the first user logic area (UL1) and
•databus_type2_functions.vh for the second user logic area (UL2).
Note
In the default design, the source files for the two user logic areas includes the appropriate bus defini-
tions.
Custom logic
Pipeline
Bus
Extracted
fields
Inserted
fields
Fields not
inserted manually
extraction
Bus
insertion
User space
BUS_PIPELINE
Figure 4: A diagram showing the principle of extracting signals from and inserting signals into the
data bus. Any field not inserted manually is subjected to a pipeline delay equal to the value of the
BUS_PIPELINE parameter.
ADQ3 Series FWDAQ Development Kit spdevices.com Page 19 of 38