17M Gates in 8 Months with 2 Designers -- What is Your ROI for Higher-Abstraction Design and Verification?

In their presentation at the recent SystemC Japan conference, Renesas Micro Systems, Inc. (RMS) stated 2 SystemC "beginners" completed a 17M gate design in 8 months, achieving first-pass timing closure at 650 MHz targeting 40nm.

Two thoughts came to my mind:

1. Wow!
2. What is their ROI of migrating from an RTL-driven methodology to a SystemC-driven methodology?

Thought #2 is the million-dollar question that design teams are facing today. The theoretical benefits of moving to a higher-level of abstraction for design have been discussed for a while -- faster design, faster verification turnaround, easier re-use, broader micro-architecture exploration, etc. But evolving your methodology upwards requires an investment in terms of tools, education, and methodology development. In today's business climate, management needs to understand what the return is for this investment.

The first thought that comes to mind with higher-level design is "productivity." Productivity is easily defined; I can go to Wikipedia and see that it is (output / labor hour). In this case we can easily divide the 17M gates by 16 engineer-months and get a hard number. For RMS to measure their ROI they can just compare this number to the gates-per-engineer-month for the RTL flow. Of course, not all designs require the same amount of effort, as described best by Ron Collett.  He also makes a good point that for most organizations, throughput is what matters.

Throughput matters because it is ultimately measured by time-to-market. But this is going to be project-dependent. We have a success story from Casio that cites a 50% reduction in the overall verification and debug cycle. If, like most projects, verification was in the critical path of the schedule, this could lead directly to faster time-to-market. How much faster of course depends on the project schedule. And the dollar value of this return is heavily dependent on the type of end-product and the competitive dynamics of its market. In Casio's case it was an image processor for one of their cameras, so the impact would be high. But if it were an automotive application, then the time-to-market value might not be as important as quality and reducing the risk of error.

Moving up in abstraction level can greatly reduce the risk of error. Humans are writing fewer lines of code at higher levels of abstraction, so there is less potential for bugs to be introduced. And more bugs can be identified earlier because you can have earlier models available for verification. There is a bonus if you employ a full TLM methodology where you start with a virtual prototype to run the software on, then refine it toward something that can be synthesized to hardware. That would enable broader system testing as well, which is often where we see field failures these days. Some field failures can be fixed with firmware updates, which can be inexpensive for a smartphone, but very expensive for an automobile. And some field failures that don't show up until system integration end up requiring a hardware fix, which will always be expensive.

We recently did an informal survey of our C-to-Silicon Compiler customers to see what value they were getting out of higher-level design and verification. Not surprisingly, two of the top three responses were faster verification turnaround, already discussed here, and easier IP re-use, which I discussed in a previous post -- that one can be measured in terms of both productivity as well as time-to-market.

The top response to the survey, however, was the ability to explore a broader micro-architecture solution space. This was also cited in that aforementioned Casio success story. Sometimes, as in Casio's case, this results in an area savings that is easy to measure the value of in terms of silicon real estate. Sometimes it results in faster throughput, which is more difficult to measure the value of. If it makes the chip more competitive, how much extra profit can it generate? A better micro-architecture for power falls in both camps -- it can mean a less expensive package or heat sink, whose value is easily measured, or it can mean a more competitive product.

As we talk to more customers about moving up to higher-level design and verification, we find that everybody has different goals in terms of what they are looking to get out of it. This is not a surprise, because companies have different goals and metrics due to the nature of their businesses. The good news is that there are a variety of metrics that moving design and verification up in abstraction can improve. This is why RTL became so universally adopted.

I am curious to hear your thoughts in the comments section regarding what return you look for when assessing whether to evolve your methodology to a higher level.

Jack Erickson