Using IXP2400/2800 Development Tools: A Hands-on Approach to Network Processor Software Design

Finally, that fast packet quit ringing her bell, and started down the river but she hadn't gone mor'n a mile, till she ran clean up on top of a sand-bar, whar she stuck till plum one o'clock, spite of the Captain's swearin'.
Mark Twain
Now you have the simulation running. The packet generator is sending packets in to the Intel IXP2800 Network Processor. You've established output log files to capture packets for each transmit port. You look in the files, and what do you see? Mostly garbage and an occasional packet! Or perhaps you have garbage in, packets out, as shown in Figure 14.1. This chaos is typical of the second microsecond in the life of packets that are thrust upon an untested design.
In the old days that is, before you read this chapter you had to look in the output log file, scan through packet data, and when you found something that was not right, you had to figure out which packet contained the error and approximate the cycles in which the erroneous packet went through the chip simulator. To do so, you probably restarted the simulation and ran it until the packet appeared in the log file. You subtracted about 1400 cycles from that time. Then you reran simulation again to the beginning of the 1400-cycle period. Then you had to guess which code most probably had last touched the packet. It is even worse if...