Two Good 'n Easy Opinion Pieces on ESL

I’ve seen two good opinion pieces on electronic system level (ESL) design this week on Web sites for two magazines. The first piece, titled "Is System-Level Design About Discipline?" on the Electronic Design Web site, was written by Frank Schirrmeister, who is Director of Product Marketing for System-Level Solutions at Synopsys. The first thing that caught my eye was this truism:

“Everybody seems to know and agree that it becomes more difficult to find and fix defects the further a project has progressed.”

I don’t expect to give or get any argument about that statement. I believe that multiple studies over several decades will substantiate this statement as fact. You should feel it in your bones. If not, just consider the cost of recall if a design bug gets into a product that ships several million units. It’s always easier and cheaper to fix a show-stopping bug before it gets out the door.

Schirrmeister then makes another statement and asks a critical question:

“So what’s wrong with consumer electronic product design? Are we simply not disciplined enough to think first and implement later?”

I believe the clear answer to this question is “yes.” As an industry, we lack the discipline to think about system architecture first and implement later because we’ve “always” done it this way, where “always” is defined as “for the last 20 years.” Early SOC designs were simple enough and the performance requirements were lax enough to permit designers to go straight to implementation after creating a simple architectural design with little or no systems analysis. Any performance problems were addressed with some easy fixes: more memory or more clock rate.

Increasingly complex systems no longer permit this lack of discipline. The penalty for lax discipline is now going to be horrendous financial failure for the SOC design project. Time to get some discipline fast!

Which brings me to the second ESL piece I saw this week, which is not signed but I think it was written by Jon McDonald, a technical marketing engineer at Mentor Graphics, because his name is in the blog’s URL. McDonald writes:

“I’ve been thinking about a conversation I had recently with a colleague. He’s been doing system-level modeling for a few years and has been an advocate for transaction-level modeling and ESL in his company. He has had tremendous success in identifying and fixing system-architecture issues before implementation, as well as saving his company from pursuing business that they would not have been able to satisfy based on their current product architecture. Yet he still has trouble convincing project groups to invest in the up-front ESL modeling and analysis that has delivered his success.”

It sounds like this person does have the required system-level design discipline, but his employer does not—at least not enough to enforce good system-level design practices for major projects. McDonald then gives as good a justification for using disciplined ESL techniques as any I’ve seen:

“As a hardware designer focused on the hardware implementation, I may prove that the hardware works exactly as it is designed to work, but at this RTL implementation level we cannot run real software interacting with real data without building the actual system or implementing a prototype of the system. This is one of the reasons to bother with ESL design.”

I am an unabashed supporter of the idea of ESL. Complex systems should be designed before they’re implemented. If we’re talking about 1-chip wonders based on some existing microcontroller IC, then feel free to be a maverick and implement away. If we’re talking about today’s complex multicore systems with multiple processors, complex I/O, and dozens of memory arrays strewn around the chip, put some thought into it before you unleash the RTL code slingers!