1 / 9

Speed, Drunkenness, and the Wall Does High Level Design/ESL Make Sense?

This article discusses the need for speed in microprocessor architecture and the challenges in functional validation. It explores the use of high-level design/ESL for early validation environments and the barriers to its adoption, including the translation from RTL to ESL and the maintenance of test environments. The article also suggests rendering ESL models for micro-architecture verification, focusing on complex protocol verification and creating a value statement for ESL modeling. It questions the use of SystemC as a hardware language and calls for a structurally intuitive, modern HW language in the industry.

simont
Download Presentation

Speed, Drunkenness, and the Wall Does High Level Design/ESL Make Sense?

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Speed, Drunkenness, and the WallDoes High Level Design/ESLMake Sense? Kris Konigsfeld Sr. Principal Engineer Oregon CPU Architecture Intel Corporation

  2. The Need for Speed • In 2004, we moved our RTL to Industry “Standards” SystemVerilog/E • The promise: • More Abstraction • Leverage Industry Tools • Better use of our resources by leveraging Industry • What we got, was a very slow model • ~5x slower than previous internal simulator…

  3. The Need for Speed - 2 • In Microprocessor Architecture, we do detailed transaction level modeling • Performance • Power • But, Functional Valid. is a big limiter to getting a new feature • Functional Validation is high effort • Complex Features are “risky” • We don’t do “ESL” for this – we should

  4. We’re Drunk on Random • Or, better said, we’re randomly drunk  • Random Testing for micro-architecture • Need to Code Coverage • Need to Code the Driving Random Test bench • Need to Code Checkers • Run on RTL to 1) debug the validation env.,2) debug RTL, iterate until 3) hit the coverage • A High Level Design/ESL should enable early Validation Environment • Without the RTL!! • Skew Bug Curves: Valid Env versus RTL bugs • Can it become the validation environment?

  5. The (Intellectual Property) Wall • Microprocessor Design is a hugeIP re-use adventure • The IP is “very soft” – its more like “goo” • We invade it, change it, perturb it, and then we build it • This IP baseline is the largest barrier to using High Level Design • No one wants to pay for the translation from RTL to an ESL model • Huge test env “collateral” tied to RTL • Who Maintains it?

  6. High Level Design and ESL:Who Cares? • Those who need “fast” simulation • Those who want validation collateral in place before RTL • Those architects believing definition closure requires an implementation • Especially if these can be formally proved • Those who have to develop SW that delivers at the same time silicon does. • And, in my opinion, those who buildhigh integration Microprocessors

  7. What Should be Done? • Render ESL Models for Micro-Arch. Verification • Functional, Un-timed Models: For Checking • Sequenced and “Timed” models • Overcome “all or nothing” barrier for value • Focus: Complex Protocol Verification • Diverse Agent Interaction • Find the “missing link” between ESL and Functional Verification • Create value statement justifying the model

  8. Backup

  9. What’s with SystemC? • SystemC is a hardware language implemented with a C++ library? What the <beeeep> is up with that?!!! • Are we lazy? • Don’t want to specify a parse-able HW language? • Don’t want to build a compiler? Fast Simulator? • Don’t want to understand the true abstractions of HW? • Afraid to tell language customers to sequence their code? • Are we gluttons for punishment? • Make the synthesis problem harder than it already is? • Translate the language work to into training/lint work? • Please, will someone in the industry deliver a structurally intuitive, modern HW language: • Acceptable to Architects, Rapid uArch entry, Fast Simulation (100x RTL today), Synthesizable, Formally Analyzable, with SW Abstraction Power!

More Related