MicroZed Chronicles: Estimating FPGA Development Times

As a consultant, correctly estimating the time it will take to develop an FPGA or module can mean the difference between making a profit or a loss.

If a development takes longer than I expected, it has a double impact. It not only delays payment but also means I can’t start on the next project.

Apparently, I am not alone in this challenge. Respondents to the AspenCore embedded survey indicated that achieving project deadlines was their major challenge.

To aid in this process, I have an established system for estimating the timescale, complexity, and cost of the development that I am being asked to quote. Some of the high-level things I consider are:

1. Are the requirements clearly defined? Does a requirement base exist and is it stable or subject to considerable change?

2. What is the development standard of the FPGA (is it IEC61508 / ISO26262 or ESA-Q60 for example)? These standards can drive considerable process and review effort which needs to be accounted for.

3. What is the architecture of the design? Start with a basic top down top-level diagram and try to identify all the major functions within the design.

4. What IP will I use in the development? This will be a mix of free IP included in the tool and purchased IP which will hopefully reduce the development timescale. Of course, what I cannot source as IP will need to be written from scratch.

5. What is the level of verification required and is independent test benching and verification required? Independent verification is common in high reliability and mission-critical applications.

6. What is the Technology Readiness Level (TRL)? This is a great indication of the technical risk that the project is facing. Assigning TRL to function in the design, especially new and advanced elements, can be a good indication of where there might be technical risk that needs to be retired. One recent example was for customer who desired the RFSoC to do some very fine frequency and phase adjustments across a wide frequency range.

7. Lessons learned from previous similar developments. Did these developments lead to over running on the delivery milestones? If so, what was the reason and could it apply to this development?

8. What is the tool chain being used? Is it established, mature, and capable? The FPGA vendors’ tools range in capability from reasonably good to shocking.

Of course, there are many other aspects to take into consideration like availability of input information and hardware and the need to travel for integration and contingency. Normally I build in some contingency into the project. On large projects (> £100K), this can be considerable and can be held by the client.

These developments are normally paid when milestones are achieved. These could include agreement of requirements, architecture, delivery of the source and verification code, completion of integration, for example.

I was curious to see how other engineers developed their timescales, so I thought I would ask on r/fpga. The responses were remarkably interesting. One respondent indicated they just took a WAG as 25% was automatically added by their employer on any FPGA development timescales. Another commented, “I've found that the estimate asymptotically approaches the market deadline defined by sales/marketing. Delivery, however, usually ends up being closer to the initial, much longer, estimate.” This is a statement that I think anyone who has worked in the industry a while will be familiar with.

Of course, what drives the development timescales outside of the initial estimates are the issues encountered as the design develops. These issues can range from being tool chain related, as bugs or capability issues are identified, to having design and timing closure issues because technically challenging areas of the design take considerably longer than expected. Identifying these issues and working around them can be a significant driver of long days, weekends, and stress.

Although I am not perfect and no project ever runs smoothly, my approach has helped me with many more successes than failures in my 21 years as a corporate professional and seven years as a consultant.

How do you estimate your design effort? Timescales?