Special Session: In-System-Test (IST) Architecture for NVIDIA Drive-AGX

Total Page:16

File Type:pdf, Size:1020Kb

Special Session: In-System-Test (IST) Architecture for NVIDIA Drive-AGX 2019 IEEE 37th VLSI Test Symposium (VTS) ! Special! Session: In-System-Test (IST) Architecture for NVIDIA Drive-AGX Platforms Pavan Kumar Datla Jagannadha, Mahmut Yilmaz, Milind Sonawane, Sailendra Chadalavada, Shantanu Sarangi, Bonita Bhaskaran, Shashank Bajpai, Venkat Abilash Reddy, Jayesh Pandey, Sam Jiang NVIDIA Corp, 2788 San Tomas Expressway, Santa Clara, CA 95051, USA {pavand, myilmaz, msonawane, schadalavada, ssarangi, bbhaskaran, sbajpai, vreddy, jpandey, sajiang}@nvidia.com Abstract - Safety is one of the crucial features of autonomous Xavier AI SOC and delivers 30 TOPS (Tera Operations Per drive platforms, and semiconductor chips used in these Second) of performance while consuming only 30 watts of architectures must guarantee functional safety aspects mandated by power. It includes various processors for redundant and diverse ISO 26262 standard. To monitor the failures due to field defects, deep learning algorithms. For applications that require ultimate in-system-structural-tests are automatically run during key-on performance, NVIDIA DRIVE AGX Pegasus™ achieves 320 and/or key-off. Upon detection of any permanent defects by the in- TOPS of deep learning with an architecture built on two system-test (IST) architecture, Drive platform responds to achieve NVIDIA Xavier™ processors and two next generation GPUs the fail-safe state of the system. In this paper, we present the IST based on Turing architecture [2]. architecture that helps with achieving highest functional safety levels on the NVIDIA Drive platform. Automotive ICs are screened with high-quality test methods to achieve near-zero DPPM (Defective Parts Per Keywords— automotive, functional safety, ISO 26262, in- Million). Even with such high standards of testing, there can be system-test, MBIST, LBIST, ATPG, power, permanent faults reliability defects that will manifest during the in-system field operation due to environmental or operating conditions [3]. I. INTRODUCTION The ISO 26262 standard [4] defines functional safety for all The design complexity of SOCs (System-On-Chip) and electronic and electrical equipment used in automotive safety- GPUs (Graphic Processing Unit) used in Autonomous driving related systems. These functional safety features form an applications is on a steady rise. Companies are moving to integral part of each automotive product development phase. lower semiconductor technology nodes to meet the high- ISO 26262 also defines the various ASIL (Automotive Safety performance requirements of these mission critical Integrity Level) standards applicable to the lifecycle of these applications. These SOC and GPU chips are tested during systems. Different ASIL levels (A, B, C, and D) have different production testing to screen for manufacturing defects and only test coverage targets, with ASIL-D being the most stringent known good die are used on system boards designed for drive among these and requiring the highest test coverage. platform applications. NVIDIA ICs used in automotive applications have built-in Automotive drive platform applications are considered functional safety mechanisms such as ECC or functional highly safety critical [1] and any failure of the integrated redundancy. IST supplements these safety mechanisms to circuits (ICs) used in these systems could be life threatening. achieve the highest possible ASIL level for permanent fault NVIDIA Drive AGX platform (Fig. 1) is architected from the coverage targets. ground up for safety. It is an AI (Artificial Intelligence) super computer that can run an array of deep neural networks IST involves execution of structural ATPG (Automatic simultaneously and is designed to safely handle highly Test Pattern Generation) vectors, i.e., deterministic scan automated and fully autonomous driving. Drive AGX platform compression and Logic Built-In Self-Test (LBIST), and a has different configurations that can support various comprehensive set of MBIST (Memory Built-In Self-Test) performance needs. Drive AGX Xavier™ includes a single algorithms during key-on and/or key-off to determine a pass or a fail status. IST can cover all fault models applicable to lower geometry FinFET technologies. The challenge was to translate the execution of these vectors into a fully self-contained functional feature that could be repeatedly used in an automotive system for the life time of the vehicle within the test-time and power budgets. In this paper, we present details of the IST operation and challenges we had to overcome. Section II lists goals of IST. High-level IST architecture is presented in Section III. Section IV includes the challenges we faced and corresponding solutions. We conclude the paper with silicon results and final Fig. 1. NVIDIA Drive AGX Pegasus™ Platform remarks. 978-1-7281-1170-4/19/$31.00 ©2019 IEEE ! II. GOALS The! primary goals of IST architecture can be categorized as follows: • High quality test: To achieve the highest ASIL safety level, the design under test (DUT) needs to have a very high permanent test coverage. Additionally, we expect that comprehensive set of fault models needs to be supported by test to detect lower geometry FinFET design defects [5][6][7]. • Low latency: The high-quality test patterns are quantified by highest test coverage achieved with shortest possible test time and smallest test data volume. • Architecture flexibility: The architecture should be fully scalable for varied clock frequencies and data rates to adapt to power, storage, and latency requirements. It should also support different design configurations. • TDP (Thermal Design Power) budget: We need to make sure we stay within the limits of the functional TDP during IST execution. • Debug and diagnosis: The architecture should support all modes of debug and diagnosis and provide traceability for field returns. III. HIGH LEVEL IST ARCHITECTURE The IST architecture enables structural testing of a complex SOC system to detect permanent faults in the field. It can be used for supplementing functional safety mechanisms for permanent fault coverage goals as specified in ISO 26262 [4]. It is fully scalable and can meet the various requirements over the life-cycle of the product. IST supports key-on and key-off testing, updating test configurations and their application sequence, and targeting comprehensive fault models under different test conditions, e.g voltage and clock frequencies. The scheme also maintains a high level of in-field diagnostic granularity of scan and MBIST test patterns. This architecture is not limited to the in-field application of test patterns. It can also be used for System Level Test (SLT) to screen for defects to further improve test quality. For example, it can help in bridging the gap between ATE environment and the platform specific operating conditions. IST uses a combination of hardware and software components to test a Xavier SOC standalone and/or a discrete Turing GPU paired with Xavier SOC. Fig. 2 shows an overview of IST architecture where test data and results are stored off-chip in the eMMC (Embedded Multi-Media Card) flash memory on the platform. The eMMC memory size requirements are based on desired test-quality and the cost of the platform. For the DRIVE-AGX platforms, the test-data for Fig. 2. In-System Test Architecture the Turing dGPU will also be stored in the eMMC flash memory which is connected to the Xavier SOC. The data will For IST, production ATE test patterns should be translated be transported from the Xavier SOC to the Turing over PCIe. into a packet format that can be stored on eMMC memory, The hardware (HW) controller has a direct communication then fetched and decoded by HW controllers on chip. Test data path with the flash memory. application during production testing is from primary pins of ! the SOC and/or GPU using ATE platforms. The test data Our manufacturing test programs ensure that defective parts application during IST is enabled by intercepting the are not shipped to customers, and the design-for-testability multiplexers! inside the IP being tested. Customized software (DFT) structures we insert throughout the chip ensure that tools were developed to create and store IST test programs on these tests are of the highest quality with quantifiable coverage eMMC memory. and low latency. The challenge was to translate this expertise of manufacturing testing into a fully self-contained functional IST HW controllers on Xavier and Turing communicate feature that could exercise the same high-quality structural tests with various on-chip as well as platform components to in an automotive system. Furthermore, IST needs to run these execute the tests utilizing the IEEE 1500, Scan compression tests while a subset of the logic stays functional. [8][9], XLBIST [10], and MBIST systems on the chip. The HW controllers are programmed via IEEE 1500 as well as via software registers. The controllers can handle platform A. Test-Data and Test-Latency Limitations interrupts, e.g., thermal interrupts, and power cycling to meet The key-on and key-off application of IST mandates a very the performance and latency requirements specified for a given low test-latency relative to ATE tests. Furthermore, external system. memory requirements should be minimized to reduce platform cost. Based on the request to execute IST either during key-on or key-off, the system software configures the chip to platform One of the first options for in-field testing is BIST specific operating conditions, e.g. clock frequencies, power & mechanisms: LBIST and MBIST. MBIST has a proven track voltage settings, coverage target. The testing conditions and record of getting comprehensive coverage of memory test application sequence is flexible and can be updated over structures with low test latency, whereas for LBIST, we cannot the product life cycle. tell the same. The XLBIST test patterns require minimal test- data, but these non-deterministic patterns, in general, do not The high-level IST operational sequence is illustrated in yield high test coverage on complex SOCs, especially under Fig. 3. Custom designed HW controllers execute MBIST, constraints of low latency and strict power budgets.
Recommended publications
  • NVIDIA Launches Tegra X1 Mobile Super Chip
    NVIDIA Launches Tegra X1 Mobile Super Chip Maxwell GPU Architecture Delivers First Teraflops Mobile Processor, Powering Deep Learning and Computer Vision Applications NVIDIA today unveiled Tegra® X1, its next-generation mobile super chip with over one teraflops of processing power – delivering capabilities that open the door to unprecedented graphics and sophisticated deep learning and computer vision applications. Tegra X1 is built on the same NVIDIA Maxwell™ GPU architecture rolled out only months ago for the world's top-performing gaming graphics card, the GeForce® GTX 980. The 256-core Tegra X1 provides twice the performance of its predecessor, the Tegra K1, which is based on the previous-generation Kepler™ architecture and debuted at last year's Consumer Electronics Show. Tegra processors are built for embedded products, mobile devices, autonomous machines and automotive applications. Tegra X1 will begin appearing in the first half of the year. It will be featured in the newly announced NVIDIA DRIVE™ car computers. DRIVE PX is an auto-pilot computing platform that can process video from up to 12 onboard cameras to run capabilities providing Surround-Vision, for a seamless 360-degree view around the car, and Auto-Valet, for true self-parking. DRIVE CX is a complete cockpit platform designed to power the advanced graphics required across the increasing number of screens used for digital clusters, infotainment, head-up displays, virtual mirrors and rear-seat entertainment. "We see a future of autonomous cars, robots and drones that see and learn, with seeming intelligence that is hard to imagine," said Jen-Hsun Huang, CEO and co-founder, NVIDIA.
    [Show full text]
  • Co-Optimizing Performance and Memory Footprint Via Integrated CPU/GPU Memory Management, an Implementation on Autonomous Driving Platform
    Co-Optimizing Performance and Memory Footprint Via Integrated CPU/GPU Memory Management, an Implementation on Autonomous Driving Platform Soroush Bateni*, Zhendong Wang*, Yuankun Zhu, Yang Hu, and Cong Liu The University of Texas at Dallas Abstract—Cutting-edge embedded system applications, such as launches the OpenVINO toolkit for the edge-based deep self-driving cars and unmanned drone software, are reliant on learning inference on its integrated HD GPUs [4]. integrated CPU/GPU platforms for their DNNs-driven workload, Despite the advantages in SWaP features presented by the such as perception and other highly parallel components. In this work, we set out to explore the hidden performance im- integrated CPU/GPU architecture, our community still lacks plication of GPU memory management methods of integrated an in-depth understanding of the architectural and system CPU/GPU architecture. Through a series of experiments on behaviors of integrated GPU when emerging autonomous and micro-benchmarks and real-world workloads, we find that the edge intelligence workloads are executed, particularly in multi- performance under different memory management methods may tasking fashion. Specifically, in this paper we set out to explore vary according to application characteristics. Based on this observation, we develop a performance model that can predict the performance implications exposed by various GPU memory system overhead for each memory management method based management (MM) methods of the integrated CPU/GPU on application characteristics. Guided by the performance model, architecture. The reason we focus on the performance impacts we further propose a runtime scheduler. By conducting per-task of GPU MM methods are two-fold.
    [Show full text]
  • A Low-Cost Deep Neural Network-Based Autonomous Car
    DeepPicar: A Low-cost Deep Neural Network-based Autonomous Car Michael G. Bechtely, Elise McEllhineyy, Minje Kim?, Heechul Yuny y University of Kansas, USA. fmbechtel, elisemmc, [email protected] ? Indiana University, USA. [email protected] Abstract—We present DeepPicar, a low-cost deep neural net- task may be directly linked to the safety of the vehicle. This work based autonomous car platform. DeepPicar is a small scale requires a high computing capacity as well as the means to replication of a real self-driving car called DAVE-2 by NVIDIA. guaranteeing the timings. On the other hand, the computing DAVE-2 uses a deep convolutional neural network (CNN), which takes images from a front-facing camera as input and produces hardware platform must also satisfy cost, size, weight, and car steering angles as output. DeepPicar uses the same net- power constraints, which require a highly efficient computing work architecture—9 layers, 27 million connections and 250K platform. These two conflicting requirements complicate the parameters—and can drive itself in real-time using a web camera platform selection process as observed in [25]. and a Raspberry Pi 3 quad-core platform. Using DeepPicar, we To understand what kind of computing hardware is needed analyze the Pi 3’s computing capabilities to support end-to-end deep learning based real-time control of autonomous vehicles. for AI workloads, we need a testbed and realistic workloads. We also systematically compare other contemporary embedded While using a real car-based testbed would be most ideal, it computing platforms using the DeepPicar’s CNN-based real-time is not only highly expensive, but also poses serious safety control workload.
    [Show full text]
  • Developing & Deploying Autonomous Driving
    DEVELOPING & DEPLOYING AUTONOMOUS DRIVING APPLICATIONS WITH THE NVIDIA DRIVE PX PLATFORM Shri Sundaram, Product Manager, DRIVE PX Platform DRIVE PX: AV Development Platform AV Developers: DRIVE PX as your tool AV HW/SW Ecosystem: DRIVE PX as your platform to reach developers 2 NVIDIA DRIVE PX Open AV Computing Platform for the Transportation Industry Powerful and scalable AV computer Deep Neural Network, Sensor Fusion and Computing Extensive I/O to interface with wide range of sensors and vehicle networks An open SW stack Level 3 to Level 5; ASIL-D functional safety 3 DRIVE PX DRIVING AV AI DRIVE Platform Engagements 400 350 300 250 Launched CES 2015 200 150 Spike in AV AI engagements after 100 50 we powered on discrete GPU 0 FY18 Q1 FY18 Q3 More than doubled in last 6 months Plus >145 AV Startups on NVIDIA DRIVE Source: NVIDIA statistics 4 AV DEVELOPMENT Path from Idea to Production IDEA DEVELOPMENT PROTOTYPE PRODUCTION Develop Test Deploy Perception Feature development Safety hardening OBJECTIVE Mapping/Localization Validation Performance tuning Path Planning SW upgrades Combination/More… PC PC DRIVE Platform TOOL Automotive Sensors Production SW OTA framework Scalable compute with discrete GPUs Ecosystem of sensors + other HW/SW peripherals TensorRT, CUDA, Open Source Frameworks 5 Autonomous Vehicle DEVELOPMENT FLOW Application Development 4 Using DRIVE PX Platform Test/Drive 3 1 Data Acquired Curated/Annotated Neural Network Deep Neural From Sensors Training Data Training Network Autonomous Vehicle Applications 2 1 Data Acquisition
    [Show full text]
  • Diseño De Un Prototipo Electrónico Para El Control Automático De La Luz Alta De Un Vehículo Mediante Detección Inteligente De Otros Automóviles.”
    Tecnológico de Costa Rica Escuela Ingeniería Electrónica Proyecto de Graduación “Diseño de un prototipo electrónico para el control automático de la luz alta de un vehículo mediante detección inteligente de otros automóviles.” Informe de Proyecto de Graduación para optar por el título de Ingeniero en Electrónica con el grado académico de Licenciatura Ronald Miranda Arce San Carlos, 2018 2 Declaración de autenticidad Yo, Ronald Miranda Arce, en calidad de estudiante de la carrera de ingeniería Electrónica, declaro que los contenidos de este informe de proyecto de graduación son absolutamente originales, auténticos y de exclusiva responsabilidad legal y académica del autor. Ronald Fernando Miranda Arce Santa Clara, San Carlos, Costa Rica Cédula: 207320032 3 Resumen Se presenta el diseño y prueba de un prototipo electrónico para el control automático de la luz alta de un vehículo mediante la detección inteligente de otros automóviles, de esta forma mejorar la experiencia de manejo y seguridad al conducir en la noche, disminuyendo el riesgo de accidentes por deslumbramiento en las carreteras. Se expone el uso de machine learning (máquina de aprendizaje automático) para el entrenamiento de una red neuronal, que permita el reconocimiento en profundidad de patrones, en este caso identificar el patrón que describe un vehículo cuando se acerca durante la noche. Se entrenó exitosamente una red neuronal capaz de identificar correctamente hasta un 89% de los casos ocurridos en las pruebas realizadas, generando las señales para controlar de forma automática los cambios de luz. 4 Summary The design and testing of an electronic prototype for the automatic control of the vehicle's high light through the intelligent detection of other automobiles is presented.
    [Show full text]
  • Introduction 3 Acknowledgement 3 Problem and Project Statement 3
    Introduction 3 Acknowledgement 3 Problem and Project Statement 3 Operational environment 5 Intended uses and users 5 Assumptions and limitations 6 End Product 7 Specifications and analysis 9 Proposed Design 9 Design Analysis 10 Implementation details 10 Testing process and testing results 11 Placing your work in the context of: 21 • Related products 21 • Related literature If/When needed, you should resort to Appendices. 22 Appendix I – Operation Manual 23 Raspberry PI 3 Model B 23 Nvidia Drive PX2 29 Software Licensing 31 Appendix II: Alternative/ other initial versions of the design 32 1) The DSRC 32 2) The Mobile Wireless Data 32 3) The Arduino & XBEE 32 Appendix III: Other Considerations 34 Appendix IV: Code 35 Introduction 35 External Libraries 35 Native Libraries 35 Gather Component Information 35 Finding and Initializing Devices 36 Initialize The GPS 37 Parsing and Transmission 37 Introduction As part of our senior design we had to create the means for the communication between two vehicles. The information that had to be communicated was the latitude, longitude coordinates, and the time. For this we have come up with several solutions throughout our design and testing process. We looked into DSRC, Cellular Communication, Raspberry Pi’s over a LAN network, and Xbee transceivers. All these are viable options and several can complement the others pretty well. We will have more details in following sections. Acknowledgement First off, we would like to formally thank Dr. Hegde for guidance on our project and the insightful advice on how to approach and overcome different obstacles of our progress. Also we would like to thank Vishal as our project manager who made sure we stuck to our milestones and meeting with us every week to make sure we were working towards our goals.
    [Show full text]
  • Deeprcar: an Autonomous Car Model Student: Bc
    ASSIGNMENT OF MASTER’S THESIS Title: DeepRCar: An Autonomous Car Model Student: Bc. David Ungurean Supervisor: Ing. Zdeněk Buk, Ph.D. Study Programme: Informatics Study Branch: Knowledge Engineering Department: Department of Applied Mathematics Validity: Until the end of winter semester 2019/20 Instructions Search for RC car models suitable for autonomous driving implementation. Focus on models which allow the control software to be run onboard. The autonomous control will be based primarily on visual inputs from an onboard camera. Other sensors such as ultrasonic distance sensors can be also used. Implement the control algorithms using deep neural networks which use the visual information as input and produce control signals for steering and speed control. Design and implement several experiments to test various neural network architectures and image preprocessing methods. References - J. Koutnik, J. Schmidhuber, F. Gomez, Online evolution of deep convolutional network for vision-based RL, SAB 2014: http://people.idsia.ch/ koutnik/papers/koutnik2014sab.pdf - Zheng Wang, Self Driving RC Car: https://zhengludwig.wordpress.com/projects/self-driving-rc-car/ Ing. Karel Klouda, Ph.D. doc. RNDr. Ing. Marcel Jiřina, Ph.D. Head of Department Dean Prague February 16, 2018 Master’s thesis DeepRCar: An Autonomous Car Model Bc. David Ungurean Department of Applied Mathematics Supervisor: Ing. Zdenˇek Buk, Ph.d. May 9, 2018 Acknowledgements First of all, I would like to thank my supervisor Dr. Buk for giving me the chance to explore such an interesting field of machine learning and for always pointing me in the right direction, whenever I was starting to get lost. I am also very grateful to Dr.
    [Show full text]
  • Entertainment Software Association
    Long Comment Regarding a Proposed Exemption Under 17 U.S.C. 1201 [ ] Check here if multimedia evidence is being provided in connection with this comment Item 1. Commenter Information The Entertainment Software Association (“ESA”) represents all of the major platform providers and nearly all of the major video game publishers in the United States.1 It is the U.S. association exclusively dedicated to serving the business and public affairs needs of companies that publish computer and video games for video game consoles, personal computers, and the Internet. Any questions regarding these comments should be directed to: Cory Fox Simon J. Frankel Ehren Reynolds Lindsey L. Tonsager ENTERTAINMENT SOFTWARE ASSOCIATION COVINGTON & BURLING LLP 575 7th Street, NW One Front Street Suite 300 35th Floor Washington, DC 20004 San Francisco, CA 94111 Telephone: (202) 223-2400 Telephone: (415) 591-6000 Facsimile: (202) 223-2401 Facsimile: (415) 591-6091 Item 2. Proposed Class Addressed Proposed Class 19: Jailbreaking—Video Game Consoles Item 3. Overview A. Executive Summary Proposed Class 19 is virtually identical to the video game console “jailbreaking” exemption that the Librarian denied in the last rulemaking proceeding. As in the last proceeding, “the evidentiary record fail[s] to support a finding that the inability to circumvent access controls on video game consoles has, or over the course of the next three years likely would have, a substantial adverse impact on the ability to make noninfringing uses.”2 Proponents offer no more than the same de minimis, hypothetical, 1 See http://www.theesa.com/about-esa/members/ (listing ESA’s members).
    [Show full text]
  • DRIVE PX 2 HANDS-ON NVIDIA Automotive
    DRIVE PX 2 HANDS-ON NVIDIA Automotive Rev. 20170725 Drive PX 2 SDK 4.1.8.0 TABLE OF CONTENT DRIVE PX 2 Overview DRIVE PX 2 Hardware Setup DRIVE PX 2 SDK Installation DRIVE PX 2 Hands-on NVIDIA CONFIDENTIAL — DRIVE PX 2 DEVELOPMENT PLATFORM DRIVE PX 2 OVERVIEW DRIVE PX 2 AutoChauffeur • Scalable from 1 to 4 processors to multiple DRIVE PX 2s • 2x Tegra Parker SoC • 2x Pascal dGPU • 8 TFLOPS • 24 DNN TOPs • Up to 12 cameras, plus LIDAR, radar, ultrasonic sensors • DriveWorks SW/SDK • AI perception • Mapping NVIDIA CONFIDENTIAL — DRIVE PX 2 DEVELOPMENT PLATFORM NVIDIA DRIVE PX 2 BUILT FOR NVIDIA CONFIDENTIAL — DRIVE PX 2 DEVELOPMENT PLATFORM NVIDIA DRIVE PX 2 – SOFTWARE STACK A full stack of rich software components NVIDIA Vibrante Linux & Comprehensive BSP Rich Middleware Filesystem SDK, Samples and more Open GL ES 3.x Ubuntu Open GL 4.x 16.04 CUDA 8.x Yocto X11 EGLStream/EGLOutput Linux K4.4 NVIDIA CONFIDENTIAL — DRIVE PX 2 DEVELOPMENT PLATFORM DRIVE PX 2 HARDWARE SETUP Check out the Quick start guide! Included in your DRIVE PX 2 box NVIDIA CONFIDENTIAL — DRIVE PX 2 DEVELOPMENT PLATFORM Top View DRIVE PX 2 Connectors Front View NVIDIA CONFIDENTIAL — DRIVE PX 2 DEVELOPMENT PLATFORM DRIVE PX 2 Harness Connectors Note: Make sure that the AURIX Flashing switch is in the RUN position NVIDIA CONFIDENTIAL — DRIVE PX 2 DEVELOPMENT PLATFORM Vehicle Harness Cable Step 1 ATTENTION: Do not plug in the power supply to the wall socket unless instructed. a) Connect vehicle harness • Plug the vehicle harness cable to DRIVE PX 2 • Lock the DRIVE PX 2 Vehicle Harness b) Connect the Power Supply to the harness cable NVIDIA CONFIDENTIAL — DRIVE PX 2 DEVELOPMENT PLATFORM Connecting the Cameras If you don’t have GMSL cameras, proceed to Step 3 Connect your GMSL Camera (e.g.
    [Show full text]
  • Self Driving RC Car Using Behavioral Cloning
    Self Driving RC Car using Behavioral Cloning 1. 2. 3. Aliasgar​ Haji, Priyam​ Shah, Srinivas​ Bijoor ​ ​ 1 S​ tudent, IT Dept., K. J. Somaiya College Of Engineering, Mumbai. 2 S​ tudent, Computer Dept., K. J. Somaiya College Of Engineering, Mumbai. 3 S​ tudent, Startup School India, K. J. Somaiya College Of Engineering, Mumbai. ---------------------------------------------------------------------***--------------------------------------------------------------------- Abstract - Self Driving Car technology is a vehicle that Convolutional Neural Networks as they are made up of ​ guides itself without human conduction. The first truly neurons that have learnable weights and biases are similar autonomous cars appeared in the 1980s with projects to ordinary Neural Networks. [1] Each neuron receives funded by DARPA( Defense Advance Research Project some inputs, performs a dot product and optionally Agency ). Since then a lot has changed with the follows it with a non-linearity activation function. The improvements in the fields of Computer Vision and Machine overall functionality of the network is like having an image Learning. We have used the concept of behavioral cloning to on one end and class as an output on the other end. They convert a normal RC model car into an autonomous car still have a loss function like Logarithmic loss/ Softmax on using Deep Learning technology. the last (fully-connected) layer and all ideas developed for learning regular Neural Networks still apply. In simple Key Words: Self Driving Car, Behavioral Cloning. Deep words, images are sent to the input side and the output ​ Learning, Convolutional Neural Networks, Raspberry Pi, side to classify them into classes based on a probability Radio-controlled (RC) car score, whether the input image applied is a cat or a dog or a rat and so on.
    [Show full text]
  • A Leader in AI Computing~
    Special Feature 1: NVIDIA Special Feature NVIDIA ~A Leader in AI Computing~ Born in Silicon Valley in 1993, NVIDIA is the inventor of the GPU and a world leader in visual computing. Along with the NVIDIA solutions that continue to elevate its reputation as an 'AI computing company', we also offer a wide variety of solutions including autonomous driving, the latest vehicle technology from NVIDIA and NEXTY Electronics. Who is NVIDIA? Since NVIDIA's establishment in 1993, the GPUs conceived by the company have driven growth in the PC gaming market, redefined modern computer graphics, and revolutionized parallel computing. In more recent years, GPU-based deep learning has become a catalyst Established: 1993 for modern AI and is paving the way to a new age of computing. Founder: Jensen Huang These GPUs are being used as the backbone of a diverse array of Address: Santa Clara, California, U.S. computers, robotics, and autonomous vehicles that are aware of― Number of employees: Approximately 12,000 and understand―the world around them. NVIDIA is no longer just a semiconductor supplier. Today, NVIDIA's reputation as an 'AI Sales volume: FY 2018, USD 9.71 billion (over 1 trillion yen) computing company' is making another leap forward. "Endeavor" is Nvidia's new offi ce building located Jensen Huang, founder and CEO, is NVIDIA's Released in August 2018, the GeForce RTX in Santa Clara, the heart of Silicon Valley. Please iconic leader. He was selected as 'Best- realized real-time ray tracing with the newest stop by if you are ever in Silicon Valley.
    [Show full text]
  • Open Source Software License Information
    Open Source Software license information This document contains an open source software license information for the product VACUU·SELECT. The product VACUU·SELECT contains open source components which are licensed under the applicable open source licenses. The applicable open source licenses are listed below. The open source software licenses are granted by the respective right holders directly. The open source licenses prevail all other license information with regard to the respective open source software components contained in the product. Modifications of our programs which are linked to LGPL libraries are permitted for the customer's own use and reverse engineering for debugging such modifications. However, forwarding the information acquired during reverse engineering or debugging to third parties is prohibited. Furthermore, it is prohibited to distribute modified versions of our programs. In any case, the warranty for the product VACUU·SELECT will expire, as long as the customer cannot prove that the defect would also occur without these modification. WARRANTY DISCLAIMER THE OPEN SOURCE SOFTWARE IN THIS PRODUCT IS DISTRIBUTED IN THE HOPE THAT IT WILL BE USEFUL, BUT WITHOUT ANY WARRANTY, WITHOUT EVEN THE IMPLIED WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. See the applicable licenses for more details. Written offer This product VACUU·SELECT contains software components that are licensed by the holder of the rights as free software, or Open Source software, under GNU General Public License, Versions 2 and 3, or GNU Lesser General Public License, Versions 2.1, or GNU Library General Public License, Version 2, respectively. The source code for these software components can be obtained from us on a data carrier (e.g.
    [Show full text]