S12X slower than S12??

[khumphri]

This message contains an entire topic ported from a separate forum. The original message and all replies are in this single message. We have seeded this new forum with selected information that we expect will be of value to you as you search for answers to your questions.

Posted: Thu Jul 28, 2005  5:03 am

I have some time critical code that writes words to PORTAB at location $0000. On the S12DP256, I use MOVW 2,X+,PORTAB. This takes 5 machine cycles.

When running this same code on the XDP512, the same instruction executes in 6 cycles, even though the new 12X cpu manual says this instruction should now require only 4 cycles.

I did some tests using STAA PORTA, and it seems there is a wait state inserted when writing to PORTA. I haven't tested any other registers yet.

Is this chip slower than the S12 for parallel IO?

---

 

Posted: Thu Jul 28, 2005  6:55 am

On the S12X accesses to registers that would be to a PRU (Port Replacement Unit) register in a full-emulator environment take 2 ECLK cycles to complete (even when operating not in an emulator environment). The reason is so the timing of such accesses will be identical in the full-emulator environment, and in the stand-alone environment. There are a total of 22 PRU registers on the S12X, and these are documented in section 23.5.2 in the S12X manual. S12X accesses to all other registers and internal memory resources take only 1 ECLK cycle to complete.

So what's slower on the S12X is the accesses to the PRU registers, not the MOVW or MOVB instruction. In any case you are right that as a result of the above the specific instruction MOVW 2,X+,PORTAB takes 6 ECLKs on the S12X as oppose to 5 ECLKs on the HCS12.

---

Posted: Thu Jul 28, 2005  9:57 am

MOVW IDX,EXT with src and dst aligned should take 4 cycles on S12X (was 5 cycles on S12). Destination address is PRU and I think instruction should take one cycle longer, not two. Maybe source is also PRU, or misaligned flash?

BTW it's hard to find in docs if XDP512 misaligned RAM accesses still take single cycle or indeed two.

---

 

Posted: Thu Jul 28, 2005  11:27 am

No, MOVW IDX,EXT is actually 5 ECLKs long also on the S12X. The S12X documentation is wrong in the S12X access details for all the MOVB and MOVW instructions. I reported these documentation mistakes to the Freescale design team more than a year ago, but maybe it was forgotten.

The MOVW IDX,EXT instruction opcode is 5 bytes long. It therefore must have 2 P cycles (to fetch 16 bit words) and one O cycle for a conditional fetch of a 16 bit word (depending if the instruction starts in an even or odd address). Thus the MOVW IDX,EXT access details that are shown in the data sheets "RPPW" for the S12X cannot be correct. The actual sequence is most likely "ORPPW", or some other order of these 5 cycles. I have also tested this in practice in the past, and found what I write ere to be true in practice too.

I will contact the Freescale design team about this again to see that the documentation is fixed appropriately.

---

 

Posted: Thu Jul 28, 2005  4:44 pm

> No, MOVW IDX,EXT is actually 5 ECLKs long also on the S12X.

> The S12X documentation is wrong in the S12X access details for all

> the MOVB and MOVW instructions. I reported these documentation

> mistakes to the Freescale design team more than a year ago, but
> maybe it was forgotten.

I hear ya. I am still trying to convince Freescale that the 9S12C32 does not have 2000000 (2 Megabytes) of internal RAM!

---

 

Posted: Thu Jul 28, 2005  4:59 pm

> > No, MOVW IDX,EXT is actually 5 ECLKs long also on the S12X.

> > The S12X documentation is wrong in the S12X access details for all

> > the MOVB and MOVW instructions. I reported these documentation

> > mistakes to the Freescale design team more than a year ago, but

> > maybe it was forgotten.

>

>I hear ya. I am still trying to convince Freescale that the 9S12C32

>does not have 2000000 (2 Megabytes) of internal RAM!

In my specific case, Freescale have been usually very good in responding to my remarks, and when necessary fix the documentation, and often the silicon as appropriate.

Just in this one isolated case of the MOVB and MOVW instructions the documentation access details is not compatible with reality, and it hasn't been fixed in spite of my reporting. But Freescale are usually very good at this from my perspective, and in my own experience.