 and after execution of each SW module and logging the cycle count readings in a logging database. This database is extracted to a host for offline analysis. Cycle counting is identifying which SW components (as such, their respective owners) are causing excessive CPU loading. As such, cycle counting is the baseline for focusing optimiza- tion effort and a useful tool in tracking optimization "actual" versus "target" numbers. Iteratively, the results of cycle counting in a product are input into the modeling baseline for the next generation, as such increasing accuracy and trust in the modeling HW/SW codesign approach. In case cycle counts are not readily available, we can use rule-of-thumb math: Write C-code, compile, and count additional lines of assembly. Assume a metric (say, 0.7-1) lines of assembly/CPU clock cycle. Chapter 9 Software performance 311 Write pseudocode and estimate 7 lines of Reduced Instruction Set Computer (RISC) assembly lines per simple line of C-code. Execute code on a core/SoC simulator, even if cycle accuracy is not guaranteed but only estimated. Example: Enhanced Common Public Radio Interface complexity analysis As an example of packet processing complexity analysis, let's look at eCPRI termination CPU cost. Performance requirements are defined by U-plane IQ termination and associated eCPRI (or equivalent) processing. This is broken down to the following: 1. eCPRI frame receive/transmit operation. This is everything that needs to happen to get the software to the start of the eCPRI header and typically handled by Data Plane Development Kit (DPDK) drivers and/or hardware components in the Network Interface Card. This includes the overhead in Linux to wake up and handle the eCPRI-received frames-even though this latency can be brought down to near-zero by means of moving toward a polling mode implementation or similar techniques. 2. eCPRI/Open Radio Access Network (O-RAN) FH C/U framing/deframing: Assumed implemented in software rather than hardware for this discussion, this is a (DPDK) 