Jon McDonald’s opinion piece, just published in the System-Level Design Community section of Chip Design Magazine’s site, is about assumptions built into the design of complex electronic systems. Although it’s not McDonald’s topic, his writing drove my thinking along another set of assumptions that costs design teams a lot of time and energy. These assumptions lead us to make easy architectural choices that later get us into trouble. Here are a few common ones.
“I need a processor that runs at X GHz to run all the tasks I need to run.” The assumption here is that one fast processor is the right choice. Increasingly, using multiple processors is a better design approach.
“I need a processor clocked at Y GHz to run video.” The assumption here is that a general-purpose processor is the right choice to perform digital video encoding or decoding. Specialized video processors perform the task at much lower clock rates. The same is true for digital audio.
“I need a bus that runs at ZZZ MHz to connect all of these blocks.” The assumption here is that a bus or bus hierarchy is the best way to connect multiple processors, memory, and I/O blocks. There are simpler ways to connect blocks and many times, the simpler ways are the far better choice.
“A bus isn’t fast enough, so I need a NoC (network on chip).” The assumption here is that there are only two alternatives: a bus or hierarchy of buses and a NoC. In reality, there is a spectrum of interconnect alternatives to explore.
These assumptions and many others are treated as rules of thumb or “best practices” and are based on SoC design experiences at earlier, less advanced process nodes. Rules of thumb can save us time, as long as they don’t overgeneralize and as long as they are built on a foundation that remains based on true facts. Process technologies tend to break facts and make them inoperative. Without exploring the system design space to test these assumptions in the dynamic world of SoC development, you’re practically guaranteed to come up with a suboptimal design.
ESL design methodologies, SystemC, and TLM (transaction-level modeling) are a start on the tools needed to do true system “engineering,” what EDA360 calls System Realization. System-level complexity at 40nm, 32nm, and 28nm process nodes is sufficient to drive the industry towards a more formal definition of System Realization tool kits. To get there, we need standards. That was the topic of my previous blog entry and the topic of discussion at the recent Si2 OpenAccess Conference. Without standards, you get a bunch of proprietary, incompatible design tools. We’ve done that. Now it’s time to grow up.