https://semiengineering.com/do-necessary-tools-exist-for-risc-v-verification/ [semi_logo] Search for: [ ] [Search] Subscribe * Home * Systems & Design * Low Power - High Performance * Manufacturing, Packaging & Materials * Test, Measurement & Analytics * Auto, Security & Pervasive Computing * Special Reports * Business & Startups * Jobs * Knowledge Center * Technical Papers + Home'; + AI/ML/DL + Architectures + Automotive + Communication/Data Movement + Design & Verification + Lithography + Manufacturing + Materials + Memory + Optoelectronics / Photonics + Packaging + Power & Performance + Quantum + Security + Test & Analytics + Transistors + Z-End Applications * Events & Webinars + Events + Webinars * Videos & Research + Videos + Industry Research * Newsletters & Store + Newsletters + Store * MENU + Home + Special Reports + Systems & Design + Low Power-High Performance + Manufacturing, Packaging & Materials + Test, Measurement & Analytics + Auto, Security & Pervasive Computing + Knowledge Center + Videos + Startup Corner + Business & Startups + Jobs + Technical Papers + Events + Webinars + Industry Research + Newsletters + Store + Special Reports Home > Low Power-High Performance > Do Necessary Tools Exist For RISC-V Verification? Low Power-High Performance Do Necessary Tools Exist For RISC-V Verification? Existing tools can be used for RISC-V, but they may not be the most effective or efficient. What else is needed? March 30th, 2023 - By: Brian Bailey popularity Semiconductor Engineering sat down to discuss the verification of RISC-V processors with Pete Hardee, group director for product management at Cadence; Mike Eftimakis, vice president for strategy and ecosystem at Codasip; Simon Davidmann, founder and CEO of Imperas Software; Sven Beyer, program manager for processor verification at Siemens EDA; Kiran Vittal, senior director of alliances partner marketing at Synopsys; Dave Kelf, CEO of Breker Verification, and Hieu Tran, president and CTO of Viosoft Corporation. What follows are excerpts of that conversation. To view part one of this discussion, click here. SE: What does a RISC-V verification flow look like? Kelf: We see the verification of processors as a stack of activities, but there's lots of loopbacks in that stack. A lot of companies treat conformance to the ISA as a separate activity. They'll do a 'Hello World' test as a first stack to make sure things are up and running, then they will run as many conformance tests as they can. They try and match the ISA, and then they start testing the micro-architecture. A lot of people stop there. What we see happen is as they run the conformance tests, they may appear to get conformance, and then they start writing the micro architecture tests, find some things that are broken and realize that conforming to an ISA is a lot more complex than just making sure the instruction run properly. As they go further up the stack, they get into, 'Can we verify the cores as they relate to the rest of the system? Can we boot an OS on it? Does it have the necessary performance? Can they profile the design to make sure the performance is correct and start those validation activities to reveal more bugs in the verification?' When we're testing a regular ASIC or regular core, you can run through all the verification activities, get really good coverage, and then do the validation on the end. You often don't have to go back to verification. With these processors, you do. You have to go backward and forward through that verification stack all the time. This really slows you down, and the whole verification of that architecture. The golden reference model is becoming critically important. The Imperas models are recognized as state-of-the-art industry standard models by a lot of people. We've been working with those models. Bringing in a really solid core reference model that you can rely on is becoming a critical thing. You can test the micro-architecture, you can test some of the interaction with the rest of the system against that core model, and really getting a clearer picture of what's going on in the actual processor. Tran: I have some doubt as to whether the idea of a golden reference model is viable when it comes to RISC-V. If you go back to the day when Unix came on the scene, there were a handful of suppliers that had their own implementations. You had Solaris, SVR4, AIX from IBM, and so on. The idea of achieving a common executable that can run across the board, from all these different Unix/Linux implementations was just not possible. Every vendor is incentivized to build value add and custom extensions that will give them differentiation versus the other. We see that here with RISC-V. Unlike with x86 and with Arm, where the majority of the implementations are under the Intel or Arm umbrella, you literally have hundreds of different institutions and organization building their own RISC-V implementation. When you talk about things like vector extension, where the spec is so large, many implementers have decided to implement only a subset of that extension. How would you be able to create a common golden reference model to be able to verify execution against this variety of implementation? Second, when we talk about verification and validation of execution, you have to go further up the stack into the tool chain and the operating system. Take, for instance, the vector extensions. Every vendor that I've spoken to, and work with, has their own compiler, their own LLVM implementation in support of their vector extension. And none of them is compatible with the others. So you can take LLVM compiler from vendor A, generate code, and it wouldn't be very efficient for the implementation from vendor B. From that perspective, I'm skeptical as to whether it's even possible to come up with a common model that can give you a baseline against these variations. Davidmann: I clearly disagree with that comment. RISC-V is a complete nightmare because there are so many options. This is one of the challenges for compatibility and compliance. There are so many configuration options, which are all legal, and the big question is, how do you create a reference model? But it's worse than that. Every three months, there's a new version of each extension. In our simulator, it is a complete reference. It is completely configurable for any of the independent subsets, but also the versions. We have 11 versions of the vectors, 4 of which have gone to silicon. I don't think there's a problem with this, as long as it's designed and architected correctly. RISC-V offers the opportunity to do things better. We can't live with the old way of having just one Arm or one Intel. That isn't going to work. If the old world was you can have a reference model which does one thing, the new world is you have a reference model that can do 100 things. And that's where we are going. Otherwise, RISC-V will never fulfill its destiny. We have to solve those problems. Hardee: We know processor implementation and the devil is in the details. We certainly agree with you that SystemVerilog, Verilog, is much better at capturing those implementation details. But you've got to verify that implementation against a higher-level model that is capturing the intent. That is not a single reference model. It could be many, or a standardized way of creating a reference model for those many variants that we're talking about. Davidmann: Five or six years ago, I was part of the RISC-V International organization that looked into formal and ended up choosing SAIL as the language for building a golden reference model. What we got wrong is that SAIL is not very configurable. It is great for one architecture. For Arm, it is fantastic. They have this whole flow from a definition, all the way through correct-by-construction, all the way down, coming from a formal description, and it's brilliant. The challenge for RISC-V is it has this infinite configurability by design. And so there is a real challenge in the modeling of that in SAIL. That's why Imperas went for a dynamic model. Vittal: RISC-V is being adopted by almost every company out there. Even the leading semiconductor vendors are doing RISC-V designs, as are many startups. But the key is the being able to have a successful verification plan where you have very high-quality stimulus to achieve your coverage targets. Both verification and debug go hand in hand. Hardware/software debug, stepping through the code to simultaneous look at the problems, is key. Going back to the flexibility of the architecture, that's providing challenges -- and where the opportunity lies for all of us. Innovative solutions are being developed. There's a lot of collaboration happening between the RISC-V vendors and EDA tool companies, as well as other EDA partners and so on. Kelf: There are companies that have figured this out to a certain extent. The infinite configurability of RISC-V, all these things are true. But at the end of the day, Arm and Intel have solved the verification of their somewhat less configurable processors. They have a flow, or a series of complex flows, and those flows include a bunch of different activities. Arm uses a lot of formal tools, a lot of different things to do it. A good place to start might be looking at what some of these guys are doing in their flows, and trying to automate some of it. You need something that can be used by all of the folks trying to do RISC-V processors and collaborating together -- collaborating to come up with these more generalized flows, and see if we can standardize some of this stuff. And not in the sense of a proper standard, but a de facto standard way of verifying a RISC-V processors that does work across the industry and creates some real compatibility, not just instruction-set compatibility. SE: A couple of you have mentioned that we do need new tools, new flows. What is missing today? How are we going to work out what the things are that somebody needs to provide? Kelf: There are a lot of folks doing RISC-V processors internally, and they are starting anew. They're learning how to do processor verification. Companies like Codasip have brought in people with a lot of experience and expertise from places like Arm and Intel and others, who do understand what to do. So we see some of these companies now producing flows where they are considering issues such as, 'Can the processor support full coherency? Does it work across the rest of the system? Can the security instructions, like the PMP (physical memory protection) instructions inside RISC-V operate correctly?' Davidmann: When we started with RISC-V five or six years ago, there was nothing specific for RISC-V. We had the Verilog simulator, you had some formal stuff, you could write some properties. There was GCC, and you could run it and debug it. That was it. What we've seen over the last five years is that people have evolved a lot of tools and technology, which have been derived by learning how processors are verified in proprietary ways. And we've been trying to make that more public. We've been trying to understand how it's been done in Intel and Arm, and the types of technologies that have been used. We've been working within OpenHW, where I look after the verification task. It is about open-source silicon with industrial quality. It is not about using open-source tools. What we've learned over the last few years is a lot of different techniques, a lot of different ways to do things, and we've evolved and built tools like this configurable reference model, like technology which does the verification for you, like functional coverage that we've been evolving into ways for trying to check how well Linux runs. People have been building test generators. Other companies have been building formal tools, like the OneSpin Technologies out of Siemens that are focused on RISC-V. There have been three or four other companies that have been involved in the formal side of things. What we're seeing is there are some specific RISC-V technologies being built, there's some verification IPs being built, and more and more, the EDA vendors are learning the methodologies people need, and they're building the tools. But it's early days. We are only five years into the real use of RISC-V, and probably a couple of years into the commercial bit of it. There was five years of academic stuff before. And companies like Codasip, and the other commercial vendors of silicon IP, are really evolving and building the technologies internally for verification. We're trying to help build them as commercial tools, as are some of the EDA vendors. We're at the beginning of this new age of RISC-V verification technologies. Vittal: The mainstream processor developers know what they're doing. They've done x86 and Arm before. They are adopting RISC-V and they know exactly what to do. They're also leveraging the open-source community. For the mainstream, when you look at RISC-V, it's being adopted by the mainstream designers. That's where they need a methodology. That's what is missing. Synopsys offers everything that is required to do verification and validation, both software and hardware. We have VIPs, we have formal techniques, we have data path, but what is missing is a methodology. And the methodology comes with expertise of the processor verification engineer and other experts. Eftimakis: That's the secret sauce of IP vendors. That's what we do internally. Davidmann: Companies like Imperas are trying to make that more public. It might have been proprietary IP before. We give a 90-minute tutorial on a RISC-V processor verification reference flow. It lays out all the different bits you need, and what technologies are available today and what is not available. We talk about test generators based around commercial technology. Vittal: We have something similar called a cookbook, which our customers can download from the portal that uses an open-source core. That can take you through the whole verification process. Beyer: It's key to add new tooling, but we need the very configurable RISC-V reference model, and to make that available to the tooling and the flow. Then we can build something around it so that people without deep experience can get to the point of having decent verification experience for the RISC-V cores. Eftimakis: We have integrated tools into our flow, including Imperas and OneSpin. That's something that we see as a benefit of being part of RISC-V, because we can leverage these tools that have been built for the ecosystem and integrate them into our verification flow. We can combine comparison with models, simulations, formal verification, assertions, etc. That's a benefit that we gained from being part of this ecosystem. Tags: ARM Breker Verification Cadence Codasip EDA Imperas Software Intel Mentor OneSpin Technologies OpenHW RISC-V Siemens EDA Synopsys Unix verification Viosoft Brian Bailey Brian Bailey (all posts) Brian Bailey is Technology Editor/EDA for Semiconductor Engineering. Leave a Reply Cancel reply [ ] [ ] [ ] [ ] [ ] [ ] [ ] Comment * [ ] Name*[ ] (Note: This name will be displayed publicly) Email*[ ] (This will not be displayed publicly) [Post Comment] [ ] [ ] [ ] [ ] [ ] [ ] [ ] D[ ] Technical Papers * Combination of AI Techniques To Find The Best Ways to Place Transistors on Silicon Chips March 30, 2023 by Technical Paper Link * Covert Channel Between the CPU and An FPGA By Modulating The Usage of the Power Distribution Network March 30, 2023 by Technical Paper Link * Large Area Process For Atomically Thin 2D Semiconductor, Using Scalable ALD March 30, 2023 by Technical Paper Link * CXL Memory: Detailed Characterization Analysis Using Micro-Benchmarks And Real Applications (UIUC, Intel Labs) March 30, 2023 by Technical Paper Link * Hardware Based Monitoring For Zero Trust Environments March 26, 2023 by Technical Paper Link Trending Articles True 3D Is Much Tougher Than 2.5D While terms often are used interchangeably, they are very different technologies with different challenges. by Brian Bailey Mini-Consortia Forming Around Chiplets Commercial chiplet marketplaces are still on the distant horizon, but companies are getting an early start with more limited partnerships. by Ed Sperling Uneven Circuit Aging Becoming A Bigger Problem The industry is gaining ground in understanding how aging affects reliability, but more variables make it harder to fix. by Ann Mutschler Do Necessary Tools Exist For RISC-V Verification? Existing tools can be used for RISC-V, but they may not be the most effective or efficient. What else is needed? by Brian Bailey Tech Forecast: Fab Processes To Watch Through 2040 Key pivot and innovation points in semiconductor manufacturing. by Laura Peters Knowledge Centers Entities, people and technologies explored Learn More Related Articles Will Floating Point 8 Solve AI/ML Overhead? Less precision equals lower power, but standards are required to make this work. by Karen Heyman Choosing The Correct High-Bandwidth Memory New applications require a deep understanding of the tradeoffs for different types of DRAM. by Ann Mutschler Startup Funding: November 2022 127 startups raise $2.6B; data center connectivity, quantum computing, and batteries draw big funding. by Jesse Allen Uneven Circuit Aging Becoming A Bigger Problem The industry is gaining ground in understanding how aging affects reliability, but more variables make it harder to fix. by Ann Mutschler Do Necessary Tools Exist For RISC-V Verification? Existing tools can be used for RISC-V, but they may not be the most effective or efficient. What else is needed? by Brian Bailey IC Stresses Affect Reliability At Advanced Nodes Thermal mismatch in heterogeneous designs, different use cases, can impact everything from accelerated aging to warpage and system failures. by Ann Mutschler Chiplets Taking Root As Silicon-Proven Hard IP Technical and business challenges persist, but momentum is building. by Ann Mutschler What Makes RISC-V Verification Unique? The verification of a processor is a lot more complex than a comparably-sized ASIC, and RISC-V processors take this to another layer of complexity. by Brian Bailey * Sponsors [Siemens-lo] [se_sp_ramb] [se_sp_syno] [1_se_sp_ne] [se_sp_new-] [se_sp_cade] [1_mixel] [iis_85mm_p] [cliosoft_2] [qu] * [INS::INS] Advertise with us * [INS::INS] Advertise with us * [INS::INS] Advertise with us * Newsletter Signup Popular Tags 2.5D 5G 7nm advanced packaging AI ANSYS Apple Applied Materials ARM automotive business Cadence EDA eSilicon EUV finFETs GlobalFoundries Google IBM imec Intel IoT IP Lam Research machine learning memory Mentor Mentor Graphics MIT Moore's Law Nvidia NXP Qualcomm Rambus Samsung security SEMI Siemens Siemens EDA software Sonics Synopsys TSMC UMC verification Recent Comments * Ron Lavallee on RISC-V Disrupting EDA * Brian Bailey on RISC-V Disrupting EDA * DRB on RISC-V Disrupting EDA * Katherine Derbyshire on New Challenges Emerge With High-NA EUV * Ed Korczynski on New Challenges Emerge With High-NA EUV * chip99monk on Panel Tackles Chiplet Packaging Challenges * Fred Chen on New Challenges Emerge With High-NA EUV * IanD on Self-Heating Issues Spread * Allen Rasafar on Metrology Strategies For 2nm Processes * Allen Rasafar on Metrology Strategies For 2nm Processes * M. Fortner on Metrology Strategies For 2nm Processes * Charles R on What Causes Semiconductor Aging? * Rey on Tomorrow's Semiconductor Workforce * Arpan Bhattacherjee on Leveraging Chip Data To Improve Productivity * Eric Esteve on Considering Semiconductor Implementation Aspects Early During Network-on-Chip Development * Nitin Shanker on Hybrid Bonding Basics: What Is Hybrid Bonding? * Anne Meixner on Hunting For Hardware-Related Errors In Data Centers * Jan Hoppe on Hunting For Hardware-Related Errors In Data Centers * Karen Heyman on Will Floating Point 8 Solve AI/ML Overhead? * Steve Nordquist on 3-Terminal Thermal Transistor With Thermal Measurements For The Switching And Amplification * Christopher Wendt on Collaboration Widens Among Big Chip Companies * Tanj Bennett on Chip Design Shifts As Fundamental Laws Run Out Of Steam * Tanj Bennett on Chip Design Shifts As Fundamental Laws Run Out Of Steam * Harshita Gupta on Challenges With Stacking Memory On Logic * Arpan Bhattacherjee on The Path To Known Good Interconnects * Xavier on Metrology Options Increase As Device Needs Shift * Leonard Tsai on Will Floating Point 8 Solve AI/ML Overhead? * WZIS on Arbitrary Precision DNN Accelerator Controlled by a RISC-V CPU (Ecole Polytechnique Montreal, IBM, Mila, CMC) * Rama Chaganti on Growing System Complexity Drives More IP Reuse * TL on How Secure Are RISC-V Chips? * Frank on The Good And Bad Of Bi-Directional Charging * Sandeep Dixit on The Good And Bad Of Bi-Directional Charging * Hertz on How Secure Are RISC-V Chips? * Andrew on How Software Utilizes Cores * Asaf Jivilik on Cybord: Electronic Component Traceability * Santosh Kurinec on Where All The Semiconductor Investments Are Going * dick freebird on Designing And Securing Chips For Outer Space * Akshay on Designing And Securing Chips For Outer Space * Raj on Is UCIe Really Universal? * Andrew TAM on How Software Utilizes Cores * Riko R on Designing For Multiple Die * Dan Ganousis on RISC-V Pushes Into The Mainstream * Ivan Batinic on IC Stresses Affect Reliability At Advanced Nodes * Giovanni Lostumbo on A Power-First Approach * Mohammed Zakir Hussain on Embracing the Challenges Of Cybersecurity In Automotive Applications * Laura Peters on Week In Review: Manufacturing, Test * Aiv on Week In Review: Manufacturing, Test * Ross Youngblood on High Voltage Testing Races Ahead * Mark Olivas on Cybord: Electronic Component Traceability * Karl Stevens on The Drive Toward Virtual Prototypes * Ron Lavallee on The Politics Of Standards * Denis McCarthy on Hot Trends In Semiconductor Thermal Management * Tom Smith on Are We Too Hard On Artificial Intelligence For Autonomous Driving? * Maya F on Where All The Semiconductor Investments Are Going * Saikatm on Balancing Power And Heat In Advanced Chip Designs * Doug L. on Holistic 3D-IC Interposer Analysis In Product Designs * Andy Deng on Post-Quantum And Pre-Quantum Security Issues Grow * John Dunn on Post-Quantum And Pre-Quantum Security Issues Grow * madmax2069 on Chip Design Shifts As Fundamental Laws Run Out Of Steam * Matthew Slyman on Chip Design Shifts As Fundamental Laws Run Out Of Steam * Douglas MacIntyre on Chip Design Shifts As Fundamental Laws Run Out Of Steam * Jose on Universal Verification Methodology Running Out Of Steam * Zhengji Lu on Moving From AMBA ACE to CHI For Coherency * John Bennice on A Power-First Approach * [email protected] on Chip Design Shifts As Fundamental Laws Run Out Of Steam * Matthew on Chip Design Shifts As Fundamental Laws Run Out Of Steam * Karthik Krishnamoorthy on AI-Powered Verification * CPlusPlus4Ever on Chip Design Shifts As Fundamental Laws Run Out Of Steam * Douglas on Chip Design Shifts As Fundamental Laws Run Out Of Steam * Bowie Poag on Chip Design Shifts As Fundamental Laws Run Out Of Steam * Eugene on Startup Funding: October 2022 * Wesley Sung on Fan-Out And Packaging Challenges * Hong Xiao on Chip Design Shifts As Fundamental Laws Run Out Of Steam * Robert Anderson on Chip Design Shifts As Fundamental Laws Run Out Of Steam * Mike Frank on A Power-First Approach * William Ruby on A Power-First Approach * Peter C Salmon on A Power-First Approach * Dr. Dev Gupta on Which Foundry Is In The Lead? It Depends. * Steve Hoover on A Power-First Approach * DylanP on Which Foundry Is In The Lead? It Depends. * Asaf Jivilik on Cybord: Electronic Component Traceability * Chris @ crossPORt on Foundational Changes In Chip Architectures * Mark Olivas on Cybord: Electronic Component Traceability * Ari ben David on Constraints On The Electricity Grid * Jeff Zika on Auto Safety Tech Adds New IC Design Challenges * Jung Yoon on Foundational Changes In Chip Architectures * Schrodinger's Cat's Advocate on Foundational Changes In Chip Architectures * RigTig on Foundational Changes In Chip Architectures * Steve on Foundational Changes In Chip Architectures * Prashant Purwar on Why Mask Blanks Are Critical * Mostafa Abdelgawwad on Radar For Automotive: How Far Can A Radar See? * yieldWerx on Managing Wafer Retest * John Horner on A Brief History of Test * Lakshm J on ESD Requirements Are Changing * Dr. Dev Gupta on Improving Redistribution Layers for Fan-out Packages And SiPs * Akarsh on Better PMIC Design Using Multi-Physics Simulation * Todd Bermensolo on Reducing Schedule Slips With Automated Post-Route Verification Of SerDes High Speed Serial Links * Laur Rizzatti on Why Geofencing Will Enable L5 * Raj Raghuram on The Complex Art Of Handling S-Parameters * Stevo on CHIPS Act: U.S. Releases New Implementation Strategy * Santosh Kurinec on Quantum Research Bits: Sept. 12 * Lewis Sternberg on ML And UVM Share Same Flaws * Roger Stierman on L5 Adoption Hinges on 5G/6G * Marcel on MicroLEDs Move Toward Commercialization * Ragu Athreya on Is There A Limit To The Number of Layers In 3D-NAND? * Brian Bailey on AI Power Consumption Exploding * David S on AI Power Consumption Exploding * Mike Cormack on Cryogenic CMOS Becomes Cool * Lance Harvie on New Uses For AI In Chips * Doc R on Electronics And Its Role In Climate Change * Magdy Abadir on Is Standardization Required For Security? * guest on How Overlay Keeps Pace With EUV Patterning * Santosh Kurinec on Week In Review, Manufacturing, Test * sravani on Timing Library LVF Validation For Production Design Flows * Dr. F on A Sputnik Moment For Chips * Gary Dagastine on A Sputnik Moment For Chips * Mike Sottak on A Sputnik Moment For Chips * Robert Pearson on A Sputnik Moment For Chips * Raye E. Ward on A Sputnik Moment For Chips * Michael Williams on A Look Inside RF Design Week In Review: Semiconductor Ma... Gregory Haley Week In Review: Design, Low Power Susan Rambo [se_logo_bl] About * About us * Contact us * Advertising on SemiEng * Newsletter SignUp Navigation * Homepage * Special Reports * Systems & Design * Low Power-High Perf * Manufacturing, Packaging & Materials * Test, Measurement & Analytics * Auto, Security & Pervasive Computing * Videos * Jobs * Technical Papers * Events * Webinars * Knowledge Centers * Industry Research * Business & Startups * Newsletters * Store Connect With Us * Facebook * Twitter @semiEngineering * LinkedIn * YouTube Copyright (c)2013-2023 SMG | Terms of Service | Privacy Policy This site uses cookies. By continuing to use our website, you consent to our Cookies Policy ACCEPT Manage consent Close Privacy Overview This website uses cookies to improve your experience while you navigate through the website. The cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. We do not sell any personal information. By continuing to use our website, you consent to our Privacy Policy. If you access other websites using the links provided, please be aware they may have their own privacy policies, and we do not accept any responsibility or liability for these policies or for any personal data which may be collected through these sites. Please check these policies before you submit any personal information to these sites. Necessary [*] Necessary Always Enabled Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information. Non-necessary [*] Non-necessary Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website. SAVE & ACCEPT Quantcast