I haven't been able to count instructions and convert them into execution time for decades. There's always something else inside the CPU, in the cache or memory controller to get in the way of those assumptions.
You should either program the chip to emit a signal derived from the CPU clock to a pin, or program a timer and have it drive an external pin. Otherwise have the CPU monitor the timer and flash a LED when it overflows/times-out/whatever. That's the safest way to monitor "the CPU clock".
I assume you're running with the cache disabled, in which case the CPU might be able to execute one instruction per clock, but it has to read them from whatever memory your code is in. Are you running from SRAM or FLASH?
The CPU is meant to run at up to 132MHz, so the peripherals and memory probably have wait states.
The SRAM gives 0, 1 or 2 wait states depending on the previous operation. Are you sure the Crossbar is set up to allow direct CPU access to the SRAM? On other families of chips (that use the Crossbar module)
If you haven't reprogrammed it, the FLASH defaults to 7 wait states.
Are you accessing the FLASH at its base address or at one of the "Internal Flash External Emulation Mode" mirror addresses? That can add up to 31 wait states.
How fast do you think the CPU can "write to a LED"? I've programmed a PXA320 that took TWO HUNDRED CPU CLOCKS just to write to an LED on an I/O pin!
The Freescale MCF5329 (a far simpler chip than the MPC5554) takes 18 CPU clocks to write to an I/O pin and 33 clocks to perform a read-modify-write with "port |= bit". That's because the I/O register hardware is usually on the other side of one or more "bridges" and is running at a slower clock than the CPU is. That's most likely what you're seeing here.
Tom
