feature article
Subscribe Now

Got MILF?

Microprocessors I’d Like to Find, 2013 Edition

It’s springtime, the groundhog has seen his shadow, Easter is behind us, and a young man’s thoughts turn to… microprocessors.

Every embedded system includes a microprocessor or two, and few things will affect the performance of your system as much as that chip. We all have our favorite CPUs (and a few least-favorite CPUs), but rarely do we find that perfect chip: the one that has absolutely everything we want, just the way we want it. Maybe if we create an imaginary checklist of all the things we’d like to see, one of the microprocessor vendors out there will surprise us come Christmastime.

For starters, I’d want a multicore processor. Surveys show that more than half of embedded systems in design right now will contain multiple processor chips. That’s counting 8-bit, 16-bit, and 32-bit CPUs. Sometimes those are identical chips, sometimes different chips but from the same vendor (mixing different Freescale parts, for example), and sometimes they’re completely different processors from different vendors (an ARM and an x86, for instance). So we’re all over the map as designers. 

Instead of that, I’d want to have one chip that had multiple CPU cores in it. Having different physical chips takes up space and complicates my PCB routing. One mega-chip would make that easier while still giving me the power and flexibility of multiple CPUs. Multicore microprocessors are pretty common nowadays, but you don’t often see chips mixing different CPU architectures. I’d want mine to combine x86, ARM, 68K, MIPS, and maybe Z-80 just for fun. That way, I could write (or reuse) whatever code I wanted without having to worry about software compatibility. Naturally, all the unused cores would power-down and consume zero energy. Hey, a guy can dream.

Next, the perfect processor would be fabricated either by Intel on its 22nm FinFET production line, or by TSMC in 35nm bulk CMOS. Why the difference? If my system is power- or performance-critical, I’d want the leading-edge Intel silicon. But if it’s not, I’d rather go for the run-of-the-mill TSMC process and save money. No point putting a Ferrari engine in a grocery-getter.

For peripherals, I’d have none. Well, no fixed peripherals, anyway. Instead, I’d want virtual peripherals implemented either in programmable logic or simulated entirely in software. We’ve seen various companies try both approaches, but never very successfully. Ubicom, for example, did “virtual peripherals” using software emulation, which is a technique I very much like. You can add, remove, or tweak your peripherals simply by changing code. Pinouts are simply a matter of programming, and peripheral throughput is largely up to you. Want another Ethernet port? No problem, just code one up. Need a USB 3.0 or Thunderbolt port to keep up with the engineers next door? Coming right up.

Instead of the software-emulation route, the chip could use programmable logic for its peripherals; I’m okay with that. A long time ago, Triscend (now part of Xilinx) had a microcontroller with “soft” peripherals that you could create in just a few seconds using a drag-and-drop software tool. Very slick, and very easy to reconfigure to suit your board layout or your interface needs. I’ll take some more of that, please.

As far as the package for this ideal chip, I’d lean toward an old-school PGA. I know the pin density isn’t very good, but it has the advantage of easy socket access, and it’s easy to get oscilloscope or logic analyzer probes on it. Maybe in production I’d switch to a denser surface-mount package, but for development, give me that old time pin-grid array.

Debug is a big deal. Research into developers’ habits shows that embedded programmers typically spend more time debugging code than they did writing it, so throwing resources at debug tools is money well spent. The perfect embedded processor would have its own on-chip debug processor: a real 32-bit beast with private on-chip memory that does nothing but handle debugging. I’d have it run diagnostics, monitor breakpoints, manage stack over- and under-runs, check memory bounds, snoop bus cycles, and execute all sorts of elaborate conditional monitors that I’d create on the fly. Ideally, there’d be a big repository of open-source debug routines for this thing so we’d all benefit from each others’ debug experiences. 

Oh, and while we’re at it, the chip should have a few green LEDs on top. You know, so the debug routines can blink diagnostic codes. If the package is big enough, a seven-segment or LCD display on top would be even better, but let’s not get crazy.

The on-chip cache – and there would be lots of cache – would have to be configurable. I’d want to be able to dial in the cache size to see what it does to performance or predictability. A smaller cache might trim performance a little bit but save power, and maybe that’s a tradeoff I’d want to make. Sometimes I’d want to disable the cache entirely to get deterministic software behavior.

A built-in memory controller would be really handy. I hate designing memory controllers. The ideal one would handle pretty much any type of memory interface ever created, from dumb DRAMs with RAS/CAS timing to several generations of Rambus interface, Hybrid Memory Cube, and modern DDR3/DDR4 chips. SRAM, flash, and NVRAMs would have to be supported, too. The MMU would let me map the memories to any address range I want, of course.

Operating systems? I’ll take all of ’em. The ideal chip should come with ready-made ports of Linux, Windows Embedded, µCOS, ThreadX, Android, VxWorks, Integrity, and MQX, plus a few others to be named later. One big DVD with all the images on it would be nice, thank you. Naturally, each OS would come with drivers for all the soft peripherals I’ll be creating.

While we’re at it, make sure there’s a firmware setting that I can adjust to set the chip’s maximum power consumption. Maybe something that would automatically throttle back the chip’s clock speed to stay within my preset power envelope. Separate settings for instantaneous power and average power (say, over 10 seconds) would be handy, thanks.

This should all come on a $99 evaluation board with a bunch of USB connections, a Wi-Fi daughterboard, AA batteries, LCD and LED displays, PCI Express, and a TV tuner. And be waterproof. Complete circuit schematics, PCB layout, and firmware source code included.

That should about cover it for now. Got that, all you embedded hardware vendors? We’ve just given you the key. All you have to do is follow this simple recipe and you’ll sell a million of ’em. Every engineer, programmer, and development manager in the world will beat a path to your door. Of course, you’ll probably lose a few thousand dollars on every unit you sell, but so what? You’ll make it up in volume. 

Leave a Reply

featured blogs
Mar 2, 2021
You probably have heard that Waymo has completely driverless (no safety driver) taxis serving Phoenix. 600 of them. But you can't go and buy one. Why is that? Paul Graham, the founder of the... [[ Click on the title to access the full blog on the Cadence Community site....
Mar 1, 2021
“Do you know how FAST you were going?!?” That question strikes fear in almost all teenage drivers. The resulting ticket dashes any hope of a fun weekend. Plus, what happens when the parents find out?? No!!! Meanwhile, embedded and optical engineers may wonder the ...
Feb 26, 2021
OMG! Three 32-bit processor cores each running at 300 MHz, each with its own floating-point unit (FPU), and each with more memory than you than throw a stick at!...
Feb 25, 2021
Learn how ASIL-certified EDA tools help automotive designers create safe, secure, and reliable Advanced Driver Assistance Systems (ADAS) for smart vehicles. The post Upping the Safety Game Plan for Automotive SoCs appeared first on From Silicon To Software....

featured video

Silicon-Proven Automotive-Grade DesignWare IP

Sponsored by Synopsys

Get the latest on Synopsys' automotive IP portfolio supporting ISO 26262 functional safety, reliability, and quality management standards, with an available architecture for SoC development and safety management.

Click here for more information

featured paper

Authenticating Remote Automotive Peripherals Using GMSL Tunneling

Sponsored by Maxim Integrated

Authentication can be applied to automotive environments to protect peripheral components from third-party counterfeits. This application note details how to implement automotive authentication with the use of gigabit multimedia serial link (GMSL).

Click here to download the whitepaper

Featured Chalk Talk

Selecting the Right MOSFET: BLDC Motor Control in Battery Applications

Sponsored by Mouser Electronics and Nexperia

An increasing number of applications today rely on brushless motors, and that means we need smooth, efficient motor control. Choosing the right MOSFET can have a significant impact on the performance of your design. In this episode of Chalk Talk, Amelia Dalton chats with Tom Wolf of Nexperia about MOSFET requirements for brushless motor control, and how to chooser the right MOSFET for your design.

More information about Nexperia PSMN N-Channel MOSFETs