bigmac wrote:
I agree on Mac,when he says as an programmer, one need not really worry about the instruction execution details in deep like timing of each micro execution details. All he needs to know( mainly assembly programmers - for say better code which executes in less time) is the timing period of entire execution of each instruction.Normally time for each instructions will be in terms of micro seconds or less. Obviously there has to be some common reference unit/terminology for their measurement.Here the common reference unit is BUSCLK. When some one says one instr takes 5 BUSCLKs he says total time taken is 5 times the bus clock.But that doesn't mean that CPU clock (core activities) are not involved during this time.Surely a good part of it will be involved.
Same info is mentioned in HCS08RMv1/D Rev. 2 05 Page
I also agree that "Each instruction will always take a specific number of bus cycles to execute, and is not affected by preceeding instructions. The execution cycles required for a block of assembly code is totally deterministic. "
My concern about "bottleneck" had got nothing to do with as an programmer but as an processor architecture enthusiast !!!!
My concern about the " bottleneck" is within the execution of a SINGLE instruction and not with the series of instructions aka preceeding instructions. Bottleneck between the core (say max speed 40 MHz and hence more throughput) and the write block (max speed of 20Mhz ).You can compare this to the Bucket with a hole in the bottom side . 
Yes!!! Bucket is filled with water.Now with the hosepipe you are filling water a faster rate than (say twice) the speed of water trickling out from the bottom side.It works fine for some time, then water obviously will overflow.What does that mean ?? Wasn't there a bottleneck condition at the junction of incoming water and outgoing from bucket ?This is what I was trying to convince.
Fine!!! Anyway I got the answer from Fabio where he suggests that HCS core (CONTROL AND EXECUTION BLOCKS )needs to do MORE things before write block becomes ready, and hence increase in the speed of core clock..
May be, if this CPUclock was slow(than the current twice speed) and HCS core had not completed its tasks before write block was ready, obviously the write block had to wait until the EXECUTION BLOCKS gives its result to write block (Bucket empty condition).Seeing all these possibilities Freescale hardware designers might have given the CPU clock a higher speed compared to bus clock.And hence no overflow or empty condition....Everything has got to do with HW hardwired logic. SW Programmers have no control over them. All they want is the time of each instruction.Here the time is measured interms of BUSCLK!!! (reference **bleep** for measurement of instructions)
Best regards Denn
Denn wrote:My doubt still remains unanswered.What about bottleneck!!!! between the execution phase (CPU clk) and write phase( Bus clock)...
N.B: This was not a problem in HC08 micros because bus= cpu clk , but in HCS08 bus clk=1/2( cpu clk)There surely will be bottleneck condition....ultimately bus clk dictates the entire speed of the MCU!!!
Message Edited by bigmac on 2008-03-05 12:01 AM
Again no much info abt pipeline .!!!
To avoid confusion...A single consistent point of reference...--> Bus Clock..That doesnot mean that CPU clock is not used anywhere during instruction execution. As Mac has pointed out it is used for timing inside the CPU core.
If I read again "a single consistent point of reference so other system timing can be related to this common reference" so other system timing =??? Is this not CPU clock ??
If one sees in the instruction execution in terms of bus clock , alphabets like p,r,s,u,v,w and finally f is used.
f — Free cycle. This indicates a cycle where the CPU does not require use of the system buses. An f cycle is always one cycle of the system bus clock.
System buses are not used during f !!!! Couldn't this be the time utilised for decoding in Instruction Register and executing operations in ALU ???
How can you equate bus clock for core operations?? I don't see any logic behind this.
fabio wrote:
1- In the HC08, the BUSCLK signal is one fourth of the CPUCLK. This means that the instruction-rate is one-half of the HCS08.
I cross checked in AN2717, "M68HC08 to HCS08 Transition " it is said (page-6 .section 4.1) "CPU vs. Bus Clock
The M68HC08 CPU clock is equal to the bus clock. The HCS08 CPU clock is twice the speed of the bus"
Then how can the instruction rate of HC908 MCUs be one half of HCS series MCUs.???
Even if it was so , I don't know how you could relate CPU clock with Bus Clock in a linear way.Both are involved in different places one on bus activity and other on core activity.
fabio wrote:2- The HCS08 do not implement a pipeline, instead, they use an three-byte instruction queue (which is just a prefetch buffer, simpler than a pipeline). This instruction queue allowed the designers to reduce the CPI (clock per instruction) for many HC05 instructions.
operand information available to the CPU immediately at the start of an instruction. Without the queue,
the CPU would have to spend the first few cycles of an instruction waiting for the program information to
be fetched into the CPU. "
What about bottleneck!!!! between the execution phase (CPU clk) and write phase( Bus clock)...I am really CONFUSED !!!!!In reply to your Service Request SR 1-425437386:
CPU vs. BUS clocks:
******************
Well, you can forget CPU frequency. It is only marketing. It is useless for comparing HC08 and S08.
The S08 family use the same instructions as the HC08. (Four instructions have been added in S08 CPU) All instructions execution times are specified in Bus cycles on either S08 and HC08.
Many instructions have slightly different cycle counts on S08 compared to the M68HC08 Family.
But the main difference between the two families is that S08 maximum bus speed is 20 MHz and HC08 was 8 MHz.
Furthermore , the three of the four new S08 instructions improve C code compiler efficiency. The efficiency is improved in both code size and cycle counts.
