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:
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
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
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
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.