Symbolic QED Pre-silicon Verification for Automotive Microcontroller Cores: Industrial Case Study

We present an industrial case study that demonstrates the practicality and effectiveness of Symbolic Quick Error Detection (Symbolic QED) in detecting logic design flaws (logic bugs) during pre-silicon verification. Our study focuses on several microcontroller core designs (~1,800 flip-flops, ~70,000 logic gates) that have been extensively verified using an industrial verification flow and used for various commercial automotive products. The results of our study are as follows: 1. Symbolic QED detected all logic bugs in the designs that were detected by the industrial verification flow (which includes various flavors of simulation-based verification and formal verification). 2. Symbolic QED detected additional logic bugs that were not recorded as detected by the industrial verification flow. (These additional bugs were also perhaps detected by the industrial verification flow.) 3. Symbolic QED enables significant design productivity improvements: (a) 8X improved (i.e., reduced) verification effort for a new design (8 person-weeks for Symbolic QED vs. 17 person-months using the industrial verification flow). (b) 60X improved verification effort for subsequent designs (2 person-days for Symbolic QED vs. 4-7 person-months using the industrial verification flow). (c) Quick bug detection (runtime of 20 seconds or less), together with short counterexamples (10 or fewer instructions) for quick debug, using Symbolic QED

High-Integrity Performance Monitoring Units in Automotive Chips for Reliable Timing V&V

As software continues to control more system-critical functions in cars, its timing is becoming an integral element in functional safety. Timing validation and verification (V&V) assesses softwares end-to-end timing measurements against given budgets. The advent of multicore processors with massive resource sharing reduces the significance of end-to-end execution times for timing V&V and requires reasoning on (worst-case) access delays on contention-prone hardware resources. While Performance Monitoring Units (PMU) support this finer-grained reasoning, their design has never been a prime consideration in high-performance processors - where automotive-chips PMU implementations descend from - since PMU does not directly affect performance or reliability. To meet PMUs instrumental importance for timing V&V, we advocate for PMUs in automotive chips that explicitly track activities related to worst-case (rather than average) softwares behavior, are recognized as an ISO-26262 mandatory high-integrity hardware service, and are accompanied with detailed documentation that enables their effective use to derive reliable timing estimatesThis work has also been partially supported by the Spanish Ministry of Economy and Competitiveness (MINECO) under grant TIN2015-65316-P and the HiPEAC Network of Excellence. Jaume Abella has been partially supported by the MINECO under Ramon y Cajal postdoctoral fellowship number RYC-2013-14717. Enrico Mezzet has been partially supported by the Spanish Ministry of Economy and Competitiveness under Juan de la Cierva-Incorporación postdoctoral fellowship number IJCI-2016- 27396.Peer ReviewedPostprint (author's final draft

Plug & Test at System Level via Testable TLM Primitives

With the evolution of Electronic System Level (ESL) design methodologies, we are experiencing an extensive use of Transaction-Level Modeling (TLM). TLM is a high-level approach to modeling digital systems where details of the communication among modules are separated from the those of the implementation of functional units. This paper represents a first step toward the automatic insertion of testing capabilities at the transaction level by definition of testable TLM primitives. The use of testable TLM primitives should help designers to easily get testable transaction level descriptions implementing what we call a "Plug & Test" design methodology. The proposed approach is intended to work both with hardware and software implementations. In particular, in this paper we will focus on the design of a testable FIFO communication channel to show how designers are given the freedom of trading-off complexity, testability levels, and cos

Automatic instantiation of abstract tests on specific configurations for large critical control systems

Computer-based control systems have grown in size, complexity, distribution and criticality. In this paper a methodology is presented to perform an abstract testing of such large control systems in an efficient way: an abstract test is specified directly from system functional requirements and has to be instantiated in more test runs to cover a specific configuration, comprising any number of control entities (sensors, actuators and logic processes). Such a process is usually performed by hand for each installation of the control system, requiring a considerable time effort and being an error prone verification activity. To automate a safe passage from abstract tests, related to the so called generic software application, to any specific installation, an algorithm is provided, starting from a reference architecture and a state-based behavioural model of the control software. The presented approach has been applied to a railway interlocking system, demonstrating its feasibility and effectiveness in several years of testing experience

Space biology initiative program definition review. Trade study 2: Prototype utilization in the development of space biology hardware

The objective was to define the factors which space flight hardware developers and planners should consider when determining: (1) the number of hardware units required to support program; (2) design level of the units; and (3) most efficient means of utilization of the units. The analysis considered technology risk, maintainability, reliability, and safety design requirements for achieving the delivery of highest quality flight hardware. Relative cost impacts of the utilization of prototyping were identified. The development of Space Biology Initiative research hardware will involve intertwined hardware/software activities. Experience has shown that software development can be an expensive portion of a system design program. While software prototyping could imply the development of a significantly different end item, an operational system prototype must be considered to be a combination of software and hardware. Hundreds of factors were identified that could be considered in determining the quantity and types of prototypes that should be constructed. In developing the decision models, these factors were combined and reduced by approximately ten-to-one in order to develop a manageable structure based on the major determining factors. The Baseline SBI hardware list of Appendix D was examined and reviewed in detail; however, from the facts available it was impossible to identify the exact types and quantities of prototypes required for each of these items. Although the factors that must be considered could be enumerated for each of these pieces of equipment, the exact status and state of development of the equipment is variable and uncertain at this time

Research and technology goals and objectives for Integrated Vehicle Health Management (IVHM)

Integrated Vehicle Health Management (IVHM) is defined herein as the capability to efficiently perform checkout, testing, and monitoring of space transportation vehicles, subsystems, and components before, during, and after operational This includes the ability to perform timely status determination, diagnostics, and prognostics. IVHM must support fault-tolerant response including system/subsystem reconfiguration to prevent catastrophic failures; and IVHM must support the planning and scheduling of post-operational maintenance. The purpose of this document is to establish the rationale for IVHM and IVHM research and technology planning, and to develop technical goals and objectives. This document is prepared to provide a broad overview of IVHM for technology and advanced development activities and, more specifically, to provide a planning reference from an avionics viewpoint under the OAST Transportation Technology Program Strategic Plan

Evolution of shuttle avionics redundancy management/fault tolerance

The challenge of providing redundancy management (RM) and fault tolerance to meet the Shuttle Program requirements of fail operational/fail safe for the avionics systems was complicated by the critical program constraints of weight, cost, and schedule. The basic and sometimes false effectivity of less than pure RM designs is addressed. Evolution of the multiple input selection filter (the heart of the RM function) is discussed with emphasis on the subtle interactions of the flight control system that were found to be potentially catastrophic. Several other general RM development problems are discussed, with particular emphasis on the inertial measurement unit RM, indicative of the complexity of managing that three string system and its critical interfaces with the guidance and control systems