s is now extremely well understood by many engineering organizations, it remains a fact of life that the process is not sensitive to ongoing changes. An organization starts by deciding on and fully specifying the ASIC functionality, and the engineers proceed with its imple- mentation. Roughly 18 months down the road, a working product will come out of the production line and will hopefully operate as specified. What about the case where something must be either added to or modified in the originally speci- fied ASIC functionality? In this case, the answer is easy because the vendor has to stop the design work and restart the development work to avoid wasting precious time and money. The exact point of retreat obviously depends on the individual case. A user may have to go back to the hardware coding language source level (VHDL or Verilog), carry out the needed modifications, and resyn- thesize the hardware encoding against the underlying technology library. A user may also have to go back and recode the whole design. Sometimes the extent of the work is SO significant that it is easier to recode from scratch than it is to revamp obsolete or incorrect code. The specification disruption can be SO significant that the design has to start again from the beginning, incurring extra cost and time to market. For example, say marketing did not fully understand what the market was looking for. In that case, all the interim work of scripting, synthesizing, verifying, simulating, documenting, and SO on has probably vapor- ized. The precious time to market has been lost and the money needed for that work has essentially been thrown away, straining budgets and strangling metrics of profitability or return on investment (ROI). This is an unfortunate but all too real side effect of the ASIC design process, and its impor- tance should not be underestimated. Many product line managers have lost their jobs because they had to go to their boss one day to announce the following: There will be an extra n-month delay until the product a