“This article explores Analog Devices’ new and widely marketed LIDAR prototyping platform, and how it can help customers shorten product development by providing a complete hardware and software solution that enables users to prototype their algorithms and custom hardware solutions Time; details modular hardware design, including optical receive and transmit signal chains, FPGA interfaces, and optics for long-range sensing; introduces system partitioning decisions to highlight good system design, interface definition, and proper modularity Importance of grading; describes the components of the open source LIDAR software stack and platform-customized APIs, showing customers in production

“

Summary

This article explores Analog Devices’ new and widely marketed LIDAR prototyping platform, and how it can help customers shorten product development by providing a complete hardware and software solution that enables users to prototype their algorithms and custom hardware solutions Time; details modular hardware design, including optical receive and transmit signal chains, FPGA interfaces, and optics for long-range sensing; introduces system partitioning decisions to highlight good system design, interface definition, and proper modularity The importance of grading; describes the components of the open source LIDAR software stack and platform-customized APIs, showing how customers benefit during product development and how these products can be integrated into their final solutions.

Introduction

As self-driving cars and robots move from imagination to reality, automotive and industrial customers are looking for new environment-aware solutions to enable these machines to navigate autonomously. LIDAR is one of the fastest growing technologies in the field, and as it becomes more mature and reliable, its application scope becomes wider, bringing huge market opportunities. Many startups and established sensor companies are working to develop more accurate, lower power, smaller, and more cost-effective LIDAR sensors, but when designing the system hardware and implementing the software infrastructure to communicate with all the components in the system, they have encountered the same challenges. It is in these areas that ADI can deliver value through software reference designs and open source software stacks, enabling customers to easily integrate the ADI LIDAR product family, software Modules and HDL IP into their products and ICs, reducing time to market.

system structure

When customers develop their own LIDAR sensors, there are some differences in system design: receive and transmit optics, number and orientation of lasers, laser emission patterns, laser beam steering, and number of light-receiving elements. However, regardless of the choice made, all sensors are highly similar in terms of receive signal chain and laser drive signal requirements. Based on these assumptions, Analog Devices designed the modular LIDAR prototyping platform AD-FMCLIDAR1-EBZ to allow customers to easily configure or replace devices with their own hardware; the platform is designed for specific application requirements, but can still be used as a complete system. The system can be divided into three different boards, each equipped with standardized digital and analog interfaces:

A data acquisition (DAQ) board containing a high-speed JESD204B ADC, corresponding clocks, and power supplies. This board has an FMC compliant interface to connect to the user’s preferred FPGA development board. It acts as the baseboard for the system, connecting the other two boards to this board through digital connectors for routing control and feedback signals between these boards and the FPGA, and coaxial cables for analog signals.

An analog front-end (AFE) board containing the avalanche photodetector (APD) light sensor and the entire signal chain used to tune the APD output signal so that it can be fed into the ADC on the DAQ board.

Laser board containing laser and driver circuit.

As ever, in system design, modularity means flexibility, but it also has disadvantages, such as increased complexity, performance degradation, and increased cost, which must be fully evaluated when deciding on system partitioning. In this case, the system is divided into three boards for the following reasons:

Regardless of which analog front end is used, and which laser solution is chosen, the ADC and clock will most likely remain the same.

The analog front-end hardware design and size will vary depending on the APD chosen, the overall system receive sensitivity, and the optics chosen.

Laser board designs and dimensions vary depending on the chosen lighting solution and optics.

The system offers a lot of flexibility in the location and orientation of the receiver and transmitter so that they correspond to each other or to other objects, so flex cables are used to transmit digital signals and coaxial cables are used to transmit between two circuit boards the analog signal.

Figure 1. LIDAR platform system design.

Figure 2. Product development cycle.

The software stack that includes the hardware design is based on a layered approach, with a few layers divided into OS-specific drivers and interfaces, system-specific APIs, and application layers. This allows the upper layers of the stack to remain the same whether the software is running on an embedded target or on a PC that communicates with the system via a network or USB connection. As shown in Figure 2, this is useful at different stages of product development, as it means that the same application software developed during prototyping can be easily deployed into an embedded system when connecting the system to a PC to simplify development , without even touching the low-level interface.

hardware design

LIDAR sensors calculate the distance to a target by measuring the time it takes for a light pulse to reach the target and return. When measuring time, the ADC sampling data is used as an increment, where the ADC sampling rate determines the resolution of the system sampling the received optical pulse. Equation 1 shows how to calculate distance based on the ADC sampling rate.

in:

LS is the speed of light, 3 × 108 m/s

fS is the ADC sampling rate

N is the number of ADC samples from light pulse generation to return reception

Assuming the system uses the 1 GHz sampling rate of the AD9094JESD204B quad ADC, each sample results in a distance of 15 cm. Therefore, sampling uncertainty cannot exist in the system, as any sampling uncertainty can lead to large distance measurement errors. Traditionally, LIDAR systems have been based on parallel ADCs, which inherently provide zero sampling uncertainty. As the number of receive channels continues to increase and the power and PCB size requirements become more stringent, these ADC types do not scale well. Another option is to use an ADC with high-speed serial outputs, such as JESD204B, to address the issues with parallel ADCs. This option has a higher data interface complexity, making it difficult to achieve zero sampling uncertainty.

Figure 3. DAQ board clock and data paths.

Figure 4. AFE board signal chain.

The LIDAR DAQ board provides a solution to these challenges by ensuring deterministic latency by demonstrating a power, clock and data interface design for a JESD204B data acquisition system operating in Subclass 1 mode to achieve zero sampling uncertainty while leveraging JESD204B All the advantages provided by the interface, the power consumption of the clocking scheme is minimized. To run JESD204B in Subclass 1 mode, the system uses a total of 5 clocks:

ADC sampling clock: Drives the ADC signal sampling process.

ADC and FPGA SYSREF: Source synchronous, high slew rate timing resolution signal to reset the device clock divider to ensure deterministic latency.

FPGA global clock (also known as core clock or device clock): Drives the output of the JESD204B PHY layer and FPGA logic.

FPGA reference clock: Generates the PHY layer internal clock required by the JESD204B transceiver; needs to be equal to, or an integer multiple of the device clock.

All clocks are generated by an AD9528 JESD204B clock generator, so they are guaranteed to be synchronized with each other. Figure 3 shows the clocking scheme, as well as the data interface to the FPGA.

The AFE board receives the optical reflected signal, converts it into an electrical signal, and transmits it to the ADC on the DAQ board. This board is probably the most sensitive part of the entire design, as it mixes the signal conditioning circuit (using the microamp current signal generated by the 16-channel APD array), converts the optical signal to an electrical signal, and uses the required power to power the same APD. C120 V to C300 V high voltage power supply. The 16 current outputs are fed to four low-noise quad transimpedance gain amplifiers (TIA) LTC6561 with an internal 4-in-1 multiplexer to select which output channel is then fed to one of the ADC inputs. Special attention is paid to the input section of the TIA to achieve the required level of signal integrity and channel isolation so that the very low current signal generated by the APD is not impregnated with more noise, thereby maximizing the SNR and object detection rate of the system. The design of the AFE board shows that the best way to achieve the highest signal quality is to keep the line length between the APD and TIA as short as possible and add elliptical holes between the TIA inputs to maximize channel-to-channel isolation; When deploying the signal conditioning circuit, ensure that the circuit does not interfere with other power circuits on the board. Another important feature is the ability to measure the temperature of the APD to compensate for changes in the APD’s signal output due to an increase in the APD’s temperature during normal operation. Several knobs are provided to control the signal chain bias and APD bias, which translates into APD sensitivity to maximize ADC input range for maximum SNR. Figure 4 shows the block diagram of the AFE board signal chain.

The laser panel generates optical pulses with a wavelength of 905 nm. It uses four lasers that are driven simultaneously to increase beam intensity and enable longer measurement distances. The laser is controlled using a PWM signal with programmable pulse width and frequency generated by an FPGA carrier board. These signals are generated on the FPGA and transmitted in LVDS from the FPGA to the laser board, and are less susceptible to noise during their journey through the DAQ board and the flat cable connecting the DAQ to the laser board. The drive signal can be returned to one of the ADC channels for a time-of-flight reference. An external power supply is used to power the laser. Its design meets the requirements of the international standards IEC 60825-1:2014 and IEC 60825-1:2007 for Class 1 laser products.

Both the AFE and the laser board require optics to enable long distance measurements. The system has been shown to measure up to 60 meters, using a fast axis collimator1 that helps the laser diode reduce the vertical FoV to 1°, while keeping the horizontal field of view constant, placing a non- spherical lens.

HDL Reference Design

The HDL design contains the main interfaces to the hardware, the logic that implements the transfer of data from the JESD link to the system memory, drives the lasers, synchronizes the receiver and transmitter for accurate time-of-flight measurement, and designs the communication interfaces on all components. Figure 6 shows a simplified block diagram of the HDL design. ADI’s HDL reference design uses a common architecture to make the framework scalable and easier to interface to another FPGA port. The design uses Analog Devices’ JESD204B framework 2, along with multiple SPI and GPIO interfaces, to receive data from the AD9094 ADC and to control all devices on the prototyping platform.

The JESD204 link is configured to support 4 data converters (M) using 4 lines at a line rate of 10 Gbps to achieve 8-bit converter resolution. The device clock is the same as the reference clock for the high-speed transceiver, set to 250 MHz, provided by the DAQ board. The link operates in Subclass 1 mode, ensuring deterministic latency between the high-speed converter and the FPGA.

For LIDAR systems, the biggest challenges are how to synchronize the various functions and transmit pulses, and how to process the necessary amount of data received from the high-speed ADC. To address this challenge, an IP was included in the HDL design to provide the logic needed to generate the laser pulses, control the TIA’s internal multiplexer, and provide back pressure for the DMA. All of these control functions are synchronized with the transmit pulse so that the system does not need to save all of the original high-speed quantized data stream. As such, the overall data rate of the system is greatly reduced.

software

Several key points that define the software stack of the LIDAR platform include free and open source. Users are thus able to “freely run, copy, distribute, learn, change, and improve the software,”3 including tools from the Linux kernel to the userland, and all code associated therewith.

The software drivers used in the kernel start the hardware components and show the user all available functions. Most of these drivers are part of the Industrial I/O (IIO) Linux subsystem. 4 These drivers are platform-independent, so no hardware changes are required, including those related to the FPGA vendor (eg, migrating from Xilinx FPGAs to Intel).

To simplify software interface IIO device development, ADI has developed the libiio library. 5 This library abstracts the low-level details of the hardware and provides a simple but complete programming interface that can be used by advanced projects. Multiple available libiio backends (e.g., local, network, USB, serial) support using the IIO device locally, as well as remotely in applications running on different operating systems (including, Linux, Windows, macOS) .

An example of such an application is the IIO oscilloscope developed by Analog Devices, which uses libiio to interface with IIO devices and can be used during the system evaluation phase. The tool captures and graphs data in different modes (eg, time domain, frequency domain, constellation, cross-correlation), transmits data, and allows the user to view and modify the settings of the device under test.

While libiio provides a low-level programming interface, in most cases users expect to use a platform-specific API that aggregates low-level driver calls to expose a set of functions for accessing and configuring various system parameters and streaming data. As such, the LIDAR prototyping platform employs specific APIs, as well as supporting components for commonly used frameworks and programming languages ​​such as C/C++, MATLAB or Python,6 enabling users to connect to the system using their preferred programming language and focus on research and development Algorithms and applications of great value to customers.

in conclusion

For system design, there is a certain level of ambiguity when establishing the architecture and making design decisions. This represents the risk of a system not working or functioning properly after it is built, resulting in repeated design cycles, increased development costs, and longer time-to-market. Reference designs are based on pre-engineered systems designed to interoperate with each other, with reduced risk and improved overall predictability and reliability compared to custom purpose-built designs from scratch. Using reference designs as a starting point in the planning process helps bring new designs to market faster and ensures fewer surprises and problems. System designers always look to reference platforms to validate their designs to reduce risk and improve reliability. When starting a project, using clear and standard design options can help drive the planning process forward. This can be achieved by using a common language to help align goals, encourage collaboration and engagement across multiple functions, and help simplify the evaluation and trade-offs between design goals. The LIDAR prototyping platform seeks to meet these needs by providing open-source hardware and software designs that can provide reference during the initial system architecture phase. Hardware platforms and software stacks can be used throughout the product development phase, from initial system evaluation, development, and integration into the final product. The content of the reference design (such as engineering drawings and BOM) can be constructed, legal, localized system design provides a good start. Can help shorten design cycles and potentially save money along the way. Modular hardware design support enables a variety of configuration options to meet specific application requirements, while an open source software stack with application examples based on industry standard frameworks and programming languages ​​allows customers to focus on developing applications and adding value to the product without expending effort on The lower level of the stack.