A basic tenant of configurable computing, and the one that got me hooked as a senior in undergraduate engineering, as the idea that the lines between hardware and software could be blurred. Software had always been tailored for the hardware that it ran on, whether it was done that way by hand or if left up to the compiler. Well, what if you could design hardware that better fit the needs of a particular application, automatically? My idea was to use the well-known tricks of scheduling for VLIW machines and use those as a set of “hints” for the what the ideal hardware could look like.

The class professor wasn’t too hot on this idea, but let me do it anyway ‘cuz I’m tenacious. So for the next few weeks I poked around an open-source compiler and messed with making a mythical hardware design out of the compiler’s scheduler and ended up with some interesting results.

For example, most DSP’s have a single instruction multiply-and-add. This is because the most common thing they do is add and multiply (you can find a bunch of these in the my previous paper). Well it turns out that you get only modest savings from doing that. My research showed that for most implementations, making faster individual multiply and add units performed better than making a monolithic one.

The results were interesting enought that the prof convinced me to submit my work to a handful of conferences. Ha! This was literally a stretched out homework assignment and he expected it to be accepted at a research conference? Well, it did, and to one of the most prestigious ones — ICCAD. Here’s a link to my paper, the abstract and embedded copy can be found below.

Abstract

Many previous attempts at ASIP synthesis have employed template matching techniques to target function units to application code, or directly design new units to extract maximum performance. This paper presents an entirely new approach to specializing hardware for application specific needs. In our framework of a parametrized VLIW processor, we use a post-modulo scheduling analysis to reduce the allocated hardware resources while increasing the code’s performance. Initial results indicate significant savings in area, as well as optimizations to increase FIR filter code performance 200% to 300%.

There is a lot I want to write about PhatNoise, since there is a lot that happened.  Literally a garage startup, PhatNoise ended up running for over six years, with half a dozen automotive deals, and finally a successful sale to Harman International.  Whatever I write, however, I would like these notes to be considered both a post mortem and a straight historical accounting of what went down.

PhatNoise began as a question I asked myself: could I put a little computer full of mp3s in my car by replacing (and mimicking) a regular old CD-Changer?  Only one way to find out – reverse engineer the communication path in the car, build the hardware to interface it to a PC, and off we go!
Our home base was a crappy apartment in west LA, which happened to be just up the street from the infamous DEN.  Here’s Dan Lau, my roommate at the time, where it all started:

What we had hobbled together wasn’t much, and it would frequently break down in a plume of smoke, but it was enough to convince us that having thousands of songs in your car was damn cool.

Keep in mind this is late 1998.  It was about six months before the original Napster was released, and about three years before the first iPod.  I would often joke that the first half of any meeting we would have with an investor or hardware vendor was devoted to explaining what mp3s were and why anyone would care.  But this demo was enough for us to realize the potential, and we thus set out to build a dedicated solution to replace the jungle of wires pictured above.  My buddy Dan and I finished up our Master’s degrees at UCLA, and founded the company in July of 1999.

Pizza and Ikea

The company was largely conducted out of our living room.  Most of our hires were friends of ours at school, many of whom had not graduated yet.  The operation was run on Ikea furniture (the first job of any new hire was to build the desk they would call their home), and lots of pizza dinners.  Folks would head over to our pad (the “PhatPad”, the first in a long line of Phat* names), and bang out various aspects of the concept.  There wasn’t much of a plan, nor did anyone have any relevant experience beyond being smart engineers.

Creating a small Linux computer to interface with cars was the main idea, but a bunch of other problems needed to be solved along the way.  The biggest was moving music from the PC to the car.  Our original concept was for computer to house a hard disk drive full of music, and you would shuttle the whole computer to and from the car.  At the time, though, USB-bulk storage devices were *just* coming out on the market.  Using painfully slow first generation USB, these were designed to accommodate external hard drive enclosures.  Our idea as a bit more ambitious – house just the drive in a small cartridge that could easily slide into bays or docks.  Here’s what very early sketches looked like:

The computer itself (the “PhatBox”) was originally thought to look not much different from CD-changers, such as this sketch below:

This idea was ditched when our contract manufacturer convinced us that using a single piece of extruded aluminum was cheap to tool, and looked way cooler.  With our concept firmly in hand, we were able to raise enough venture money to actually pay people and to move the operation out of our apartment.

Prototypes

Speaking of which, this is probably the biggest lesson in building a new hardware product: get really comfy with the contract manufacturer.  You gotta choose them as if you were going on a long, dangerous, and ill-planned camping trip together.  This partner will need to take on a lot of risk if you are going to do this on the cheap, and yet they will need to be capable enough of really running the show.  Fortunately, we did have a great partner that believed in our vision, and part of what this partner did was create manufacturable 3D models of our sketches and quick-turn SLA prototypes.  Here they are:

Pretty damn close, wouldn’t you say?  Here’s how the cartridge fit in the cradle, with a giant CRT monitor for scale:

The cartridge never did quite perfectly fit in the dock, considering there was a 40-pin connector there and all.  Rigorous mechanical engineering is one of those things that you just gotta pay a lot for.  If this looks familiar, well let’s just say we inspired a few folks:

Iomega, really, we’re flattered!

Enough about plastic, though, onto electronics!  Our idea was always a small computer, capable of playing back thousands of mp3s, interfacing to a variety of automotive networks, and easily software upgradable.  In order to fit our cost and mechanical constraints though (more on that later), it meant finding a processor “just good enough”.  It also meant pretty much designing and building it from scratch.

The just good enough processor turned out to be an ARM7 running at a whopping 74MHz from Cirrus Logic.  And just as important as being cozy with your manufacturer is to be really chummy with your major chip vendors.  Processors are complicated beasts — even little ones like this — and you’ll need all the help you can get.  Cirrus was always a great vendor for us.

Software was done all in house: a stripped down Linux kernel, software audio decoders, and daemons to manage everything.  A smart decision we made was to include a second, smaller microcontroller on the board to handle interfacing with the vehicle, power management, and in-system updates.  It acted like a bridge between the PCB and the Linux OS.

I want to make the point that this was all very fancy stuff for a music player.  Every other device on the market used a dedicated IC for decoding MP3s and doing everything else on the device.  We were the first to employ a full OS and software decoders in such a product, and we got press simply for that fact.

The boards took quite a long time to get working properly, but this basic design would last us for years.  Here’s a shot of an early PCB:

Along the way, the company crammed as much as possible into the space and time we had.  That’s me on the right – hey at least we had a view!

Although one downside is that at 4am it gets quite cold in an office building with no heat on, even in Los Angeles:

Notice all the crap in the back – oy!

We wouldn’t have had much of a music system if there wasn’t a tool to effectively rip CDs and manage all that stuff.  As if there wasn’t enough to do, we made that as well.

It was not the first music management tool, but one of the only built around a database to manage thousands of tracks, and with a dedicated interface to sync it to the portable drive.  And since all the cool apps had funky skins, ours did too.  One of our early users called it “garish”, and the name stuck!

The Big Show

After about 15 months from inception, we were ready for our first big show: the MP3 Summit, sponsored by the then huge mp3.com.  Most of the companies were either software services (luminaries such as Scour and moodlogic), or large hardware companies such as Philips and Thomson.  And then us.  We had a barely working system, held together with tape and with a soldering iron always nearby.  One of us was permanently on duty to reset crashed demos.  But none of it mattered, since the crowd was in awe:

We were easily the most popular booth at the show, because people saw something for the first time in the flesh: thousands of songs, accessible by the stereo they may already have in their car; a portable harddrive with USB connectivity, and a database driven music management software for the PC.

Was it worth it?  Well, we won best of show.  The company went on to strike deals with most major automotive suppliers, and to develop several variants of the system, including a home version and a multimedia version for General Motors.  We have PhatNoise alums at both Apple and Google.  Our main competitor (and major source of inspiration) went on to become the hardware chief of the Apple iPhone.  Here’s Hugo and myself at that summit:

About six months later, when rumors were swirling around a totally new product line from Apple (a week before the iPod was announced), a Wired reporter asked me for a quote.  I didn’t think Apple was doing anything directed at cars, and to this day most interfaces for iPods are pretty lame.  But Apple did take what they knew was a game-changing technology (MP3s), and spent the money to cross the chasm to the masses (more on that another day!).  I’d like to say that our company did some trailblazing as well, and was an experience I wouldn’t have gained any other way.

So you wanna get into the electronics business?

As I mentioned earlier, there is a lot more to write about PhatNoise, but since you don’t run into too many consumer electronics startups, I thought I would spend some time on some humble advice.

Try to avoid hardware. Really, it is awfully expensive and time consuming.  But if you got this far you are probably hell bent on making hardware an integral part of something new, so…

Use the biggest building blocks possible. It’s like Duplo versus Lego: you maybe able to make something more intricate with Legos, but that’s reserved for the bigger kids with bigger wallets.  For the Techcrunch tablet project, for example, they should really just book a weeklong trip to south China, look at lots of existing models that come close to their vision, and weigh the pros/cons of modifying it.

Weigh the opposing forces. There is a saying: fast, good, or cheap – pick two.  Well, I can make this a bit more precise for consumer electronics.  The NRE cost, final price, performance, flexibility, and mechanical constraints are five dimensions that generally oppose each other.  For example, tight mechanical constraints will make the product NRE cost more.  But lowering the NRE cost will likely raise the final price.  Increasing performance (faster processor, longer life battery) stresses the mechanical design (faster processors need better heat dissipation, longer life batteries are usually just larger ones).

Find an original design manufacturer (ODM) that can do it all, and let them do it all. Let’s say you violate this rule and hire an amazing mechanical engineer outside of the ODM to design an awesome dock for your web tablet.  The tablet is largely the ODM’s design, and the dock is from this super fellow.  And when you have the first prototype and it doesn’t dock correctly one out of a hundred times, who is going to find out what’s wrong and make the appropriate change?  Both the mechanical engineer and the ODM will point fingers as at you.  Let the ODM do all the work and manage their own subcontractors.

Make sure the hardware-software connection is clear. Lots of folks feel they have a stronger handle on the software than on the hardware, and thus make that the dividing line.  However, the hardware and software need to work in concert.  If your web tablet is supposed to have a “sleep/resume” feature, what is the mechanism of waking it up again?  Do all the peripherals get reinitialized correctly?  Are the things that are supposed to be non-volatile really safe?  How about updating the software?  Can you update the operating system?  If so, what happens if that update fails (and it will)?  If you are not careful you will be left with a cool paperweight.

Where is the product going to be sold, and how is it going to be used? This is painfully tricky – FCC is required in the US, CE in Europe, and it kinda varies everywhere else.  Do you know what the packaging requirements are like?  Do you have French everywhere in order to be sold in Canada?  Who is writing the user’s manual?  What are the environments this is to be used in?  What are the requirements for temperature, humidity, mechanical shock, EM radiation, EM immunity – and who’s going to test all this?  If you think this should all be “ok” the next time you try out that LCD panel that’s really cheap, think again — these are the exactly the areas the vendor is likely cutting corners without you noticing.  Lastly, if the product doesn’t pass FCC/CE testing, who knows how to resolve it?  If you have any “custom” electronics made, the ODM will just hand the problem right back to you.

I’ll have much more to write about both PhatNoise, building startups, and other aspects of the consumer electronics business.  This list above is really just the tip of the iceberg, but this post is already waay too long.  In the meantime, please don’t hesitate to contact me through the comments below or via the methods on my about page.

I remember literally staring at the math behind my lab’s latest research work.  I was a student at UCLA, and our lab just was on a high from having made the cover story on Scientific American.  The lab worked on the (then hot hot hot) topic of reconfigurable computing.  Specifically, we worked on machines that would perform image correlation very quickly; my specific project performed at 12FPS running at just a 16MHz clock!

What struck me was that what the machine was doing could represent a more generic way of how machines performed mathematics — vector math, to be precise.  So over the course of about a summer, I wrote the following paper (I also wrote the actual C++ code that did the work, but can’t track it down!).  Here’s what that code could do:

Re-write the following equation, using simple arithmetic, so that all multiplies are done using powers of two, and with the fewest number of adds or subtracts:

There are 7 plus signs already — how many more will you need so that there are only powers of two? (Answer at the end of this post!)

This is exactly the sort of optimization that is needed to minimize hardware design complexity (a multiply by a power of two is just a shift, after all).  I loved this project because it transformed this algebraic problem into a graph coloring problem, and by doing so, allows computers to do all the dirty work.  For example, if you gave the code a fixed point representation of the DCT, it would optimize and transform the 8×8 matrix multiply to something that approximates the widely used version by Feig & Winograd.  Except it took the computer just about a day to do it.

Abstract

This  paper  presents  a method,  called  multiple  constant  multiplier trees  (MCMTs),   for  producing   optimized   reconfigurable   hardware implementations  of vector products.  An algorithm for generating  MCMTs has been developed and implemented, which is based on a novel representation  of common subexpressions  in constant  data patterns.  Our optimization  framework covers a wider solution space than previous approaches; it also supports exploitation  of full and partial  run-time  reconfiguration  as well as technology-specific constraints,  such as fanout limits and routing.  We demonstrate that while distributed arithmetic techniques require storage size exponential  in the number  of coefficients,  the resource utilization of MCMTs usually grows linearly with problem size.  MCMTs have been implemented in Xilinx 4000 and Virtex  FPGAs,  and their  size and speed  efficiency  are confirmed in comparisons  with  Xilinx  LogiCore  and ASIC implementations  of FIR filter designs.  Preliminary results show that the size of MCMT circuits is less than half of that of comparable distributed arithmetic cores.

Download the full paper (PDF), or browse through the paper below (it looks blurry cuz the font wasn’t properly embedded, crap.)

If you are still reading you must be dying to know the answer — well, in the paper I describe how to use only 10 additions and only powers of 2 multiplies. See if you can do it by hand!