st1\:*{behavior:url(#ieooui) }

4.4.3 Budgets and Scheduling

Budgets and schedules are key tools for effective project management. In developing a budget it is important to derive solid estimates. Historical data provides the best data points to use for the estimates. In the budget, include an appropriate “management reserve” to deal with issues that will come up during the project. When scheduling, include measurable and significant (individual and group) milestones in each phase of a schedule. Measure concrete results in the schedule when possible. Develop schedules with margin for mistakes and setbacks appropriate for the work environment and team. Allow team members time to research critical design decisions. Pace the work load versus efficiency and schedule; don’t schedule weekends and 55+ hour weeks on a long-term basis. Don’t rush into the implementation phase. It is better to suffer in the design phase than in the debug phase.

       As previously mentioned, there is commonly a significant gap between the amount of time and effort a design phase is perceived to require and the actual time and resources expended. In order to reduce a schedule, either the effort can be parallelized or short cuts can be taken. Parallel development is a critical element of schedule compression. Certain tasks make more sense to run in parallel, and some must remain serial for maximum efficiency. Sometimes certain shortcuts can be taken, but often there is a price to be paid further down the development cycle. Work to understand what the trade-offs of a particular “shortcut” might be. Often the end result is a wash in terms of schedule advantage or, worse, a net schedule loss. The following list of items may have a significant impact on a development schedule.

       Schedule Killers

       The design team and engineering management must be aware of the costs and impacts of design changes and updates at each stage of the design process. Large amounts of time, energy and budget can be saved if certain design changes are limited to the appropriate phase of the design cycle. Just because a change can be supported within an FPGA-based design dose not mean that it is necessarily reasonable or affordable to make that change.

       There is a tendency to simplify FPGA design flow to the concept that “more design change can be supported at a later phase of the design cycle than can be accommodated by other design implementation approaches.” While this statement is technically true, the reality is that even though it may be possible to support a change, the cost may be high enough that it is not reasonable to pursue implementing it. There is a significant risk that management teams will rush into FPGA-implemented designs early than is appropriate and accelerate design schedules so aggressively that the upfront schedule savings are consumed by the complications of trying to implement a design that was intentionally rushed into under the assumption that any required design changes or updates can be implemented within the FPGA.

       The objective of efficient design is to reduce or eliminate the expenditures of time, resources and effort re-implementing design functionality. The FPGA design cycle can become as efficient as the technology will allow if an efficient FPGA design process is followed. This requires careful management of individual FPGA design cycle processes and actions and reduction of design changes later in the design process.

       Many design issues may be avoided by focusing on determining the correct level of design margin, the required FPGA resources and effective design partitions. Design errors may be multiplied if critical early design decisions are rushed in order to get to the next design milestone. It is valuable to know which design tasks should be implemented with extra care of resources. Having the discipline to invert the extra effort into these tasks may result in a more efficient design implementation. If a design error is caught in an earlier design phase (ideally in the requirements or architecture phase), the cost to resolve the issue may be minimized. A majority of FPGA design mistakes are caused by not following practices and procedures that reduce or eliminate design oversights and mistakes.

       Focusing extra effort and resources on a design’s requirement document(s) can return significant schedule savings. Granted, few design requirements are complete before the design architecture and implementation phases are started, but rushing to start a project before the requirements are sufficient stable can be expensive in the long run. The challenge from a management perspective is determining when the design requirements are mature or complete enough to move into the design architecture and implementation phases. A sufficiently detailed concrete requirement document provides clear goals for the design architect and the design team.

Estimating the FPGA Design Cycle

The most accurate method of estimation is based on historical data. A historical-based estimation method requires access to measured and estimated metrics from previous projects. The team must collect the right information from a number of internal projects with a special focus on consumed resources (manpower and schedule) and influencing factors such as requirement stability and design team experience and continuity. Typical metrics include code size, complexity, and number of engineering resources, team member experience level, selected tools, schedules, and various other factors appropriate for tracking FPGA project status. The main objective of this approach is to develop a formal or informal database with real-world values, based on projects implemented under the organization’s typical operational constraints. As real-world design data is collected, future projects can be estimated based on prorated extrapolations. When deriving estimates, it is crucial to pay particular attention to any “new” element. This could include first FPGA design, first HDL, first mixed-mode HDL, first-time use of advanced tool features, or first hierarchical design. Each “new” element can add significant overhead and can also make estimation less accurate. For each “new” element, factor the learning curves into the estimates.

       One factor that can have a significant impact on estimated schedule duration is simulation. Depending on the thoroughness of the simulation effort, it may require a significant percentage of the overall project schedule. The required amount of simulation can vary greatly. A rule of thumb is to estimate that simulation should take between one to two times the amount of time that is scheduled to design and enter the system design. For smaller, less complex designs, or designs with significant reuse of pre-verified functionality, the simulation numbers should tend more toward the minimum estimate. While a point of diminishing returns will be reached with simulation, every hour of simulation prior to this point will generally be time well spent. Simulation, especially of lower-level blocks before they are integrated into larger assemblies, can significantly reduce the number of hours required to debug designs in the lab.

       After an estimate has been completed for a new project, it is important to record and store the estimates along with any contributing factors and assumptions. Post-project evaluation of estimated versus observed schedule can be very educational. An important element to improving future estimates is the careful tracking of factors affecting a project’s status and progress during the course of the project. At the completion of the development, this tracking data can then be used to clarify deviations from initial estimates. These refinements and a “lessons learned” report can be used to improve estimation results for future projects.

*博客内容为网友个人发布，仅代表博主个人观点，如有侵权请联系工作人员删除。