VC Blog by Guy Kawasaki
Static vs. Dynamic Partitions

Defining "Ship Then Test" For Chip Design

When a company like Intel builds a microprocessor they have the luxury of throwing massive engineering, marketing, and sales teams at the problem.  The architecture and marketing teams will work with major customers to ensure the product being built will be well received by end users.  Quality is a major concern and due to the amount of time it can take to do a respin and requal of custom silicon, it's important to get things right the first time (or close to it).  But what about a startup with far more limited resources?  How do you balance the need for a quality product with the importance of getting the product into a customer's hands as quickly as possible?  Software companies will often ship a product before it is ready and rely on users to help them with the testing and development process.  Is such a feedback loop even possible with a product that requires ASIC development?

Guy Kawasaki, a venture capitalist and columnist for recently wrote an interesting article entitled The Art of Bootstrapping. In it he describes what to do if you find yourself trying to get your company off the ground without the help of venture capital.  He makes several interesting suggestions, but number three - "Ship, then test" caught my attention.

...When your product or service is ”good enough,“ get it out because cash flows when you start shipping. Besides perfection doesn't necessarily come with time--more unwanted features do. By shipping, you'll also learn what your customers truly want you to fix. It's definitely a tradeoff: your reputation versus cash flow, so you can't ship pure crap. But you can't wait for perfection either...

It makes sense.  Get something basic working as fast as possible and get it out the door.  Use customer feedback to fine tune the product until you get it right.  If you delve deeper though, you'll realize this is just as difficult to argue with as it is to execute.  The question is how would one go about applying this principle to a startup working on an ASIC?

Your first reaction might be that a self-funded startup has no business building an ASIC as its first product.  Fair enough, though I've been at a startup that was funded that way.  If it makes you feel better, assume we're talking about a funded startup where you're trying to minimize VC influence.

Assuming a preliminary architecture specification exists and has been passed around to some potential customers (you do have some, right?), the first task is to decide on a base set of features that must be present in the product for it to have even the most basic of functionality.  For example, if your product is going to be a PCI-Express based card with an Ethernet interface, the PCI-Express and Ethernet ports need to be working.  That SSL offload engine you're working on that you think your customers will dive head over heals for is an entirely different story.  How many connections does it need to support?  What type of throughput?  Following Guy's argument you might suspect you ought to make the problem as easy as possible and put together a prototype that can serve as a proof of concept.  That would mean supporting the smallest possible number of connections and the worst-case throughput.  Once your customers have samples you can begin working on the optimized version.  There's only one small problem.  There is a tremendous amount of work that goes into designing and verifying even a minor respin of an ASIC.  Add on to that the several weeks of lead time it takes to get back new samples (which must be validated in the lab at least a little bit before heading to a customer).  By the time you've updated the product to meet new requirements you may find you're customer has found better things to do with its time (and you may be out of money!). 

Another option is to design in as much configurability as possible - including doing much of the required work in software.  Make the hardware as simple as possible and use embedded microcontrollers to do the rest of the work.  Sure, the part will be slow, but you'll have something working.  This could be a good option if performance is not critical to your product (at least, for the first version).  If performance is a concern, you'll find yourself in trouble with this approach.  You may also find you have to redo the entire architecture of your product before it becomes commercially viable.  Another gotcha here is the added verification burden of making the part too configurable.  If you end up with a design with multiple embedded cores and the ability to reroute data around the chip as needed to work around bugs, you'll be popular with your customers, but what if you can't get it to work in the first place?  As discussed earlier, a lot of verification work goes into getting a chip out the door.  The more features you add, the worse it gets. 

So far I haven't mentioned FPGA prototyping.  I think there are a lot of areas where FPGAs can come in handy during the development process.  If you can partition your design into a reasonable number of FPGAs you have a good shot of being able to produce a working sample for your customers before you're able to tape out.  Such an implementation can help work out kinks in software and find architectural issues.  The gotchas here are that they usually must be run at a much slower clock speed than the ASIC version and are notoriously difficult to debug.  If your design is complex enough to require an ASIC in the first place, it's likely to contain some nasty bugs that will be difficult to find if you skimp on building a verification environment and rely on the samples to wring out all the issues.

One final possibility is to make sure your customers are intimately involved in your product's architecture and development.  Make sure they get regular status updates, see results of simulations, and get to look at preliminary versions of software and design specifications.  If you're lucky you might even get them to help you with the implementation.  You'll also ensure you both are in sync when the chip is ready for production.  You'll also allow yourself time and resources to properly verify your product.  The end result should still be something with a limited set of features, but those features should be well tested and meet your customer's requirements.

I don't really have a good, generic answer as to how much emphasis you should put on the shipping vs. the testing when building your first product.  I'd love to hear about how the rest of you have handled the tradeoffs between getting a product in your customer's hands quickly and ensuring the quality of the end result.