Portable Stimulus: What's Coming in 1.1

Total Page:16

File Type:pdf, Size:1020Kb

Portable Stimulus: What's Coming in 1.1 Portable Stimulus: What’s Coming in 1.1 and What it Means For You Portable Stimulus Working Group PSS 1.1 Tutorial Agenda • What is PSS Introduction • Tom Fitzpatrick, • Abstract DMA model in PSS 1.0 Mentor, a Siemens Business Memory • The problem • Prabhat Gupta, AMD Allocation • New PSS concepts Higher-Level • The problem • Matan Vax, Scenarios • New constructs Cadence Design Systems • The problem • Karthick Gururaj, HSI Realization • New concepts and constructs Vayavya Labs System-Level • Portability • Hillel Miller, Synopsys Usage • Complex scenarios • Summary Special Thanks to: Conclusion • What’s next Dave Kelf, Breker Verification Systems Josh Rensch, Semifore 2 The Need for Verification Abstraction Test content authoring represents major proportion of development SIMULATION Disconnected cross-process methods Test Content • Block EMULATION • UVM tests laborious, error-prone • SoC FPGA PROTO • Hard to hit corner-cases with C tests • Post-Silicon • Disconnected diagnostic creation IP BLOCK SUBSYSTEM FULL SYSTEM Test portability, reuse, scaling, maintenance all problematic 3 Key Aspects of Portable Stimulus Capture pure Partial scenario Composable Formal Automated test Target multiple test intent description scenarios representation generation platforms of test space Separate test intent from implementation High-coverage test generation across the verification process with much less effort 4 PSS Improves Individual Verification Phases IP BLOCK SUB-SYSTEM FULL SYSTEM Create block-level (UVM) tests & Easily model system-level Generate software processor tests sequences based on operations, reuse modular block and IO transactions from common scenario intent level tests scenario model Easily compose complex, Drive hard-to-predict corner-case Flush out system functions with concurrent, high-coverage tests tests to flush out design operation software-driven tests, while avoiding processor complexity 5 PSS Generalized Tool Flow DSL DSL Compiler Gen-time or Run-time Constraint Test Scenario model Solver Solved Model Generator + Constraints C++ Compile / Compile Link / Run Link UVM Transaction Sync C-test Sequences Sequences PSS Abstract AXIAXI VIPVIP TB Scenario AXI CPUVIP Model DMAC DMAC UART UART DDR UART UART DDR VIP MEM VIP MEM UVM Testbench SoC Testbench 6 Active PSWG Participants 7 Key Additions to PSS 1.1 Modeling Improvements • Better Reusable Content Capture • Storage Allocation Test Realization • Register Space Definition • Reusable Abstract Procedural Layer Programming Enhancements • Templates • Collection Types 8 What is a Portable Stimulus Model? The • What does Abstract Model it do The • How does Realization it do what Layer it does 9 The Parts of a PSS Model flow objects describe resources represent actions describe behavior communication chan pieces of the system action b2s_a { dbuf input dbuf din; b2s dstr output dstr dout; rand int in [1..100] size; struct dat_s { rand bit[31:0] addr; constraint din.size == size; rand int size; } lock channel_r chan; } buffer dbuf : dat_s { rand bit[12:0] key; actions may have data fields } actions may have constraints stream dstr : dat_s { actions may claim resources rand bit dir; } 10 Data Flow Objects Imply Scheduling bufo_a activity describes schedule action actdemo_a { dbuf b2s_a b2s; s bufo_a bufo; b2s dstr stri_a stream object buffer objects imply parallel stri_a stri; imply sequential activity { struct dat_s { bufo; rand bit[31:0] addr; parallel { rand int size; b2s; } stri; } buffer dbuf : dat_s { bind bufo.dout b2s.din; rand bit[12:0] key; bind b2s.dout stri.din; } } } stream dstr : dat_s { rand bit dir; constraints on bufo.dout } apply to b2s.din 11 Activities Can Define Flexible Scenarios bufo b2s s2b b2b action sched_a { bufo_a bufo; s2b_a s2b; ax_a ax; b2s_a b2s; b2b_a b2b; my_a a1,a2; b2a activity { Directed-Random bufo; select { a1 a2 Scenario parallel { b2s; s2b; } a1 a2 b2b; a2 a1 } b2a; schedule { a1; a2; } ax ax; 123456 distinct control paths } } 12 Activities Can Define Flexible Scenarios bufo dbuf dbuf dstr b2s s2b b2b action sched_a { dbuf dbuf bufo_a bufo; s2b_a s2b; ax_a ax; b2s_a b2s; b2b_a b2b; my_a a1,a2; b2a activity { db2 db2 bufo; select { a1 a2 Explicit binding parallel { b2s; s2b; } db2 a1 a2 db2 gets complicated b2b; a2 a1 } b2a; db2 db2 schedule { a1; a2; } ax ax; } } 13 Flow Objects Managed via Pools bufo pool dbuf dbpool_p; bind dbpool_p *; pool db2 dbp2_p; dbpool bind dbp2_p *; dbufdbufdbuf dstr b2s s2b b2b action sched_a { bufo_a bufo; s2b_a s2b; ax_a ax; b2s_a b2s; b2b_a b2b; my_a a1,a2; b2a dbp2 activity { db2 db2db2 bufo; select { a1 a2 parallel { b2s; s2b; } a1 a2 b2b; a2 a1 } b2a; schedule { a1; a2; } ax ax; } } 14 Resources Add Dependencies pool [NUM] chan_r chan_p; bind chan_p *; Each resource in a Resources may be pool is unique action sched_a { locked or shared ... chan_p activity { schedule { a1; a2; } resource chan_r : base_r { chan ax; ... } } } action a1_a { a1 a2 ... a1 a2 lock chan_r chan; a2 a1 } action a2_a { Can't run in parallel ax ... if both require the lock chan_r chan; same resource } 15 Components Group Model Elements component pss_top { Default top-level name comp1_c c1; comp2_c c2; pool [NUM] chan_r chan_p; pss_top bind chan_p *; pool dbuf dbuf_p; bind dbuf_p *; comp1_c comp2_c chan_p Pool binding is pool db2 db2_p; bufo chan hierarchical bind db2_p *; b2s } b2b a1 dbpool dbp2 dbufdbuf db2 s2b a2 dbufdbuf db2db2 component comp2_c { my_a a1, a2; b2a ax ax_a ax; activity { ... Components can instantiate } subcomponents } 16 So What's the Point? Activity defines critical behaviors • May define partial specification • Tools will infer additional elements to complete the scenario Other parts of the model define how behaviors interact • Instantiated components define available actions • Flow object bindings constrain inference choices • Resources constrain scheduling options 17 component pss_top { Quick DMA Example dma_c dma; util_c util; pool dbuf dbuf_p; bind dbuf_p *; action m2mtest_a { activity { do dma_c::mem2mem_xfer; do util_c::check_data; pss_top } util_c dma_c m2mtest } } chan_p component dma_c { gen chan resource channel_r {}; dbuf_p pool [NUM] channel_r chan_pool; dbufdbufdbuf bind chan_pool *; check m2m action mem2mem_xfer { input data_buff src_buff; output data_buff dst_buff; ... lock channel_r chan; } } 18 component pss_top { Quick DMA Example dma_c dma; util_c util; dbuf pool dbuf dbuf_p; bind dbuf_p *; gen m2m action m2mtest_a { activity { dbuf dbuf do dma_c::mem2mem_xfer; gen m2m do util_c::check_data; } } } gen m2m dbuf_p m2m dbufdbufdbuf check 19 Quick DMA Example dbuf gen m2m dbuf dbuf gen m2m gen m2m gen m2m gen m2m PSS 1.1 Provides for Memory Allocation Must make sure that m2m m2m data buffers don't overlap in memory check check 20 The Rubber Meets the Road The Abstract Model must be implemented on different targets Atomic Actions → target code • Target code modeled in exec blocks Generator assembles target code according to Activity schedule 21 Target Template Exec Blocks Define SV extend action mem2mem_xfer { implementation exec SV """ begin m2m_xfer xseq = m2m_xfer::type_id::create("xseq"); xseq.item.src == {{src_buff.addr}}; xseq.item.dst == {{dst_buff.addr}}; Define C xseq.item.size == {{size}}; extend action mem2mem_xfer { implementation xseq.start(m_env.m_agent.m_seqr); exec C """ end Pass PSS args SRC_REG.write({{src_buff.addr}}); """ DST_REG.write({{dst_buff.addr}}); } SZ_REG.write({{size}}); CSR_REG.write(GO); """ } 22 Procedural Interface Exec Blocks package func_pkg { function void m2m_xfer(bit[31:0]src, bit[31:0]dst, Single method bit[6:0]size); prototype } extend action mem2mem_xfer { import func_pkg::*; exec body { m2m_xfer(src_buff.addr, dst_buff.addr, size); } } PSS1.1 adds an Must provide implementations abstract procedural layer in both SV and C 23 Thank You Please Continue with Part 2 Thank you to our Accellera Global Sponsors Portable Stimulus: What’s Coming In 1.1 And What It Means For You Part 2: MEMORY ALLOCATION Prabhat Gupta, AMD Memory Allocation Topics Problem Concepts Application Issues with memory allocation Address space Address space operations Address space region Packed struct Allocation claim Descriptor chain Address space handle 2 Portability and Controllability Problem src_addr = mem_mgr.allocate(size, properties); dst_addr = mem_mgr.allocate(size, properties); // Program descriptor in memory // ... // Program IP IP testbench write_reg(CTRL_REG, descriptor) mem_mgr.deallocate(src_addr); Need to manage memory resource mem_mgr.deallocate(dst_addr); HOW TO ESTABLISH INTERESTING RELATIONSHIP WILL TEST RUN OUT OF IS MEMORY MANAGER BETWEEN SOURCE AND MEMORY PORTABLE DESTINATION 3 Portability and Controllability Problem // Manage two different memory manager addr1 = IP1_mem_mgr.allocate(size, properties); addr2 = IP2_mem_mgr.allocate(size, properties); //-------------------- OR ---------------------- // Sub-system // Create unified memory manager Reconcile memory management addr1 = unified_mem_mgr.allocate(size, properties); of different IP addr2 = unified_mem_mgr.allocate(size, properties); ESTABLISH INTERESTING ARE MEM MANAGERS IS MEMORY MANAGER RELATIONSHIP BETWEEN COMPATIBLE? PORTABLE? ADDR1 AND ADDR2 4 Model Allocation – Portability Problem // Processor based tests // hardcode addresses Uint64_t addr = 0x123456; // Simple mem manager at runtime SoC and post-silicon addr = malloc(0x1000); Reuse stimulus that allocate and // How to create test that would hit all memory access memory controller? // IP tests need to be re-written HARDCODE ADDRESS OR IS MEMORY
Recommended publications
  • Arm Cortex-M System Design Kit Technical Reference Manual
    Arm® Cortex®-M System Design Kit Revision: r1p1 Technical Reference Manual Copyright © 2011, 2013, 2017 Arm Limited (or its affiliates). All rights reserved. ARM DDI 0479D (ID110617) Arm Cortex-M System Design Kit Technical Reference Manual Copyright © 2011, 2013, 2017 Arm Limited (or its affiliates). All rights reserved. Release Information The following changes have been made to this document: Change history Date Issue Confidentiality Change 14 March 2011 A Non-Confidential First release for r0p0 16 June 2011 B Non-Confidential Second release for r0p0 19 April 2013 C Non-Confidential First release for r1p0 31 October 2017 D Non-Confidential First release for r1p1 Proprietary Notice This document is protected by copyright and other related rights and the practice or implementation of the information contained in this document may be protected by one or more patents or pending patent applications. No part of this document may be reproduced in any form by any means without the express prior written permission of Arm. No license, express or implied, by estoppel or otherwise to any intellectual property rights is granted by this document unless specifically stated. Your access to the information in this document is conditional upon your acceptance that you will not use or permit others to use the information for the purposes of determining whether implementations infringe any third party patents. THIS DOCUMENT IS PROVIDED “AS IS”. ARM PROVIDES NO REPRESENTATIONS AND NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY, SATISFACTORY QUALITY, NON-INFRINGEMENT OR FITNESS FOR A PARTICULAR PURPOSE WITH RESPECT TO THE DOCUMENT.
    [Show full text]
  • Workshop on Post-Silicon Debug: Technologies, Methodologies, and Best Practices
    Wisam Kadry – IBM Research, Haifa 7 June 2012 Workshop on Post-silicon Debug: Technologies, Methodologies, and Best Practices © 2012 IBM Corporation DAC 2012, Post-silicon Debug Workshop Thanks to Mr. Amir Nahir IBM Research – Haifa, Israel Received his BSc in computer science from Technion, IIT in 2005, and is currently pursuing his PhD there. He has been a research staff member at the IBM Research Labs in Haifa since 2006, and has spent most of his time leading the development of Threadmill – a post-silicon functional validation exerciser. Since the beginning of 2011, Amir manages the Post-Silicon Validation and Design Automation Group 2 © 2012 IBM Corporation DAC 2012, Post-silicon Debug Workshop Agenda Session I (09:00-10:30) Wisam Kadry - IBM Haifa Research Lab., Haifa, Israel Kevin Reick - IBM Corp., Austin, TX Subhasish Mitra - Stanford Univ., Stanford, CA David Erikson - Advanced Micro Devices, Fort Collins, CO Bradley Quinton - Tektronix, Inc., Vancouver, BC, Canada Break (10:30-11:00) Session II (11:00-12:30) Alan Hu - Univ. of British Columbia, Vancouver, BC, Canada Keshavan Tiruvallur - Intel Corp., Portland, OR Nagib Hakim - Intel Corp., Santa Clara, CA Valeria Bertacco - Univ. of Michigan, Ann Arbor, MI Sharad Kumar - Freescale Semiconductor, Inc., Noida, India Lunch (12:30-13:30) Panel (13:30-15:00) Moderator: Harry Foster - Mentor Graphics Corp., Plano, TX 3 © 2012 IBM Corporation DAC 2012, Post-silicon Debug Workshop More complex chips 4 © 2012 IBM Corporation DAC 2012, Post-silicon Debug Workshop Observe 5 © 2012 IBM
    [Show full text]
  • UPF 1.0, UPF 2.0, UPF 2.1, UPF 3.0, and Now UPF 3.1: the Big Q “Which Is the Right Standard for My Design”?
    UPF 1.0, UPF 2.0, UPF 2.1, UPF 3.0, and now UPF 3.1: The big Q “Which is the Right Standard for My Design”? Madhur Bhargava, Mentor, A Siemens Business ([email protected]) 1 Agenda • Introduction • Evolution of UPF • Challenges in Migration • Backward Compatibility • What’s new in UPF 3.1 • Semantic difference b/w standards • UPF design Guidelines • Conclusion 2 Introduction • Power Management & Verification Complexity – Complex & energy aware chips – Maximize battery life – Requiring sophisticated power management • Power Gating, Multi Voltage, DVFS, Biasing • Affect design functionality • IPs using own power management posing integration challenges – Need for power verification • HDL not equipped, Power formats share burden • Unified Power Format – Define power management – Based on Tcl – Provide HDL Interface – Information Model to capture processed data 3 Evolution of UPF • UPF 1.0 was defined by Accellera • UPF 3.0 – Focused on adding power intent to HDL – Several new capabilities added – Relatively simple concepts and commands – Updated existing concepts, viz. power • UPF 2.0 defined by IEEE states – Backward compatible with UPF 1.0 • UPF 3.1 – latest standard – Supports IP development, refinement – New commands for simulation control • UPF 2.1 – Clarification of semantics – Clarifies and enhances UPF 2.0 features – Adds a few new capabilities UPF 3.1 UPF 3.0 UPF 2.1 UPF UPF 2.0 1.0 4 New Challenges • Five UPF standards – Compatibility, Differences & Migration challenges • Starting a new design: Which UPF version to choose
    [Show full text]
  • Ieee 1076-2008 Vhdl-200X
    IEEE 1076-2008 VHDL-200X By Jim Lewis, SynthWorks VHDL Training [email protected] SynthWorks IEEE 1076-2008 O IEEE VASG - VHDL-200X effort O Started in 2003 and made good technical progress O However, no $$$ for LRM editing O Accellera VHDL TSC O Took over in Fall 2005, O Prioritized IEEE proposals, O Finalized LRM text, O Completed Accellera standard in July 2006 O Vendors implemented some features and provided feedback O In Spring 2008, Accellera forwarded standard to IEEE VASG for IEEE standardization. * VHDL-2008 * Approved in September by IEEE REVCOM 2 Copyright © SynthWorks 2008 SynthWorks IEEE 1076-2008 O Biggest Language change since 1076-1993 O PSL O Expressions in port maps O IP Protection via Encryption O Read out ports O VHDL Procedural Interface - VHPI O Conditional and Selected O Type Generics assignment in sequential code O Generics on Packages O hwrite, owrite, … hread, oread O Arrays with unconstrained arrays O to_string, to_hstring, … O Records with unconstrained arrays O Sized bit string literals O Fixed Point Packages O Unary Reduction Operators O Floating Point Packages O Array/Scalar Logic Operators O Hierarchical references of signals O Slices in array aggregates O Process(all) O Stop and Finish O Simplified Case Statements O Context Declarations O Don't Care in a Case Statement O Std_logic_1164 Updates O Conditional Expression Updates O Numeric_Std Updates O Numeric_Std_Unsigned 3 Copyright © SynthWorks 2008 SynthWorks VHDL-2008 Big Ticket Items PSL O PSL has been incorporated directly into VHDL O Vunit, Vmode,
    [Show full text]
  • IEEE SA/Accellera Partnership
    Corporate Program Case Study IEEE-SA/Accellera Partnership Relationship Between the IEEE-SA Corporate Program and Accellera Helps Design Automation Technology Gain Reach and Recognition Since 2000, Accellera, a consortium of companies in the electronic design automation field, has been developing and promoting use of design and verification specifications for semiconductors, systems, and design-tool companies. Ten of those documents have been finalized and issued in collaboration with the IEEE Standards Association (IEEE-SA) as IEEE standards. “Working with IEEE-SA brings these standards world-wide recognition and reach,” says Yatin Trivedi, Accellera’s treasurer and a long-time member of its board of directors. “IEEE-SA is recognized globally as a leading standards-development organization for a broad range of technical areas. Standards approved or ratified by IEEE are considered ‘good for you’ without question. Accellera has a good reputation, but not on the same scale as IEEE or IEEE-SA. IEEE-SA has a vast, international member base, as well as relationships with organizations such as IEC and other international and national standards bodies. These factors make IEEE standards based on Accellera documents acceptable to a broad, world-wide audience.” “And people know and expect that IEEE’s standards development process is rigorous, open, fair, peer-reviewed, and comprehensive,” adds Trivedi. The material that organizations like Accellera submit is viewed as a strong starting contribution to an IEEE entity standards working group (WG). Industry organizations submit specifications to IEEE with the full understanding that they’ll no longer have the control they once had over the document’s content--but the standards that result are more useful.
    [Show full text]
  • Dot / Faa /Tc-16/57
    DOT/FAA/TC-16/57 Commercial Off-The-Shelf Federal Aviation Administration William J. Hughes Technical Center Airborne Electronic Hardware Aviation Research Division Atlantic City International Airport Issues and Emerging Solutions: New Jersey 08405 Authority for Expenditure No. 75 Report September 2017 Final Report This document is available to the U.S. public through the National Technical Information Services (NTIS), Springfield, Virginia 22161. This document is also available from the Federal Aviation Administration William J. Hughes Technical Center at actlibrary.tc.faa.gov. U.S. Department of Transportation Federal Aviation Administration NOTICE This document is disseminated under the sponsorship of the U.S. Department of Transportation in the interest of information exchange. The U.S. Government assumes no liability for the contents or use thereof. The U.S. Government does not endorse products or manufacturers. Trade or manufacturers’ names appear herein solely because they are considered essential to the objective of this report. The findings and conclusions in this report are those of the author(s) and do not necessarily represent the views of the funding agency. This document does not constitute FAA policy. Consult the FAA sponsoring organization listed on the Technical Documentation page as to its use. This report is available at the Federal Aviation Administration William J. Hughes Technical Center’s Full-Text Technical Reports page: actlibrary.tc.faa.gov in Adobe Acrobat portable document format (PDF). Technical Report Documentation Page 1. Report No. 2. Government Accession No. 3. Recipient's Catalog No. DOT/FAA/TC-16/57 4. Title and Subtitle 5. Report Date COMMERCIAL OFF-THE-SHELF AIRBORNE ELECTRONIC HARDWARE ISSUES AND September 2017 EMERGING SOLUTIONS: AUTHORIZATION FOR EXPENDITURE NO.
    [Show full text]
  • Portable Test and Stimulus Standard Version 1.0
    Portable Test and Stimulus Standard Version 1.0 June 2018 Copyright © 2017 - 2018 Accellera. All rights reserved. Portable Test and Stimulus 1.0 Language Reference Manual — June 2018 Abstract: The definition of the language syntax, C++ library API, and accompanying semantics for the spec- ification of verification intent and behaviors reusable across multiple target platforms and allowing for the automation of test generation is provided. This standard provides a declarative environment designed for ab- stract behavioral description using actions, their inputs, outputs, and resource dependencies, and their com- position into use cases including data and control flows. These use cases capture verification intent that can be analyzed to produce a wide range of possible legal scenarios for multiple execution platforms. It also in- cludes a preliminary mechanism to capture the programmer’s view of a peripheral device, independent of the underlying platform, further enhancing portability. Keywords: behavioral model, constrained randomization, functional verification, hardware-software inter- face, portability, PSS, test generation. Copyright © 2017 - 2018 Accellera. All rights reserved. ii Portable Test and Stimulus 1.0 Language Reference Manual — June 2018 Notices Accellera Systems Initiative (Accellera) Standards documents are developed within Accellera and the Technical Committee of Accellera. Accellera develops its standards through a consensus development pro- cess, approved by its members and board of directors, which brings together volunteers representing varied viewpoints and interests to achieve the final product. Volunteers are members of Accellera and serve without compensation. While Accellera administers the process and establishes rules to promote fairness in the con- sensus development process, Accellera does not independently evaluate, test, or verify the accuracy of any of the information contained in its standards.
    [Show full text]
  • Portable Test and Stimulus: the Next Level of Verification Productivity Is Here
    Portable Test and Stimulus: The Next Level of Verification Productivity is Here On behalf of the Accellera Portable Stimulus Working Group Sharon Rosenberg, Cadence Design Systems Pradeep Salla, Mentor Graphics © Accellera Systems Initiative 1 Agenda • Introduction: What and Why? • “Hello World”: Language Concepts • Block-to-System Example © Accellera Systems Initiative 2 It's an SOC World • Design complexity continues to increase – Outstripping verification productivity SIMULATION • System-level state space too big for STIMULUS effective UVM constrained-random EMULATION • Multiple verification platforms • Need to reuse Test Intent FPGA PROTO – Higher abstraction IP BLOCK SUBSYSTEM FULL SYSTEM – Block to system – Different design versions DVCon Europe 2018 Portable Stimulus Tutorial, Accellera PSWG 3 The Portable Stimulus Journey PSPWG PSWG 2014 2015 2017 2018 Portable Stimulus Working Group Participants AMD IBM OneSpin AMIQ EDA Intel Qualcomm Analog Devices Mentor Semifore Breker National Instruments Synopsys Cadence NVIDIA Texas Instruments Cisco NXP Semiconductors Vayavya Labs Cypress Semiconductor DVCon Europe 2018 Portable Stimulus Tutorial, Accellera PSWG 4 Reuse of Test Intent Across Platforms/Users • Single specification of test intent is critical Portable Stimulus • Constrain and randomize at the Scenario Level by capturing: – interactions – dependencies UVM C – resource contention • Abstraction lets tools IP BLOCK SUBSYSTEM FULL SYSTEM automate test generation – Multiple targets – Target-specific SIMULATION EMULATION FPGA PROTO customization DVCon Europe 2018 Portable Stimulus Tutorial, Accellera PSWG 5 The Advantages of a Declarative Specification . Most SoC tests are directed . Declarative tests let the tool do the work . Manually determining . Explore all possible options turn-by-turn directions . Easy to optimize . Hard to account for new stops . Guided by preferences .
    [Show full text]
  • An ARM Cortex-M0 for Energy Harvesting Systems: a Novel Application of UPF with Synopsys’ Galaxy Platform
    An ARM Cortex-M0 for Energy Harvesting Systems: A Novel Application of UPF with Synopsys’ Galaxy Platform Jatin Mistry James Myers School of Electronics and Computer Science University of Southampton, UK www.ecs.soton.ac.uk and ARM Ltd Cambridge, UK www.arm.com ABSTRACT In energy harvesting systems, energy is effectively infinite but output power is severely limited. In this paper we first present a novel state retention power gating technique, called Sub-Clock Power Gating, which addresses this ultra-low power budget. It works in synergy with voltage and frequency scaling and power gates combinational logic within the clock cycle to reduce ac- tive power. Secondly, we describe how the technique was implemented on an ARM Cortex-M0™ microprocessor for fabrication and discuss our experience of using UPF with Synopsys' Galaxy Platform to achieve the required power gating. Finally, silicon measured results are given. Table of Contents 1 Introduction .............................................................................................................................. 3 2 Design Challenge ..................................................................................................................... 4 2.1 SUB-CLOCK POWER GATING TECHNIQUE ........................................................................... 4 2.2 TEST CHIP ........................................................................................................................... 6 3 Design Flow ............................................................................................................................
    [Show full text]
  • Security Annotation for Electronic Design Integration (SA-EDI)
    July 2021 Security Annotation for Electronic Design Integration Standard v1.0 Security Annotation for Electronic Design Integration Standard July 2021 Rev 1.0 July 2021 Security Annotation for Electronic Design Integration Standard v1.0 Abstract: The standard is collateral-centric with a focus on security concerns; it applies to electrical designs that are integrated into other circuits. The standard defines a methodology that (1) identifies elements, such as input or output ports, that can influence the behavior of a critical section within the design and (2) associates known security weaknesses based on the type of design and/or critical section. The methodology uses data objects, which are both human and machine readable, to capture security relevant information through the architectural and design phase of the electrical design to be consumed by an Integrator for their product lifecycle. The standard is independent of existing standards and is not part of the electrical design itself. Keywords: Security, RTL, attack surface, threat modeling, security weakness, mitigation, hardware, circuit design, integrated circuit, SoC, ASIC, IP July 2021 Security Annotation for Electronic Design Integration Standard v1.0 Notices Accellera Systems Initiative (Accellera) Standards documents are developed within Accellera and the Technical Committee of Accellera. Accellera develops its standards through a consensus development process, approved by its members and board of directors, which brings together volunteers representing varied viewpoints and interests to achieve the final product. Volunteers are members of Accellera and serve without compensation. While Accellera administers the process and establishes rules to promote fairness in the consensus development process, Accellera does not independently evaluate, test, or verify the accuracy of any of the information contained in its standards.
    [Show full text]
  • Iec 61691-1-1
    This is a preview - click here to buy the full publication IEC 61691-1-1 Edition 2.0 2011-05 INTERNATIONAL IEEE Std 1076™ STANDARD Behavioural languages – Part 1-1: VHDL Language Reference Manual INTERNATIONAL ELECTROTECHNICAL COMMISSION PRICE CODE XH ICS 25.040, 35.060 ISBN 978-2-88912-440-4 This is a preview - click here to buy the full publication This is a preview - click here to buy the full publication - i - IEC 61691-1-1:2011(E) IEEE Std 1076-2008 Contents 1. Overview of this standard .................................................................................................................... 1 1.1 Scope............................................................................................................................................ 1 1.2 Purpose......................................................................................................................................... 1 1.3 Structure and terminology of this standard.................................................................................. 2 2. Normative references........................................................................................................................... 5 3. Design entities and configurations....................................................................................................... 7 3.1 General......................................................................................................................................... 7 3.2 Entity declarations ......................................................................................................................
    [Show full text]
  • Portable Test and Stimulus Standard
    1 Portable Test and Stimulus Standard 2 Version 2.0 Draft for Public Review 3 4 5 6 7 8 9 November 18, 2020 Copyright © 2020 Accellera. All rights reserved. Portable Test and Stimulus Standard 2.0 Draft for Public Review — November 18, 2020 1 Abstract: The definition of the language syntax, C++ library API, and accompanying semantics for the 2 specification of verification intent and behaviors reusable across multiple target platforms and allowing for 3 the automation of test generation is provided. This standard provides a declarative environment designed for 4 abstract behavioral description using actions, their inputs, outputs, and resource dependencies, and their 5 composition into use cases including data and control flows. These use cases capture verification intent that 6 can be analyzed to produce a wide range of possible legal scenarios for multiple execution platforms. It also 7 includes a preliminary mechanism to capture the programmer’s view of a peripheral device, independent of 8 the underlying platform, further enhancing portability. 9 Keywords: behavioral model, constrained randomization, functional verification, hardware-software inter- 10 face, portability, PSS, test generation. Copyright © 2020 Accellera. All rights reserved. 2 Portable Test and Stimulus Standard 2.0 Draft for Public Review — November 18, 2020 1 Notices 2 Accellera Systems Initiative (Accellera) Standards documents are developed within Accellera and the 3 Technical Committee of Accellera. Accellera develops its standards through a consensus development pro- 4 cess, approved by its members and board of directors, which brings together volunteers representing varied 5 viewpoints and interests to achieve the final product. Volunteers are members of Accellera and serve with- 6 out compensation.
    [Show full text]