Dropping the BOM
Volume Up, Cost Down

We’ve happily harnessed the hurry-up, speed-racer, super-fast, time-to-market advantages of programmable logic. Our product got there first, and ran virtually unopposed in the critical, market-share-sweeping early days. We rule! Now, however, we are victims of our own success. Fast-following competitors have arrived on the scene with “me too” knock-off products, and it’s time for us to kick our game back into high gear. At the same time as we’re adding a few nice second-generation differentiators to our offering, we also have to reduce our costs to the absolute minimum. We want to have it all – more market share, better features, and the lowest price with the highest margin. It’s time to roll up our sleeves and whittle that bill of materials (BOM) back to the bare bones.

The Secret Sauce

Our first stop is our own design. We have to identify the essence of what makes our system special. We need to put it in a saucepan with some dry white wine and slowly simmer it down until everything boils away except for the really tasty, gooey part that sets our product apart from all others. Once this is identified, we’ll divide our efforts between building the most cost-effective implementation of our secret sauce and buying the best combination of standard functions to finish out the project.

Fighting NIH (Not Invented Here syndrome)

In the process of building any system for the first time, we accidentally re-invent a lot of wheels. This is normal and fine, but when it’s time to cost-reduce we have to be pragmatic. Even if we spent weeks designing what we think is the worlds coolest Ethernet MAC, our next-gen system probably won’t win or lose because of it, or because of our cool dual-port RAM controller, or because of any bread-and-butter function that’s available in standard IP. We’ll be identifying all of the non-differentiating components in our design and looking for the lowest-cost, lowest-risk, least-design-effort method of incorporating them into our new system.

Next, we should visit the ASSP and standard parts catalogs. Did somebody come out with a chipset to do some, most, or even all of what we did by hand in our first generation? If so, it will probably (but not definitely – more on this later) be cheaper, faster, lower power, and/or all of the above, than our current programmable solution. In particular, if our version 1.0 system used one of the big, bad, expensive, super-FPGAs (like a Xilinx Virtex or Altera Stratix) for some integrated computational heavy lifting, we might be able to replace it with an ASSP plus a really cheap (Spartan-3, Cyclone-II, ProASIC-3, or Lattice EC) FPGA containing nothing but our highly-refined, digitally-distilled, intellectual prowess from the “Secret Sauce” step above. These FPGAs are so cheap, they can take the ride with us right up to volumes in the millions without biting our BOM in the behind.

When we pick one of these FPGAs, we have to shop very carefully. This is probably the most hotly contested segment of the programmable logic market, and it is very important to separate marketing hype from reality. There are many vendors and options to choose from, and it seems a new family is being introduced every few months, so our search will be fairly broad. Don’t narrow it prematurely, though, because there are very distinct and viable reasons to consider each option. We’ll be looping through a series of considerations like availability, suitability, price, and total system cost to hone in on our ideal device.

Since the low-cost FPGA market is so competitive, vendors tend to announce early. While it’s nice to know what’s coming down the pipe, we don’t want to hang our hat on a particular device based on its “announcement” and find ourselves with a bunch of blank circuit boards awaiting delivery of parts - just as soon as the vendor gets those last few process bugs ironed out. Our boss will not be impressed, and our customers will be enjoying our competitors’ fine products. Make sure you know that your vendor can deliver in the volume you need at the time you need, and have a backup plan.

Since the low-cost FPGA market is so competitive, vendors tend to overstate the density of their devices. It might look good to be buying a million marvel-gates for a pico-pence, but what we really need to know is whether our design will fit the device we’re considering (and not – oops, in a one-size-larger version that costs 30% more and blows our whole pricing plan out of the water). The only way to get a high-confidence answer to this question is to run our design through the tool flow (including place-and-route) and get a 100% fit. While that takes some effort, it is easier if we have a vendor-neutral EDA flow and if our design is ready to synthesize already.

Since the low-cost FPGA market is so competitive, vendors tend to overstate the performance characteristics of their devices. The datasheet’s 600MHz may sound like all the performance we’ll ever need, but it’s also more than we’ll ever get, unless our design happens to be something like… an inverter. The problem, penalty, and solution here are much like those in the paragraph above. If we can’t meet timing and have to go up a speed grade to hit our constraints, we add that nasty 30% cost penalty again, and we’ll be counting our shoelaces while our manager mentions politely that engineers could use a bit more accounting training in school. Again, if we can pre-prove our design through the tool flow, we’ll know whether we can hit the magic numbers or not.

Since the low-cost FPGA market is so competitive (this is the last one, I promise), vendors tend to publish pricing in bizarre and cryptic ways. While it might be cool to consider that a part like ours will be available for eleven cents in quantity ten million at the end of two thousand eight, what we really need to know is how much we’ll have to pay in the quantity we’re ordering at the time we actually need them (assuming they’ve already passed the availability test above). What we should do in this case is to be very impressed with all the marketing messages, and then call our favorite distributor for an actual quote. That’s the price we should factor into our planning. We won’t bother trying to correlate the two. It’s a waste of engineering time and an exercise in futility.

The last thing to factor into our spreadsheet is the “other” costs of an FPGA-based solution. Just picking the cheapest chip doesn’t mean we’ve necessarily come up with the lowest-cost answer. We need to add up the total system cost with various options, factoring in configuration logic (or lack thereof for non-volatile FPGAs such as Actel’s ProASIC lines), power supply considerations, packaging and mounting costs, and board area. In the old days, when the FPGA had a three- or four-digit price tag, the device cost dominated the equation and nothing else mattered. Now that FPGAs can be had for the price of popcorn, we need to think about the cost of the bag.

Increasing Integration Intensity

What if there’s no ASSP available, or if we really need a more integrated solution than the side-car, super-cheap FPGA? It’s probably structured ASIC time. Don’t let the “ASIC” part strike fear and anxiety into your heart. These are kinder, gentler ASICs – fully domesticated and safe even for engineers with a fear of choking on high-risk design and massive NREs. We generally won’t need to purchase extensive, expensive EDA ASIC tool suites, as most vendors use a suspiciously FPGA-like design flow. Our non-recurring engineering (NRE) costs will have about two fewer digits than a full-blown cell-based ASIC, and our design schedule will normally be a single-digit number of months.

When we turn to the structured ASIC solution, there are two basic tracks we can follow, depending on our needs. Option 1 is a direct mapping from our FPGA vendor. Currently, Altera offers the only “true” structured ASIC conversion with their HardCopy (and HardCopy II) families. Altera can take a working design (implemented in a Stratix or Stratix II device) and create a structured ASIC implementation that is a direct one-to-one replacement for the FPGA. The structured ASIC is a true, mask-programmed part with better performance, lower power consumption, and, most significantly, much lower cost than the original high-end FPGA. Design risk is reduced to the absolute minimum, because the whole process from FPGA to ASIC is done through one vendor in a transparent (from the customer perspective) process.

Xilinx’s answer to the cost-reduction dilemma is a bit more crafty and confusing, but can still get the job done. Their solution, called “EasyPath,” is still an FPGA of the same type as our original design. We send Xilinx a set of vectors to test our components, and they send us parts that pass our tests. Because these parts are qualified only with our particular design in mind, they’re not fully tested to be reprogrammable like “normal” FPGAs, but they are available at a much lower price if all we want to do is cost-reduce our existing circuit.

If we need more density than a one-to-one FPGA mapping can provide, it’s time to look at the heavier structured/platform ASIC offerings like those from ChipX, LSI Logic, NEC, and others. These devices tend to have more density, higher speeds, more robust IP offerings, and lower power than the previous options, but they require a longer, more rigorous conversion effort. As we mentioned above, the design flow will be similar to what we’ve experienced with FPGAs, but the process is more of a reset than a simple conversion.

The platform and structured ASIC market is also heating up and becoming highly competitive, but there are far fewer marketing misdirections to navigate here than back in FPGA land. Gate counts will be given ASIC-style, so don’t try to compare them with density ratings from FPGA vendors. A two-million-gate structured ASIC is much, much larger than a two-million-“system”-gate FPGA. Operating frequencies also tend to be much more conservatively stated, and pricing options seem somewhat more straightforward.

The determining factor in structured ASIC selection will often be the static/hard-IP offering. When we filter all those standard parts out from our secret sauce above, there are probably a few of them that are expensive and performance-critical enough to require a “hard” implementation instead of being dropped in as soft-IP using synthesizable VHDL or Verilog. The hard-IP we’re worried about will usually be things like block RAM, high-speed multipliers, or I/O standards that have a “phy” component. If we choose a device that has the hard-IP our design requires, the soft part of the design that goes in the programmable fabric will probably work itself out in the wash.

ChipX, for example, has developed a line of structured ASIC that includes hard-wired USB capability. If our design requires a USB interface, we can probably save money, complexity, and board space by using one of their devices with USB built-in, rather than putting our secret sauce into a different device with an external USB set. Similarly, LSI Logic has an extensive set of SerDes I/O capabilities in their RapidChip line that would have to be handled externally in most other solutions. By picking a structured ASIC slice that has the hard-IP we need, our final design will usually be simpler, smaller, and cheaper.

The mindset for cost reduction is considerably different from what we needed to get to market quickly in the first place. If we’re going to have a successful product line that lasts, we have to maintain the engineering discipline to recognize and excel at both games. Reducing cost may not provide the same adrenaline rush as burning the midnight oil to get a new product on the shelves before our competitor, but the results can be even more rewarding, and the engineering challenge is equally worthy.

Kevin Morris, FPGA and Programmable Logic Journal

August 23, 2005

[back to top]

Comments on this article? Send them to comments@fpgajournal.com