https://semiengineering.com/high-level-synthesis-for-risc-v/ [semi_logo] Search for: [ ] [Search] Subscribe Zhong Wen English * Home * Systems & Design * Low Power - High Performance * Manufacturing, Packaging & Materials * Test, Measurement & Analytics * Auto, Security & Pervasive Computing * Special Reports * Videos * Jobs * Knowledge Center * Events & Webinars + Events + Webinars * Research & Startups + Industry Research + Startup Corner * 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 + Jobs + Events + Webinars + Industry Research + Special Reports Home > Systems & Design > High-Level Synthesis For RISC-V Systems & Design High-Level Synthesis For RISC-V Abstraction is the key to custom processor design and verification, but defining the right language and tool flow is a work in progress. October 28th, 2021 - By: Brian Bailey popularity High-quality RISC-V implementations are becoming more numerous, but it is the extensibility of the architecture that is driving a lot of design activity. The challenge is designing and implementing custom processors without having to re-implement them every time at the register transfer level (RTL). There are two types of high-level synthesis (HLS) that need to be considered. The first is generic HLS, which takes a description in C, C++, or SystemC and turns it into RTL. These tools enable you to explore the design space to create an optimal architecture, and this has worked exceedingly well for algorithms that are dataflow-oriented. In fact, the tools have become better at handling control-oriented constructs over time. But can they be used to implement processors? And is there a better way? The other type of HLS is tools dedicated to processors. Extensible processors are not new. Tensilica (Cadence) and ARC (Synopsys) have been enabling users to create customizable processors for a couple of decades, and Arm recently dipped its toe in the water. These tools start with an Architectural Description Language that is designed specifically for processors. The question now is whether these two synthesis technologies can be brought together. The answer isn't entirely clear. HLS may not be applicable to all RISC-V designs. "Are you interested in a standard RISC-V implementation, or are you going for specialization?" asks Gert Goossens, senior director for ASIP tools at Synopsys. "If you're interested in a standard RISC-V implementation, then I'm not sure HLS will provide you much benefit, because you can describe the architecture in RTL and optimize it there. But as soon as you start to look at instruction set extensions it is a different story. Then the question is which extensions are the best for my application domain, and architectural exploration becomes really crucial." There are different levels of architectural optimization. "All HLS tools enable you to do architectural exploration," says Zdenek Prikryl, CTO for Codasip. "Generic HLS solutions are good for doing this for data paths and statically scheduled algorithms, such as image processing. If you are designing a CPU, it is different. We can do much more exploration than you could do at RTL or conventional HLS. In one recent example, we started with the RISC-V baseline and then played with different combinations of extensions. Then we explored custom extension and defined some new instructions. The tests were rerun and the speed-up was more than 50X." "This is the confluence of two technologies that has the potential to be truly transformative in our industry," says Rob Knoth, product management director at Cadence. "Processor design isn't just about maximizing your GHz. You're talking about processors that could be targeted for a very low area. Some could be targeted for extremely low power, some could be targeted at legacy nodes. Processors aren't vanilla. Processors come in 31 flavors, especially when you start thinking about RISC-V, where it is open and customizable. Application-specific processors need tools that are predictable, and they need a tight coupling to the physical world." Assessing extensions is a different level of architectural optimization that involves software. "You need to figure out the 'right' custom instructions for the specific target application so that certain goals can be achieved, be it memory, power, performance, or area," says Sven Beyer, product manager for OneSpin, a Siemens Business. "To do that, high-level models are needed, like virtual prototypes with custom instructions, running software to assess memory usage or performance. Once the custom extension candidates are identified, they need to be implemented in RTL to allow for the final assessment of key performance indicators (KPI). This task is very tedious when manually writing RTL, even if just adding to an existing RTL core, and manually writing independent prototypes. Keeping the models in sync is challenging." More than just hardware Processors are the boundary between hardware and software. They affect each other. "When we look at the RISC-V landscape, the IP landscape, we see a lot of focus on the hardware," says Patrick Verbist, product marketing manager for Synopsys. "Commercial companies and universities are offering different IPs, often putting RTL implementations in the public domain. There is a forest of solutions, each with a strong focus on their RTL implementation. They proclaim that one is better, or has a deeper pipeline, or higher performance. But then they say that for the compilation side, you need to rely on public domain tools. What if I want to extend RISC-V? Do those tools support my hardware implementation? There is too much focus on the RTL side of the IP implementations." There are several ways to design custom processors. For example, it could be with additional instructions, or by attaching a dedicated accelerator for a particular task. "HLS really helped blur the line about what is in the processor versus what is outside the processor, such as a dedicated accelerator," says Cadence's Knoth. "It lets that line be very flexible -- both application-specific and technology-specific. Looking at portability, if you have a processor that is being targeted toward a 5nm node, it's going to have very different care-abouts than something that is targeting a 22nm node. It is powerful to be able to have one consistent SystemC model, and then carve off certain pieces for a processor, versus certain pieces to be a hardware-based accelerator, to obtain an optimized implementation for the complete system." The key is being able to optimize the complete system, and that requires analysis of both hardware and software. "A high-level architecture description language, such as CodAL, enables us to capture the architecture with the instruction set, as well as the microarchitecture of the processors," says Codasip's Prikryl. "From the single description, in a language that is similar to C, we are able to generate an LLVM-based compiler, assembler, dissassembler, simulator, and the RTL, UVM verification environment, and other outputs." There are multiple types of optimizations. "I start with the architecture view, where I define a list of instructions and architectural resources," adds Prikryl. "I know roughly the timing that I would like to have, but I don't really care whether the load/ store unit will use AHB or AXI, or how wait states are handled. These are low-level details that come later. Once I am happy with the architecture, I can start adding micro-architectural information, low level details. There is a lot of common ground in all processors. You need to fetch instruction from the memory, you have hazard handling, decoders, load/store unit -- they just have to be there. The data path may be simple and handle just integer or floats, or it may be SIMD or scalable vector." Fig. 1: Tool flow from CodAL. Source: CodasipFig. 1: Tool flow from CodAL. Source: Codasip Fig. 1: Tool flow from CodAL. Source: Codasip Adding the microarchitecture leads to other types of optimizations. "We define two types of optimizations," says Synopsys' Goossens. "The first is compiler in the loop, and the second one is synthesis in the loop. Compiler in the loop means that when you're exploring different choices for instructions extensions, you use the automatically generated compiler for each instance of your architecture. For each trial, you generate the compiler, and then you compile benchmark code. That code is run in the simulator, and you can profile what was generated and see where the bottlenecks are in your architecture. Then you go back to the processor model -- in our case in the nML language -- and you make changes." Fig. 2: Tool flow for ASIP Designer. Source: SynopsysFig. 2: Tool flow for ASIP Designer. Source: Synopsys Fig. 2: Tool flow for ASIP Designer. Source: Synopsys "The second is synthesis in the loop," says Goossens. "From the same processor model we generate an RTL implementation and do logic synthesis. This will synthesize your generated Verilog code. You can see the critical path in the design and the clock frequency that you can achieve. You then can make decisions about micro-architectural details of your processor. You might adjust the number of pipeline stages. Maybe it has to be increased because there is a critical block, like a multiplier, that has to become pipelined. You go back to the nML model where there are constructs to describe the pipeline." When both processor extensions and dedicated accelerators are being used, a partitioning phase is necessary. "The micro-architecture parameter set and the custom extensions can be optimized for the target application by running simulation on the HLS models to understand the overall KPIs," says OneSpin's Beyer. "HLS tools can then be used to generate the RTL, with support for simple extensions inside the core and more advanced accelerators that are just loosely coupled. Thus, there is very low overhead to get to a precise RTL model with the HLS tooling and its support for custom extensions. You can then measure the KPIs on the generated RTL to finalize the choice of extensions and parameters." There are a lot of similarities in the commercial tools. "You look at ARC, Tensilica, Codasip, Andes -- they all have a language for describing the instructions," says Imperas CEO Simon Davidmann. "It is slightly more abstract than RTL, and their tools can push it into RTL. They also build a tool chain with LLVM. They often build a simulator, as well. One of the key issues is that you must be able to simulate directly in the high-level language because you have to be able to debug it. It is no good if you have to translate it into something else because then it just becomes too hard. Another important aspect of the tool chain is that when you make a small change, you don't want everything under that to change. The notion of engineering change orders (ECO) is important." So many languages Defining new processors was all the rage back in the '80s and '90s, but fell out of favor when the IP model became popular and a few companies managed to dominate the market with highly optimized processor cores. Now, there is a rebirth of sorts, and some companies have adopted the languages that were used in the past while others have adopted languages defined within the industry or developed new custom languages. They are all classified as Architectural Description Languages, or ADLs. When RISC-V initially was designed, it used a new language called Chisel. It is a hardware construction language based on Scala, and while it is at a slightly higher level of abstraction than RTL, it is not considered to be a high-level synthesis language. SiFive uses this language to define its processors. A research group at Columbia University in New York adopted SystemC and published a paper about it in 2020. The paper presented "HL5 as the first 32-bit RISC-V microprocessor designed with SystemC and optimized with a commercial HLS tool. We evaluate HL5 through the execution of software programs on an experimental infrastructure that combines FPGA emulation with a standard RTL synthesis flow for a commercial 32nm CMOS technology." So is SystemC the best choice? "SystemC has some significant advantages in terms of staying closer to the higher level of concepts than RTL," says Knoth. "You need to stay close to the people who are doing the algorithm design, so they have the freedom and flexibility to experiment and to explore their ideas. That's the best language. There is a huge amount of investment in the SystemC in terms of people using this for architectural exploration and verification. In addition, when strengthening the ecosystem with verification and connecting it closer into the implementation side, it becomes a better value proposition than pure RTL design." Many hardware/software tools have gravitated toward the C language. "The CodAL language is C-based and is understandable for everyone," says Prikryl. "You don't have objects or other things that you would find in SystemC or new programming paradigms, and it's easier for engineers to adopt. SystemC is a simulation framework, and it's hard to capture things such as how the compiler can leverage the instruction. You would have to have another layer anyhow, so it wouldn't be pure SystemC. At the end of the day you end up with a domain-specific language." There are many legacy languages for processor specification. "nML is a high-level definition language for describing a processor architecture and instruction set (ISA), says Goossens. The advantage of nML over hardware description languages like SystemC or Chisel, is all the software tools can be generated next to the RTL implementation, and you keep software and hardware consistent with each other. So nML is the golden reference for both the hardware and the software implementation." The RISC-V community also wanted a formal way to define the processor. "They adopted SAIL, which came out of Cambridge University in the U.K.," says Imperas' Davidmann. "The holy grail in design is correct by construction. You describe something up front where you can verify it. Then you map it to the next level down and re-verify. Arm clearly has this complete automation from the architecture through to the documentation. They have a flow from an initial representation through to the documentation, through to the RTL, through to the reference models, and they use formal tools along the way. The goal is to have a language that is abstract and where everything flows down from it." Arm clearly has cracked this problem, which is a factor in its success. To get some insights into what Arm does, this blog provides some insight. It was written by Alastair Reid, who was at Arm for almost 15 years, and is now staff research scientist at Google. Verification As systems become more complex, the verification task tends to grow faster than the design task. That means all viable solutions must take the verification task seriously. "Since the RTL is generated form the HLS model, both are in sync by construction," says Beyer. "The HLS model should also be used to verify the generated RTL. This is essentially the same step you would take on a normal synthesis tool by running equivalence checking. The HLS description of custom extensions can also be used to enable compiler support, instruction set simulator, and other elements of the software toolchain for the custom extensions." This relies on the high-level description being fully verified. Otherwise, you face a garbage in- garbage out situation. Unfortunately, the tools for doing that are somewhat nascent today. "If you start from a RISC-V model and you make extensions, you still want to make sure that the baseline architecture is fully compatible with the RISC-V spec," says Goossens. "So we run RISC-V validation suites to make sure that our implementation is really compliant with the RISC-V spec." Compliance suites do not verify the micro-architecture and are a long way from being complete. "There is no magic button when it comes to verification," says Prikryl. "We output a UVM environment and tools such as a random program generator, which is aware of every single instruction that's inside of the design, including the custom instructions. As a verification engineer you can take these verification tools and use them, or add more tools or testbenches on top of that. You also can do system exploration using the generated TLM SystemC model and create a virtual prototype." That becomes part of a larger 'in the loop' verification. "We typically recommend that you embed the processor model that we generate in SystemC, and use virtual prototyping tools," says Goossens. "This enables you to take into account the interactions with, for example, the memory hierarchy, the memory subsystem and measure performance." Custom instructions means that you have to do some verification yourself. "We provide the basic regression suite with C-level test programs that you can compile on the processor architecture, and you can simulate the generated code," says Goossens. "You also can execute those programs natively on the host computer and do comparisons. That's at the bit level to see if everything is consistent. But when you add custom instructions, you need to extend this test suite with specific additional test programs for what you add." Conclusion Processor design became the core competence of just a few companies, but getting more performance out of processor cores has become increasingly difficult. To make significant headway, multi-core heterogenous compute solutions are required. RISC-V has re-awakened the desire to create them. The industry is trying to create effective toolchains to address the needs in an environment that is rapidly evolving. There are multiple pieces to the puzzle and the industry is fragmented today, but the tools that exist give a significant boost over writing the processor in RTL, both in terms of optimization potential and productivity. Related Working With RISC-V What's available, what's missing, what's next. RISC-V Knowledge Center Top stories, videos, white papers and blogs on RISC-V. RISC-V Targets Data Centers Open-source architecture is gaining some traction in more complex designs as ecosystem matures. RISC-V Verification Challenges Spread Continuous design innovation adds to verification complexity, and pushes more companies to actually do it. Tags: ABH Andes architectural design languages ARM AXI C++ Cadence Cadence Design Systems Cambridge University Chisel Codasip Columbia University extensible architecture high-level synthesis Imperas Software Mentor Mentor Graphics NML OneSpin OneSpin Solutions processor processors RISC-V RTL Sail Scala Siemens EDA SiFive Synopsys synthesis SystemC TLM transaction-level modeling UVM Verilog 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[ ] Knowledge Centers Blogs RISC-V Published on August 26, 2020 C, C++ Published on October 25, 2019 Central Processing Unit (CPU) Published on October 18, 2019 Processors Published on July 25, 2019 High-Level Synthesis (HLS) Published on April 27, 2017 A brief history of logic synthesis Published on December 21, 2016 SystemC Published on September 25, 2014 IEEE 1666-Standard SystemC Published on Behavioral Synthesis Published on May 30, 2014 Technical Papers * Materials and Device Simulations for Silicon Qubit Design and Optimization October 27, 2021 by Technical Paper Link * Buried nanomagnet realizing high-speed/low-variability silicon spin qubits: implementable in error-correctable large-scale quantum computers October 27, 2021 by Technical Paper Link * Uniform Spin Qubit Devices with Tunable Coupling in an All-Silicon 300 mm Integrated Process October 26, 2021 by Technical Paper Link * Reaching silicon-based NEMS performances with 3D printed nanomechanical resonators October 19, 2021 by Technical Paper Link * Effect Of Environmental Factors On ADAS Sensor Performance (AAA) October 19, 2021 by Technical Paper Link Trending Articles What's Next For Transistors And Chiplets Imec's SVP drills down into GAA FETs, interconnects, chiplets, and 3D packaging. by Mark LaPedus HBM3: Big Impact On Chip Design New levels of system performance bring new tradeoffs. by Ann Steffora Mutschler Scaling Bump Pitches In Advanced Packaging Higher density of interconnects will enable faster movement of data, but there's more than one way to achieve that. by Mark LaPedus PCB And IC Technologies Meet In The Middle Surface mount technology is changing in some surprising ways. by Bryon Moyer High-Level Synthesis For RISC-V Abstraction is the key to custom processor design and verification, but defining the right language and tool flow is a work in progress. by Brian Bailey Knowledge Centers Entities, people and technologies explored Learn More Related Articles MicroLEDs Moving From Lab to Fab Bringing the cost down and yield up on microLED is proving to be formidable, but display companies and LED suppliers are working together toward production-worthy solutions. by Laura Peters The Silicon Carbide Race Begins As SiC moves to higher voltages, BEV users get faster charging, extended range, and lower system costs by Patrick Waurzyniak Piecing Together Chiplets Changes that could push this packaging approach into the mainstream, and the challenges ahead. by Mark LaPedus Chipmakers Getting Serious About Integrated Photonics This technology could enable the next wave of Moore's Law. What's needed to make that happen? by Brian Bailey The Great Quantum Computing Race Companies and countries are pouring tens of billions of dollars into different qubit technologies, but it's still too early to predict a winner. by Mark LaPedus Inside Intel's Ambitious Roadmap Five process nodes in four years, high-NA EUV, 3D-ICs, chiplets, hybrid bonding, and more. by Mark LaPedus and Ed Sperling What's Next For Transistors And Chiplets Imec's SVP drills down into GAA FETs, interconnects, chiplets, and 3D packaging. by Mark LaPedus Impact Of GAA Transistors At 3/2nm Some things will get better from a design perspective, while others will be worse. by Brian Bailey * Sponsors [Siemens-Lo] [se_sp_cade] [se_sp_syno] [imperas] [logo_v2_do] [vtool-logo] [1osp] [Valtrix_Lo] [se_sp_si2] * [INS::INS] Advertise with us * [INS::INS] Advertise with us * [INS::INS] Advertise with us * Newsletter Signup Popular Tags 2.5D 5G 7nm AI ANSYS Apple Applied Materials ARM Arteris Atrenta automotive business Cadence EDA eSilicon EUV finFETs GlobalFoundries Google IBM IMEC Intel IoT IP Lam Research machine learning memory Mentor Mentor Graphics Moore's Law Nvidia NXP OneSpin Solutions Qualcomm Rambus Samsung security SEMI Siemens software Sonics Synopsys TSMC UMC verification Recent Comments * TanjB on What's Next For Transistors And Chiplets * Yasunori Yamaguchi on Growing Challenges With Wafer Bump Inspection * Allen Rasafar on Gearing Up For High-NA EUV * Jan Hoppe on What's Next For Transistors And Chiplets * Craig Franklin on Fan-Out And Packaging Challenges * SteveT on Six Things We Might Need For Pervasive Computing * ASA on PCB And IC Technologies Meet In The Middle * Allen Rasafar on EUV's Uncertain Future At 3nm And Below * David Leary on How Chips Age * Anand Chamarthy on Graphene and two-dimensional materials for silicon technology * Abbas on The Verification Mindset * Peter AJ van der Made on How Much Power Will AI Chips Use? * Max Turner on Will Automotive Ethernet Win? * SUHAIMI SELIMAN on Week In Review: Manufacturing, Test * Eric on Advantages Of LPDDR5: A New Clocking Scheme * mark on Why It's The Perfect Time To Be Part Of The RISC-V Revolution * James Snodgrass on Using Better Data To Shorten Test Time * Fred Chen on Intermittent Undefined State Fault in RRAMs * Greg Yeric on Nudging 2D semiconductors forward * SUHAIMI SELIMAN on Evaluating The Impact Of STI Recess Profile Control On Advanced FinFET Device Performance * Does no Matter at the moment on Analyzing Electro-Photonic Systems * B. Couturier on Long-Haul Trucking With Fewer Drivers * SUHAIMI SELIMAN on Short-Circuit Ruggedness In SiC MOSFETs * than T nguyen on The Shortest Path Deception * David Chapman on Will Monolithic 3D DRAM Happen? * than T nguyen on Shortest Resistance Path Deception In ESD Protection Circuit P2P Debug * Akshay Mehra on Is SystemC Broken? * Jeetech Academy on How To Maximize Your Competitiveness In The Semiconductor Industry Using Advanced DFT * Huw Davies @Trameto.com on Why TinyML Is Such A Big Deal * Ali Mahdoum on New Memories Add New Faults * Sunitha Aaraveti on Will Automotive Ethernet Win? * Paul travers on Week In Review: Manufacturing, Test * Chandra on Using Analytics To Reduce Burn-in * Ron Lavallee on Steering The Semiconductor Industry * Theodore wilson on Steering The Semiconductor Industry * Theodore wilson on Education Vs. Training * 2R on Impact Of GAA Transistors At 3/2nm * Jan Hoppe on Modeling Chips From Atoms To Systems * Roddy Urquhart on Is RISC-V The Future? * wondering on Inside Intel's Ambitious Roadmap * alexander odishvili on The Next Advanced Packages * Shameem Khan on Current And Future Packaging Trends * Peterferry on Electric Cars Gain Traction, But Challenges Remain * Kirk Weedman on RISC-V Verification: The 5 Levels Of Simulation-Based Processor Hardware DV * Michael Kanellos on Who Owns In-Chip Monitoring Data? * Anne Meixner on Why Wafer Bumps Are Suddenly So Important * Matt on What's Ahead For DRAM, NAND? * Roy Longbottom on Understanding The Performance Of Processor IP Cores * Will on Is RISC-V The Future? * Jay on Impact Of GAA Transistors At 3/2nm * Ed Sperling on Designing Chips In A 'Lawless' Industry * Raymond Ramirez on Has Computational Storage Finally Arrived? * David Leary on Why Wafer Bumps Are Suddenly So Important * Karthikeyan Ramamurthi on Time To Rethink Memory Chip Design And Verification * Ian Dedic on Designing Chips In A 'Lawless' Industry * juan magallenes on Is RISC-V The Future? * Scott Shadley on Has Computational Storage Finally Arrived? * SUHAIMI SELIMAN on Manufacturing Bits: Aug. 9 * Srinath A on Automotive Lidar Technologies Battle It Out * ProDigit on Chiplets: A Solution For The Shortage Of Chips * Gilbert Humphry on Why EV Battery Design Is So Difficult * Volodymyr Dobrovolskyi on Is RISC-V The Future? * Ann Steffora Mutschler on Data Centers On Wheels * Guoqiao Tao on MicroLEDs Moving From Lab to Fab * Dr. Dev Gupta on Piecing Together Chiplets * Pankaj Mehra on Piecing Together Chiplets * Sylvain on Intel/GF deal: Pros, Cons, Unknowns * Kevin Cameron on Developers Turn To Analog For Neural Nets * Kip Stevenson on IC Data Hot Potato: Who Owns And Manages It? * Tanj on New Transistor Structures At 3nm/2nm * Tanj on Retimers Replacing Redrivers As Signal Speeds Increase * TJN Texas on Behind The Intel-GlobalFoundries Rumor * Lullaby on Chipmakers Getting Serious About Integrated Photonics * Reedman on Foundry Wars Begin * HLector Favabeen on Behind The Intel-GlobalFoundries Rumor * Reedman on CEO Outlook: Chiplets, Longer IC Lifetimes, More End Markets * Ed Sperling on Behind The Intel-GlobalFoundries Rumor * Hank Walker on Behind The Intel-GlobalFoundries Rumor * Fred on Behind The Intel-GlobalFoundries Rumor * Lewis Bosher on The Process Design Kit: Protecting Design Know-How * Benjamin Cheng on CEO Outlook: More Data, More Integration, Same Deadlines * krista on Chipmakers Getting Serious About Integrated Photonics * Jan Hoppe on Cleaning Up During IC Test * Kevin Cameron on Domain-Specific Memory * T.S. Sriram on The Case For Antifuse OTP NVM For Secure & Reliable SoCs * Michael Williams on Cleaning Up During IC Test * Michael Williams on 5G Chips Add Test Challenges * Steffen Capello on Challenges Grow For Finding Chip Defects * Harri W. on Fast, Low-Power Inferencing * Matt on China Speeds Up Advanced Chip Development * Tony on Alternatives to silicon for solar cells * Michael Kanellos on Architectural Considerations For AI * Dr. Dev Gupta on Bumps Vs. Hybrid Bonding For Advanced Packaging * Scott Phillips on Data Centers On Wheels * cybersecuritylawsrc on Preventing Online Fraud * JT SUH on Bumps Vs. Hybrid Bonding For Advanced Packaging * Hugo Pristauz on Bumps Vs. Hybrid Bonding For Advanced Packaging * Joao Geada on Pitching To Your Audience * Gil Russell on Architectural Considerations For AI * Lee H Goldberg on Pitching To Your Audience * SUHAIMI SELIMAN on Manufacturing Bits: June 22 * Pete Johnston on Virtualization In The Car * Steve B on Problems In The Power Grid * JackL on Searching For EUV Mask Defects * Luca De Santis on Scaling Simulation * Triggered on The Increasingly Uneven Race To 3nm/2nm * Hans Diesing on Is There a Practical Test For Rowhammer Vulnerability? * Gabriel Mendez-Hincapi on The Increasingly Uneven Race To 3nm/2nm * Tipalo on There's More To Machine Learning Than CNNs * Erik Jan Marinissen on Is There a Practical Test For Rowhammer Vulnerability? * Baker Mohammad on Is There a Practical Test For Rowhammer Vulnerability? * Ploni on AI Inference Memory System Tradeoffs * Jim Lewis on Continuing Challenges For Open-Source Verification * YOSHIYUKI ANDO on New Transistor Structures At 3nm/2nm * Slav Inger on Automotive IC Shortage Drags On * Jim Lewis on A Price To Be Paid * Allen Rasafar on E-beam Inspection Makes Inroads * Ron Laugesen on Innovation In C-PHY * Seeker on Foundry Wars Begin * Reiner Franke on Technology Access Discriminates Dealing With Market Shifts Brian Bailey What's Next For Emulation Brian Bailey [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 * Events * Webinars * Knowledge Centers * Startup Corner * Bus & Marketing Strategies Connect With Us * Facebook * Twitter @semiEngineering * LinkedIn * YouTube Copyright (c)2013-2021 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