| Characterizing Licensable Core Performance |
By BDTI, 11/2/2006
Comparing licensable processor cores and quantifying their relative performance is challenging. Unlike processor chips, there are many different ways in which licensable cores can be configured, implemented, and fabricated, each of which yields a different combination of speed, area, and power consumption. Particularly for digital signal processing applications (which tend to push the limits on one or more of these metrics) it’s essential to have reliable and accurate performance data.
To make apples-to-apples comparisons between cores you’ll need to pin down a consistent set of assumptions. In this article, we’ll discuss some of the factors to consider when assessing and comparing licensable cores for digital signal processing.
What will you really get?Choosing a core requires a careful analysis of its speed, area, and power consumption. Making this assessment is difficult, however, because there are many factors that affect the speed you’ll get when you actually fabricate a chip.
The fabrication process in which a core is implemented has a profound effect on every aspect of its performance—including its speed, size, and power consumption. In general it doesn’t make sense to compare the performance of cores that have been fabbed in different processes; the performance characteristics of the cores themselves are likely to be obscured by differences in the fab processes. To make fair comparisons you’ll need to compare all the cores in the same process.
Even for a specific process, the clock speed and power consumption of a core will vary between fab runs. For this reason, core performance is typically specified in terms of worst-case and typical values.
SoC designers typically design their chips for worst-case clock speed—based on worst-case voltage, temperate and process parameters. This allows them to eliminate process variations as a variable in final performance, and avoids the cost of speed sorting. SoC designers, therefore, need to see benchmark results based on worst-case clock speeds.
Unfortunately, core vendors often base their benchmark results on typical clock speeds rather than worst-case, for obvious reasons. A common justification is that the core is being compared to off-the-shelf chips, which can be speed-sorted. From the SoC designer’s perspective, this is irrelevant—SoCs are rarely speed-sorted, so SoC developers need worst-case numbers.
Later is betterThe clock speed, power, and area reported for a core are known with varying degrees of certainty at different points in the implementation of a chip. To accurately assess and compare core performance, it’s best to use values that are generated after the core has been fully placed and routed. If the values are measured after synthesis but before place-and-route, they’re much less reliable. To help ensure consistency across cores, the values should be measured using industry-standard timing analysis tools and techniques.
The memory questionMost licensable processor cores allow you to connect your own memory subsystem; you can typically choose the size and speed of caches and other on-chip memory blocks. Unfortunately, when core vendors report performance, they sometimes make unreasonable assumptions about the memory system.
For example, a core vendor might assume that the core will be hooked up to prohibitively expensive high-speed memories, or make unrealistic assumptions about the cache size. An unrealistically large cache (or other L1 memory) may reduce cycle counts, but may be too slow to allow the core to run at full speed. Conversely, an unrealistically small cache may allow faster clock speeds at the expense of greater cycle counts. These kinds of assumptions can make the core look better than it really is.
Unfortunately, most core vendors don’t show their memory assumptions alongside their benchmark results. It can be difficult to figure out whether the speed results for cores from different vendors are really comparable (or whether they’re meaningful at all, for that matter).
|
|
|