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

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!