s far fewer branch instruc- tions. As a result, the executable code will have better performance. Figure 10.4 summarizes this approach. The figure resembles a typical integrated circuit design flow except with two major differences: the underlying hardware and the instruction set of the embed- ded code can be changed in order to optimize performance, and the actual software development tools are automatically modified to reflect the latest changes, SO they can match the development require- ments and context perfectly. The toolset is made up of the following: A standalone tailor-made GNU C/C + + compiler. An assembler/disassembler. A linker. Downloaded from Digital Engineering Library @ McGraw-Hill (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 176 NETWORK PROCESSORS Instruction Instruction Instruction I: Instruction Fetch cycle Cache Instruction General R: Instruction Decode and Coprocessor Decode Register Fetch cycle Registers Registers E: Execute/Effective Address cycle Address Generation Coprocessor Xtensa Local M: Memory Access/ Memory Cache Branch Complete Interface cycle Exception W: Write Back cycle Resolution & Write Back FIGURE 10.5 Five-stage Xtensa pipeline implementation. (Source: Tensilica) A debugger. A cycle-accurate instruction set simulator. An advanced code profiler as shown later in Figure 10.10 that allows the fine-comb scanning of the application at hand looking for oversolicited resources, potential conflicts, bottlenecks of perform- ance, and SO on. If the user's initial software analysis shows some areas of poor performance, especially in con- junction with the underlying architecture, some hardware resources (MAC, multipliers, registers, ALUs, comparators, and SO on) or more specialized instructions may need to be added. If optional hardware additions must be made, the company allows the c