-For the development of FPGA-based automotive systems, debugging of internal signals is necessary to detect errors or to analyze/visualize the operation of the field programmable gate array (FPGA) at runtime. Often, so called ”debug cores” of the FPGA vendor are used for debugging. Xilinx Vivado is a development environment offering an integrated logic analyzer for statically selected signals. However, each time these input signals shall be changed, the whole workflow (synthesis, placement, routing and generation of the bit stream) must be repeated, which is very time consuming. The scope of the present work is to develop a custom and more flexible FPGA-based logic debugger: The Advanced Inverter Debugger (AID) is a logic component, integrated into the system under development, that can dynamically select signals for the debugging process at run-time. The debugging process is controlled by a user interface at a workstation, communicating via UDP/IP over Ethernet. The AID is configurable with regard to start/stop triggers and sample rate for each signal, and allows long-term recording as well as visualization at the workstation. For convenient use in the development of automotive control systems, the AID is available as Matlab component for integration into and synthesis with the target system. Index Terms-automotive, debugging, FPGA
In the automotive industry, electric engines are becoming more and more important. For testing synchronous and asynchronous engines, complex test benches are used, which are able to set up different test conditions. These test benches use FPGA-based inverters and controllers, which provide several functionalities, e.g., pulse width modulation (PWM), phaselocked loop (PLL), voltage and current control to power the different synchronous and asynchronous engines. During the development process, these inverters and controllers must continuously be checked for correct operation, which is done by debugging internal signals of the FPGA design.
For debugging, standard debug cores of the FPGA vendor
like the integrated logic analyzer (ILA) [
The present work introduces a custom FPGA-based logic debugger, the Advanced Inverter Debugger (AID). The AID can dynamically select signals for the debugging process at run-time. The debugging process is controlled by a user interface at a workstation. The debugging parameters are sent from the workstation to the debug core on the FPGA. The communication is done with UDP/IP (user datagram protocol/internet protocol). The debug core decodes the command information from the user interface and autonomously starts the debugging process with the given configuration. The sampled signal data is then sent from the FPGA to the workstation and monitored with the user interface. Optionally, the signal data can be logged in comma-separated values (csv) files for long-term observation and delayed analysis.
This paper is organized as follows: Section II shows related work on debug cores. Section III gives an overview on different concepts to implement such debug cores. Section IV explains the structure and operation of the AID debug core. Section V shows the resource usage of the debug core on the FPGA. Section VI shows the test hardware on which the debug core was tested. Section VII shows the user interface, which controls the debug core and tests. Finally, Section VIII concludes the paper.
Xilinx Vivado provides the ILA core, which allows developers to put an integrated logic analyzer into their FPGA designs. An ILA can monitor signals during the execution of the system at a predefined sampling rate if the signals meet predefined trigger conditions. The logic overhead varies depending on the selected number of samples and the defined input signals. The samples are stored on the FPGA and sent via a JTAG interface to the workstation for monitoring with Xilinx Vivado.
Debugging and validation of logic in FPGA designs was
also considered by various researchers. In [
Copyright © 2020 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). of the FPGA design. The connection between the signals and the microprocessor works via the on-chip memory (OCM) bus and the processor’s local bus (PLB) through the shared memory.
Another method uses a scan-chain based approach [
With this method it is possible to change the watch-point conditions at run-time without a recompilation of the FPGA design. However, the monitored signals can not be changed at run-time.
III. COMMUNICATION CONCEPTS FOR THE DEBUG CORE
The debug core was initially designed to debug internal signals of inverters and voltage and current controller for automotive test benches. To debug these internal signals and to visualize the inverter and controller behavior, the AID provides an interface for up to 300 possible input signals. Out of these, 4 can be selected dynamically for the debugging process at run-time. The 300 input signals were chosen to have a large selection of the internal signals of the controller. Due to the high number of signals, big multiplexers are required. To lower the resource usage on the FPGA, only 4 signals can be selected concurrently for the debugging process. The debug core sends the sampled signal data continuously to the user interface, depending on the sampling frequency. Once started, this allows infinite debugging processes.
For the inclusion of the debug core into the FPGA design, 3 different methods are discussed in this section.
A. Communication with UDP/IP and the ARM Processor
With this approach, the communication between the debug
core and the user interface at the workstation is done via
UDP/IP and the processing system (PS) [
To connect the programmable logic (PL) with the PS of the
ARM processor, the Advanced eXtensible Interface (AXI) [
The AXI-DataMover [
The connection from the PL to the PS is done with interrupts and DMA. The sampled signal data is written via AXIDataMover into the RAM and the interrupt is set. The PS processes the corresponding interrupt and reads the signal data from the RAM, builds the UDP package and sends it to the workstation with the user interface.
The lwIP library also allows to use the transmission control protocol (TCP) for the connection between the ARM processor and the workstation. However, due to lower communication overhead with UDP/IP, smaller data packages can be sent faster from the ARM processor to the workstation. Therefore, UDP/IP was selected.
Fig. 1. Communication between the debug core and the user interface with UDP/IP and the ARM processor.
B. Communication with UDP/IP and the AXI-Ethernet IP core
This approach uses the AXI-Ethernet [
With this approach no PS and ARM processor is required.
There is also no need for the DMA to access the RAM because the signal samples can be collected for a UDP package in registers on the FPGA. This might slightly increase the resource usage on the FPGA but can be accepted.
Fig. 2. Communication between the debug core and the user interface with UDP/IP and the AXI-Ethernet IP core.
C. Communication with TCP/IP and the AXI-Ethernet IP core IV. DESIGN AND IMPLEMENTATION OF THE DEBUG CORE
This approach also uses the AXI-Ethernet IP core for the communication between the debug core and the user interface, shown in Fig. 3. The debugging parameters are sent with TCP/IP from the user interface to the MAC interface. The AXI-Ethernet IP core receives the data and routes it via AXIS bus to the DebugCore block. TCP/IP allows bigger data packages and more signal data can be sent to the user interface.
Therefore, sampled signal data can be stored in the RAM for the TCP package payload. To write the signal data into the RAM, the AXI-DataMover is used. When enough samples are collected, the data is read from the RAM and transferred to the AXI-Ethernet IP core. The Ethernet transceiver sends the TCP package to the user interface at the workstation.
With this approach, no PS and ARM processor is required.
The RAM can be accessed with the AXI-DataMover and DMA to collect the signal samples for the TCP package. This requires a unit, which controls the write and read operations via the AXI-DataMover. This concept is more complex compared to the others, because memory access and the inclusion of the AXI-Ethernet IP core is required.
To use the AXI-Ethernet IP core, a licence for the Xilinx
Tri-Mode Ethernet Media Access Control (TEMAC) [
The idea was to send the sampled signal data as fast as possible to the workstation to minimize the used memory resources on the FPGA. With UDP/IP, packages can be sent faster compared to TCP/IP and potential package loss with UDP was not an issue during our evaluations and in-field tests. Both concepts with the AXI-Ethernet IP core are processor independent, which is a big advantage for the integration of the AID into different FPGA designs. Unfortunately, due to the missing TEMAC licence during the development time, the AXI-Ethernet IP core couldn’t be used and both concepts with the AXI-Ethernet IP core were not possible for the implementation. To evaluate the functionality of the AID and to analyze the communication with UDP/IP, the decision was made to implement the first concept, ”Communication with UDP/IP and the ARM processor”.
The debug core was developed in VHDL (very high speed
integrated circuit hardware description language). It is built
with different units shown in Fig. 4. The MM2S-Datamover
interface is the AXIS interface for the Memory Mapped to
Stream (MM2S) transfer. The interface is used, when the
AXIDataMover reads the debug parameters from the RAM and
transfers it to the debug core. With the unpackage (UNPKG)
Module, the AXIS data is decoded into the different
parameters to set up the debugging process. The decoded signals
are routed to the Debug Core Module, which is the heart
of the debug core. It is responsible for the trigger, signal
selection and signal sampling. The Debug Core Module unit
was developed with Matlab [
The debug core has up to 300 possible input signals, each 32 bits wide. They are combined to a signal interface and 4 signals of them can be selected for the debugging process.
The signal selection is part of the Debug Core Module block. To select the 4 signals, 4 big multiplexers are used. In Matlab SIMULINK, a 300:1 multiplexer can be built very easily, but when the VHDL code is generated and synthesized, the multiplexers are built with the available F7 and F8 multiplexers of the FPGA. Since these multiplexers are commonly needed for the main functions of the controllers and inverters, our 300:1 multiplexers are designed to us Look-up Tables (LUT). This was done by using bit wise logical disjunction.
To select the signals for the debugging process, the control information from the user interface is decoded and routed as selection signals into the signal selection blocks. Depending on the value, one of the 300 input signals is selected as output signal. The structure of the signal selection is shown in Fig. 5. The signal selection can be done at run-time.
The selected signals can be sampled with the adjusted sample frequency. The operation frequency is 1 MHz for debug core but all modules using the AXIS interface are operating at a frequency of 100 MHz. The maximum sample frequency is limited to 1 MHz and the lowest sample frequency is 1 kHz. Overall, there are 25 different sampling frequencies for the debugging process available, which can be selected in the user interface. An internal counter controls the sample points depending on the adjusted sample frequency. The functionality is comparable to a frequency divider.
The number of samples defines how long the debugging process is active. The selectable values are between 1024 and 999424 samples. The step size is 1024. An internal counter increases with each sample and when the adjusted number of samples is reached, an internal reset occurs, which stops the debugging process and resets all of the debug core sub modules. This operation mode is called normal mode. There is a second operation mode, the infinity mode, in which the sampling process is active until the stop command information is sent from the user interface to the FPGA.
To influence the start condition, a trigger can be enabled. There is a pre- and a post-trigger available. The post-trigger activates the sampling process immediately when the trigger condition is met and the sampled signal data is sent to the user interface. The pre-trigger continuously saves 100 samples per signal into a ring buffer. Once the trigger condition is met, the signal data is sent from the ring buffer to the user interface. This allows to also analyse the signals before the actual trigger event.
To access the Block RAMs (BRAM) of the ring buffer, counters are used as write and read addresses. When the start debugging command was received, the write address increases with each sample point. If no trigger event happens and 100 signal values are written into the BRAMs, the write address overflows and starts at 0 to overwrite the old signal values. The read address starts to increase and follows the write address with a constant gap. The read address also increases, when the trigger condition is met. Then, the values of the ring buffer are used to build the UDP packages. This gives information about the signal behaviour before the trigger event occurs.
Trigger condition can be set for the post- and pre-trigger. The available trigger conditions are above, lower or equal to the trigger value, shown in Table I. The trigger signal is always the first selected signal. When no trigger is active, the sampling process starts directly after sending the start debugging command information from the user interface to the FPGA. C. Communication between the Programmable Logic and the Processing System of the ARM processor
The communication from the PS to the debug core on the FPGA is done with AXI-GPIO ports, shown in Fig. 4. They support a configurable I/O channel width of up to 32 bits. These AXI-GPIO ports can be addressed with driver files from the PS. AXI-GPIO ports are used to initialize the read operation from the RAM with the AXI-DataMover. To configure the transfers between the AXI-DataMover and the RAM also AXI-GPIO ports are used.
The communication from the debug core to the PS is done with interrupts. The first interrupt signals the PS that the debug parameters were successfully read from the RAM and the AXI-GPIO port for initializing the read operation can be reset.
The second interrupt signals the PS, that the sampled signal values were successfully written into the RAM and can be read with the PS, to build the UDP package and send it to the workstation. To prevent simultaneous memory access, 2 memory addresses are used alternately to write the sampled signal data into the RAM. The DataMoveCTL block controls the alternating address change. Multiple samples can be collected for the UDP transfer, before the interrupt is set. The adjustments for this can be made in the IP settings of the DataMoveCTL block or with the PS and AXI-GPIO ports. Currently 32 samples are used to build the UDP package. One sample contains the package type, sample number (timestamp) and the 4 signal values.
D. Communication between the user interface and the ARM processor
The communication between the user interface and the ARM processor is done with UDP/IP. Different package types are defined, to distinguish between control information, version number and signal data. The package type defines, which information are transmitted with the UDP package. The different package types are shown in Table II. A standalone application with a UDP echo server is running on the ARM processor. It receives and sends the UDP packages.
If a UDP package is received and the command data are written into the RAM, the AXI GPIO port to enable the read operation is set. The corresponding interrupt is processed by the interrupt system and the program waits for the interrupts to read the signal data from the RAM to build the UDP package and send it to the workstation.
The version number request is directly processed by the PS, which sends the version number back to the user interface.
Description command information to start the debugging process
signal data command information to reset the debugging process
request for the version number version number acknowledgement V. RESOURCE USAGE OF THE DEBUG CORE ON THE FPGA
The signal selection logic is the biggest part of the debug
core. The multiplexers with 300 input signals, each 32 bits,
need a significant amount of resources on the FPGA in order to
allow selection flexibility. To lower the resource usage, a debug
core with 40 possible input signals was created. A comparison
between the AID300 and AID40 is shown in Table III. The
FPGA on the ZedBoard [
The debug core was tested with the ZedBoard [
The user interface controls the debug core on the FPGA. All adjustments for the UDP connection and the debugging process can be made here. The UDP connection is set up with the IP address, incoming and outgoing port numbers.
To get the signal names from the FPGA design, which are connected to the debug core, a signal configuration file generator was implemented with C#. This file generator extracts the input signal names with the interface name of the debug core of the FPGA design and maps them to the input port numbers to generate a csv configuration file. This configuration file can be loaded into the user interface to display the signal names, which can be selected for the debugging process.
The user interface was programmed with C# and tested with the ZedBoard. Fig. 6 shows the user interface with the different settings for the debugging process. The debugging process was started with 8192 samples and a sample frequency of 1 MHz. The post-trigger is selected as trigger condition and data logging is enabled, which generates a csv file and saves the signal data with the debugging settings.
After each received 999424 samples, a new file is automatically created. This is important, when the debugging process is running in infinity mode. The csv files with the logged signal data can also be loaded and monitored with the user interface for delayed analysis.
To test the debug core, a signal generator is used to simulate
a complex FPGA-based automotive system. It generates 300
test signals, which are used as input signals for the debug
core. The first 20 test signals are simple counters, which start
at different values and increase with different frequencies. The
other test signals are constants to test the signal selection
of the debug core. The test setup is a hardware in the
loop test by running the FPGA design on the FPGA of the
ZedBoard. The debugging process is started with the adjusted
debugging settings of the user interface. A receiving thread
and a processing thread are used to receive the UDP packages
and to process, log and monitor the signal data. It works well
for lower sample frequencies and high sample frequencies with
lower sample numbers shown in Fig. 7. The sample frequency
is adjusted to 1 MHz and the number of samples is set to
60416. However due to UDP/IP, small packages can be sent
very fast from the FPGA to the workstation and when a large
number of samples and a high sample frequency (1 MHz or
500 kHz) are adjusted, sample loss occurs. During the tests, the
incoming UDP packages were analyzed with Wireshark [
This paper shows a custom FPGA-based debug core, the Advanced Inverter Debugger (AID), which was initially develFig. 8. Testing the debug core with the ZedBoard with 1 MHz sampling rate and 100352 samples oped to debug FPGA-based inverters and controllers. The AID is able to dynamically select signals for debugging FPGAbased embedded automotive systems at run-time. In order to be flexible with the signal selection, the possible number of input signals has to be large. However, the multiplexers for the signal selection requires more resources on the FPGA, which might not be available.
The AID is controlled by a user interface at a workstation. The communication is done with UDP/IP and the processing system (PS) of the ARM processor. To transfer the data between the programmable logic (PL) and the PS, the processor RAM is used.
The limitations of this approach are the receiver of the workstation and the PS of the ARM processor. With UDP/IP, packages can be sent very fast but the user interface at the workstation has problems to process the data at high sample frequencies. The receiving thread of the user interface is blocked sometimes, which leads to sample loss. There are also limitations when the PS is used for other operations beside the AID. Some interrupts of the debug core might no longer be processed, UDP packages are not sent, and samples get lost.
For the future, the TEMAC license can be acquired to use the AXI-Ethernet IP core. With this IP core, the communication can be done without the PS but the flexibility of the AID remains the same. Also, the communication can be changed to TCP/IP. With TCP/IP, bigger packages can be sent and the receiver has more time to process the received data.
This research was supported by AVL List GmbH, Graz, Austria.