Project Phases

Specification
The most important part of a project is the initial specification which should inlude a verification plan. Any time spent upfront to carefully define the project will pay dividends.

A good specification document will define the tasks to be completed, the time required, any IP requirements and the verification methods to be used. This helps to define the cost of the project to some degree of accuracy. This is an area in which we often see companies spend less time than they should, which creates issues further into the design process. Another common problem is 'feature creep' - marketing hears about a new, emerging standard and decides that it must be included as a feature in a product that is already in design. Some of this is inevitable, the world of technology is always evolving, but be sure to examine the trade off between having each new feature included and getting the product out on time. If at all possible the product should be fully defined during the specification phase and then left unchanged.

We often engage with customers on an initial contract covering just the specification phase, usually on a time and materials basis. At the end of this phase we are able to deliver a full statement-of-work, project schedule and accurate estimate of hours required to complete the design. This makes the cost and schedule of the remainder of the development much more deterministic - which is good for both parties.

Verification plan
A formal verification plan should be included as part of the specification phase. This is an area that is often neglected. ASIC engineers typically spend 70% of their front-end effort on verification while some FPGA engineers will spend a lot less. There is a understandable tendency to debug FPGAs on the bench because the technology is reprogrammble and there is a trade off to be made between spending time on verification and time to market. However, as FPGAs get bigger and bigger, a more rigorous approach to verification must be applied as tracking down obscure or intermittent bugs in the lab can be very time consuming and inefficient. As a result, less time spent in verification up front results in even greater costs down the road. Since verification accounts for a substantial part of the front-end effort if is difficult to estimate the overall project effort without a clear specification of the verification process.

Coding and simulation
Once the specification is completed actual coding can begin. All coding is performed to our internal coding guidelines, unless the customer provides their own requirements. The design is coded in VHDL and/or Verilog, depending upon the customer's requirements and the languages of any IP or pre-existing code. We use Modelsim for in-house simulation, however with special arrangements we can accommodate a customer's request to use an alternate simulator.

Functional verification
For most projects of any complexity functional verification occurs in two stages. The first stage is performed at the module level and is typcially "white box" oriented in that specific functions and interface behaviors of the module are targetted using knowledge of the implementation. Once the modules pass this stage of verification device integration takes place and verification moves to the top level. This second stage of verification adds "black box" testing which is more oriented toward the real use of the device with less emphasis on the implementation. The completeness of verification is determined by completion of the requisit tests, coverage metrics and any other critiera indicated in the verification plan.

Synthesis
The completed RTL is now synthesized into a gate level netlist suitable for the selected technology. For Altera FPGA designs synthesis is performed by the Quartus tool suite, with also performs place and route. Synopsys remains the synthesis tool of choice for ASIC designs. In an ASIC flow timing will be checked at this point against a simulated layout to make sure there are no obvious problems. (Since FPGA layout is very quick, timing checks are usually performed as the final step in the synthesis, place and route flow.)

Back-end
A synthesized netlist now needs to be converted into an actual chip design by laying out the logic and checking timing against the developed constraints. FPGA vendors all provide their own tools for this step and the process can often be completed within a few hours - at which point you have a completed design! For ASICs and structured ASICs, the process is a bit more complex - clock trees and scan chains have to be added to the design. Now the actual layout of the chip begins - which is were structured ASICs have a great advantage over full custom ASICs. For a structured ASIC design, only metal layers remain to be completed which can be done relatively quickly and timing is very easy to meet as the chip has most of the possible variations already designed into it. For a full ASIC all layers must be created from the ground up, I/O's must be placed, power planes designed and signal integrity checked, etc. This can be a long and iterative process.

A successful project rests above all on the up-front work in the specification phase. Once this is completed and a statement of work generated, the rest of the project should go relatively smoothly.




Copyright 2010 Octera Corporation.