Words by István Csomortáni, FPGA design engineer, Dragos Bogdan, software development engineer manager, Cristian Orian, system design engineer, and Andrei Cozma, engineer manager


nalog Devices’ new broad market LIDAR prototyping platform helps shorten customers’ product development time by providing a complete hardware and software solution that customers can use to prototype their algorithms and custom hardware solutions. As autonomous vehicles and robots continue to move from science fiction to reality, automotive and industrial customers are seeking new environment perception solutions to enable these machines to navigate autonomously. LIDAR is one of the fastest growing technologies in this field, and is seeing wider adoption as the technology becomes more mature and reliable, opening up a big market opportunity. As many startups and well renowned sensor companies are working toward developing more precise, less power hungry, smaller form factor, and more cost-effective LIDAR sensors, they all face the same challenges when it comes to system hardware design and implementing the software infrastructure to talk to all the components in the system. These are the exact areas where ADI can bring value through hardware reference designs, accompanied by open-source software stacks, enabling customers to easily integrate ICs from the ADI LIDAR portfolio into their products, as well as software modules and HDL IPs, shortening their product’s time to market.

SYSTEM ARCHITECTURE As customers develop their LIDAR sensors, there are few areas of differentiation in the system design: receive and transmit optics, number and orientation of lasers, laser firing patterns, laser beam steering, and number of light receive elements. But, regardless of these choices, there is a high degree of commonality in the receive signal chain and laser drive signal requirements. Based on these assumptions, Analog Devices designed a modular LIDAR prototyping platform, AD-FMCLIDAR1- EBZ, intended to allow customers to


easily configure or replace parts of the design with their own hardware, designed according to the requirements of specific applications, but still be able to utilise the platform as a whole system. The system is partitioned into three different boards with standardised digital and analogue interfaces: • A data acquisition (DAQ) board containing a high speed JESD204B ADC and corresponding clocking and power. This board has an FMC compliant interface to connect to the users’ preferred FPGA development board. It serves as the baseboard in the system by having the other two boards connected to it via digital connectors that route control and feedback signals between these boards and the FPGA, and through coaxial cables for analogue signals.

• An analogue front-end (AFE) board containing the avalanche photodetector (APD) light sensor and the entire signal chain, required for conditioning the APD output signal so that it can be fed into the ADC on the DAQ board.

• A laser board containing the lasers and drive circuit.

The LIDAR platform system design

evaluated when deciding on the system partitioning. In this case, the system was broken down into these three boards for the following reasons: • The ADC and clocking are very likely to stay the same, regardless of the implementation of the analogue front end and chosen laser solution.

• The analogue front-end hardware design and form factor is subject to change depending on the chosen APD, overall system receive sensitivity, and chosen optics.

• The laser board design and form factor are subject to change depending on the chosen illumination solution and optics.

• The system must provide a lot of flexibility in positioning and orienting the receiver and the transmitter, so that they are aligned with each other or other targets, which is why flex cables are being used for the digital signals and coaxial cables for the analogue signals that go between the boards.

The software stack that accompanies

the hardware design is based on a hierarchical approach, with a few layers dividing it into OS specific drivers and interfaces, a system specific API, and an application layer. This allows the upper layers of the stack to remain unchanged regardless of whether the software is running on an embedded target or a PC talking to the system via the network or a USB connection. This is very valuable in the different product development stages since it means that

As always, in system designs, modularity means flexibility, but it also comes with drawbacks such as increased complexity, performance degradation and increased cost, which must be thoroughly

the same application software that was developed during the prototyping stages, when the system is tethered to a PC for ease of development, can be deployed easily onto the embedded production


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36  |  Page 37  |  Page 38  |  Page 39  |  Page 40  |  Page 41  |  Page 42  |  Page 43  |  Page 44