Years ago, when I was Editor-in-Chief of EDN Magazine, I coined (but did not name) Leibson’s Law:
“It takes 10 years for any disruptive technology to become pervasive in the design community.”
I was reminded of that observation while reading Richard Goering’s account of a DAC 2012 panel titled “High-Level Synthesis Production Deployment; Are We Ready?”
The moderator was Clem Meas of quickStart consulting and the panelists included:
- Mark Johnstone, principal EDA technologist, Freescale
- Eli Singerman, principal engineer, Intel Design Technology and Solutions division
- Benjamin Schafer, assistant manager at R&D Central Laboratories, NEC Corp.
- Vinod Kathail, distinguished engineer, Xilinx
- Mark Warren, engineering group director, Cadence
- Andres Takach, senior architect, Calypto Design Systems (and chair of Accellera SystemC Synthesis Working Group)
It was a comment by Meas that made me think of Leibson’s Law. Here’s the sentence lifted directly from Richard Goering’s blog post:
“He [Meas] noted that it takes 10 years for the industry to move to a new level of abstraction, and said that with HLS ‘we’re 8 years into a 10 year period.’”
Moving to higher abstraction levels as design complexity grows is inevitable, as Freescale’s Johnstone noted during the panel:
“Today we’re seeing 1.3 billion transistors per design. In 2020, at the projected end of Moore’s Law, it will be 21 billion transistors. Clearly this is not sustainable with RTL.”
You should not be surprised to hear that we’ve all been here before. The current use of RTL supplanted schematic-level digital ASI C design when designs hit about 50,000 to 100,000 gates. Schematic just couldn’t manage the complexity in any sort of efficient manner. Even with schematics, transistor-level design gave way to gate-level design when the number of gates in a design reached a certain level.
We’ve now used RTL-based design to create digital ASICs and SoCs for more than two decades and the wheels are falling off at that abstraction level, as Johnstone notes above. Something, or more likely “some things” will replace RTL-based design. It might be high-level synthesis but I think more likely, it will be a combination of high-level synthesis, heavier IP block reuse, and more reliance on 3rd-party IP blocks. The IP block usage is already skyrocketing and digital SoC design looks more and more like block-level assembly every day. High-level synthesis is already recognized as a viable tool for creating new IP blocks and therefore fits well with this trend towards block-based SoC design assembly.
If you doubt the current block-generating abilities of high-level synthesis, I found an interesting parallel in a long-running LinkedIn discussion of RTOS use. This discussion is taking place in the LinkedIn Real-Time Embedded Group and was started by Miro Samek of Quantum Leaps, LLC. On April 25, Samek asked this deceptively simple question: “Is an RTOS really the best way to design embedded systems?”
I say that the question was deceptively simple because it’s already generated two months of vigorous discussion in the LinkedIn group. It’s one of those discussion questions that goes viral.
The response to Samek’s question that’s relevant to the above discussion of high-level synthesis was made yesterday by Nabeel Sowan, an embedded developer at Infometric AB in Sweden:
“…there haven’t been very many compelling reasons to write pure assembly at all since C compilers became better than the average developer, which was more than a decade ago.
There’s no reason to spend 500% the effort on writing code that may or may not get that 3% gain in performance only to find out after a few weeks it loses 10% after you needed to change that critical thing for a customer.
I agree that the occasional INLINE is very important, but writing PURE asm hasn’t been a very useful way of developing anything but the smallest systems for a very long time.
Trying to outperform the best C compilers nowadays is a fool’s errand, since most of what comes out is exactly the same as you’d write on your best day.
Now, this may not be exactly true on x86 and GCC etc. but on those platforms, with your 24Gb of RAM, do you really care?
And what about requirements?
- Code reuse
- Work on more than one platform
- Share code across platforms
- Average development times
If your requirements are any of the above, you simply can’t use asm.
What I’m saying is that assembly in this case is a _strawman_ which has nothing to do with the discussion at all.
It’s like saying real men flip their bits using a scanning tunneling microscope.”
I think those sentiments either pretty much parallel the situation with SoC hardware design or will when the “Leibson’s Law” clock stops ticking on high-level synthesis.