New Advanced Techniques for Reset Domain Crossing (RDC) Analysis

March 14th @ 8:00 AM US/Pacific


  1. Body

    Author: Matthew Ballance - Mentor, A Siemens Business Introduction: The functionality of today’s SoC designs is increasingly driven and directed by software, and much of that software is tightly coupled with behavior of the hardware that it controls. Test software is a critical component of verification environments at the SoC level, but bringing software into the verification process as early as the IP level can be beneficial both in terms of finding Hw/Sw interface bugs earlier and making test creation at the SoC level more productive. There are two key challenges to making software a key and consistent element of the verification process from IP to SoC level. First, the test-automation capabilities present in IP, subsystem, and SoC environments is very different. IP-level environments (and to some extent subsystem-level environments) benefit from constrained-random stimulus generation. In contrast, SoC environments typically provide no automated means of test creation. Secondly, the way that IP-specific content interacts with the design and with other pieces of IP-specific test content is quite different at IP, subsystem, and SoC level. At IP level, test content only deals with a single IP block and uses SystemVerilog mechanisms for threading and access IP registers via verification IP APIs or transactions. At SoC, the test scenario must deal with multiple IPs, and use either bare metal or OS mechanisms for threading.These differences in test-creation capabilities and mechanisms for software to interact with hardware pose a significant obstacle to reusing software-driven test content from IP to SoC level. This paper describes how the emerging Accellera Portable Stimulus Specification standard enables automated creation of test content from IP to SoC level, and how a hardware abstraction layer for test software simplifies integration of test content. Example: The examples in this paper will primarily be based around the Wishbone DMA IP from opencores.org [1]. A block diagram of this IP is shown in Figure 1. The DMA engine provides 31 DMA channels which can perform memoryto-memory transfers, as well as transfers controlled by hardware handshake signals. Detailed IP-level verification of this block, as any other, would be performed in a UVM environment using directed, constrained-random, and other methods, to exercise the implementation to confirm that it conforms to the design specification. Thinking ahead to the verification needs at subsystem and SoC level, developing some basic firmware for exercising the IP as a part of the IP verification process would greatly help when a system containing the DMA engine is assembled. View & Download: Read the entire Managing and Automating HW/SW Tests from IP to SoC technical paper.