trix 6354.99 951.12 EncodeAC 7177.29 822.30 ChenDct 7956.46 779.17 FrequencyAC 8614.65 658.20 Preshi ftDctMatrix 9209.36 594.71 ZigzagMatrix 9701.90 492.54 82.09 82.09 SortInput 9959.11 257.21 13969 mulsi3 FIGURE 10.10 A performance analysis of custom-written code is done with Tensilica's profiler, which allows the detec- tion of bottlenecks and the generation of statistics as to which subroutines, function calls, and operations occur during most of the time. This allows the definition of new instructions when and where needed, which will simply imply one more iteration in the cycle. (Source: Tensilica) Downloaded from Digital Engineering Library @ McGraw-Hi (www.digitalengineeringlibrary.com) Copyright © 2004 The McGraw-Hill Companies. All rights reserved. Any use is subject to the Terms of Use as given at the website. ALTERNATIVE APPROACHES TO NETWORK PROCESSING: NET ASICS AND DESIGNING WITH IP CORES 182 NETWORK PROCESSORS surprise. However, if Y does this at 17 times the power consumption of X, then the argument can be made that the winner has not really Let us look at a real-life example that further corroborates the context and argument. IBM Microelectronics is working with a nondisclosed (as of the writing of this chapter) NEV to integrate the nontrivial quantity of 174 Xtensa RISC cores into one chip. In this case, IBM worked hard to trim down the individual core's gate count to around 92,000 per embedded processor in order to be able to fit the complete design in a die of 18 mmX18 mm using IBM's advanced thin-line lithography and copper-metal Cu-11 process, and to accommodate the staggering number of gates. Returning to the technical considerations of a systems architect coping with a network-processing challenge, even with a configurable processor at hand, the list of real problems starts looking like the following: Deciding upon the memory structure of the overall system and figuring out which processor has access, when it has access, through which bus and mechanism, to which memory subsystem, and under