4.4.3Budgets 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

• Requirements phase – incomplete, conflicting, poor, undocumented, excess change, change too late
• Architecture phase – poor implementation, poor structure
• Verification phase (iteration) simulation, debug, testing, verification
• Implementation phase – (IP configuration, testing, integration)
• [endif]-->Poor project management decisions or guidance
• Uninformed management decisions

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 or resources. Having the discipline to invest 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.

4.4.3预算和日 程安排

预算和日程是实现有效项目管理的关键工具。在制定预算时，得出切实可靠的评估是重要的。做出评估所需的最佳的数据点来自于历史数据。在预算中， 包含一项“管理预留”项来应对项目进行过程中可能会出现的问题。在日程的每一个阶段加入可测量的和显著的里程碑（个人的和团队的）。及时对这些切实的结果 （里程碑）进行测量。根据工作环境和团队的情况，制定日程计划时要给错误和挫折留出适当的余量。给团队成员留出时间来研究关键的设计决定。针对效率和日程 安排工作量；不要把周末休息时间和每周55个小时以上的工作时间列入长期的日程中。不要急于进入实现阶段。在设计阶段预留充分的时间要比在调试 阶段花时间解决设计阶段遗留的问题来得划算。

正如前面提到的，在设计阶段估算的时间和努力与真正花费的时间和资源通常存在显著的差异。为了缩短日 程，可以使工作并行化或者跳过某些阶段先行执行后面的工作。并行开发是日程压缩中一个关键的元素。某些任务并行执行更合理，但是有一些必须串行执行以达到 最佳的效率。有些时候，可以跳过某些任务以缩短开发时间，但是在设计周期的后期通常要花费相应的代价。应该下功夫权衡清楚某项具体“捷径”措施的收益和代 价。权衡的结果通常会是，在日程上获得的收益与付出的代价相抵，甚至得不偿失，造成延期。下面列出了对开发日程有显著影响的条目。

浪费日程的因素

1. [endif]-->由于本可避免 的原因而不得不重新实现设计中重要的部分（不完整的/相互矛盾的需求，在未取得切实的、经过评审的、达成共识的设计结构之前就开始设计输入，试图实现一个 划分欠佳或不当的设计）

< >需求定义阶段 ——不完整的、相互矛盾的、欠佳的、未写入文档的、过多的和太晚的需求变更 结构设计阶段 ——欠佳的设计，欠佳的结构 在设计验证阶 段进行的仿真、调试、测试和验证（这些反复的工作本应该在设计实现阶段完成） 设计实现阶段 ——IP核的配 置、测试和集成 欠佳的项目管 理决定或指导方向 欠佳的团队交 流 在信息不足的 情况下做出的管理决定

设计团队和工程管理人员必须了解在设计过程中的每一个阶段进行设计变更和设计更新的相应代价和影响。 某些设计变更如果被限制在设计周期的恰当阶段，可以节省大量的时间、精力和预算。基于FPGA的设计可以支持某项变更，并不意味着在设计中进行这项变更就一定是合理的和可承受的。

人们往往对FPGA设计流程存有这样一个简单化的观念：“在设计周期的后期能够比其他实现方法支持更多的设计变更”。 从FPGA的技术 特点上看这一论述是正确的；在现实中，虽然有可能支持某项变更，但是由于实现这一变更代价高昂，这样做并不合理。管理团队如果过早地（在需求尚未充分明确 和架构设计尚未成熟前）启动基于FPGA的设计，并制定一个过于紧张的日程表，风险就会很大。日程安排得如此紧张，以至于前期节省出来的时间 都被急于实现一个不成熟的设计导致的并发症抵消了。如此急于求成是基于这样一个错误的假设：任何必需的设计变更和更新都可以在FPGA上实现。

高效设计的目的是减少或消除由于返工造成的时间、资源和人力上的耗费。遵循高效的设计流程，FPGA设计周期可以实现技术上允许的最高 效率。实现这样的目标，需要谨慎地管理FPGA设计周期中的每一个环节和步骤，并且需要减少设计过程后期的设计变更。

通过专注于确定合适的设计余量、必需的FPGA资源和有效的设计划分，可以避免许多设计问题。为了到达下一个设计里程碑，贸然地制定关键的早期设 计决定，会导致设计错误加倍。弄清楚哪些设计任务应该在实现过程中投入额外的关心和资源是很有用的。针对这些任务投入额外的努力会产生更有效率的设计实 现，这一做法应该制度化。如果一个设计错误可以在更早的设计阶段（理想上是需求和架构阶段）被发现，解决这一问题的代价就更小。绝大多数的FPGA设计错误是由于没能遵循可以减少和 消除设计疏忽和错误的做法和步骤造成的。

对编写设计需求文档投入额外的努力和资源可以显著地节省开发日程。诚然，在设计架构和实现阶段开始之 前许多设计需求都是不完整的，但是从长远来看在需求没有充分稳定之前就急于启动一个项目是代价高昂的。从管理的角度来看，确定何时设计需求已经成熟和完整 到可以开始进入设计架构和实现阶段是一个挑战。编写一份内容详实的需求文档，能给设计架构师和设计团队提供清晰的目标。

评估FPGA的 设计周期

最准确的评估方法是基于历史数据的。基于历史的评估方法需要使用从以前的项目中测量和评估得到的参考 数据。设计团队必须从许多的内部项目中收集合适的信息，特别要收集资源消耗（人力和日程）和影响因素方面的信息，比如需求稳定性和设计团队的经验、设计团 队的连续性。典型的参考数据包括代码大小、复杂度和工程资源的数量、团队成员的经验水平、选取的工具、开发日程和其他各种适合于跟踪FPGA项目状态的因素。这种方法的主要目 的是采用真实数据建立一个正式或非正式的数据库，这些真实数据来自于在企业组织中典型的运营约束条件下实现的项目。收集到了真实的设计数据，未来的项目就 可以用等比外推法（prorated extrapolation）进行评估。在进行评估时，对任何“新”元素给与特殊的关注是至关重要的。所谓的“新”元素，可以包 括第一次使用FPGA进行设计，第一次使用HDL进行设计，第一次进行混合HDL设计，第一次使用工具的高级特性，和第一次进行层次化设计。每一项“新”元素会显著地增加开销，也 会使评估更加不精确。针对每一项“新”元素，把学习曲线作为一个因素加入到评估之中。

显著影响评估得到的开发时间的一个因素是仿真。随仿真工作的全面性而定，仿真可能会占用全部项目日程 中很大的一部份。必要的仿真工作量可能会在很大的范围内变化。一个经验法则是，把仿真需要的时间评估为，分配给系统设计和设计输入所需日程的一倍到两倍之 间。对于较小的、不太复杂的或者大量复用了预先验证过的功能的设计，对仿真时间的评估可以倾向于向最小评估值进行。尽管会遇到仿真收益递减点（a point of diminishing return with simulation），在这一点之前用于仿真的每一个小时大体上都是值得的。仿真，尤其是对底层模块在尚未集成到更大的 模块内部之前进行的仿真，可以显著地减少在实验室中调试设计所需要的时间。

在对一个新项目的评估完成后，对评估结果和任何起作用的因素和假设进行记录和保存是重要的。在项目完 成后，把预估的日程针对实际观察到的日程进行比较和评价是非常有教育意义的。提高未来项目的评估准确度的一个要素是对影响项目状 态和进度的因素进行全程的跟踪记录。在开发完成后，跟踪记录的数据可以被用来弄清楚实际的开发进度与最初的评估的偏差。对最初评估偏差的改进和 “经验教训”报告可以被用来改善未来项目的评估结果。