MSP430 vs Au1100 Alchemy - the GPIO battle

Hello,

When I toggle a GPIO on my MSP430 processor I have (or at least I think I have :) a clean understanding of what happens. I can relate the frequency of the toggling to the instructions used and the clock speed of the CPU. Nothing strange happens.

The MSP430 runs the instructions below:

/* Put 0xAA in the r15 register. */ mov.b #-86, r15

/* Write the contents of r15 on port 4, that acts as an 8-pin output port. */ mov.b r15, &0x001d /* XOR the r15 register. */ xor.b #-1, r15 /* Jump to the 'write the contents...' instruction. */ jmp $-6

The last three instructions take care of the toggling and cost 8 cycles total. A full period takes two runs of 8 cycles each, hence 16 cycles. With a scope I nicely see a frequency of 1/2 MHz, exactly what I expect with my 8 MHz clock speed.

But when I try to do the same thing on my Au1100 Alchemy processor, it's a completely different world. The Au1100, a ferocious beast compared to the MSP430, is not able to toggle the GPIO that much faster. With my 400 MHz clock speed I can only toggle the GPIO at 6 MHz with the instructions below:

/* I will toggle GPIO3. */ li t9, 0x00000008 loop: /* First we output a high level on GPIO3. */ li t7, 0xB1900108 sw t9, 0(t7) /* Next we output a low level on GPIO3. */ li t7, 0xB190010C sw t9, 0(t7) /* continue up untill the end of time. */ b loop nop

Of course I am comparing two completely different architectures and that's probably where I screw up. But how exactly does the Au1100 work? I can't seem to find any information about it in the data book or anywhere else, but suspect that the Au1100 has some internal mechanism that samples the registers to set and reset the GPIO at a certain frequency. And that this frequency is the maximum toggle frequency I get.

Does anybode got more insight in this and is willing to share? Thanks in advance!

1 groet, Freddy Spierenburg
Reply to
Freddy.Spierenburg
Loading thread data ...

Fast processors like that make use of heavy pipelining, both in the CPU and internal buses. The pipelining allows an increased operating frequency, at the cost of higher latency. In addition, the internal bus and the peripherials usually run at a lower clock speed than the CPU core (to save area and power consumption).

You may want to check your bus clock dividers, and see if there's a way to increase the clock speed of the internal buses. Many chips start up with conservative settings.

Reply to
Arlet

The bus clock dividers is already configured in it's most fast fasion. The CPU_PLL is configured to 33, arranging a CPU frequency of 12 MHz * 33 = 396 MHz. The system bus clock divider is configured to divide the CPU clock by two and the peripheral bus clock divider can't be changed, it's always two. So this leaves me with a peripheral bus that runs at 99 MHz.

And here comes the Freddy doesn't understand how these things works part (this is probably going to be fun). If this peripheral bus runs at 99 MHz, and the GPIO block is connected to this peripheral bus, then why am I not able to toggle on of the GPIO pins at a more high rate? A set and reset of the GPIO pin takes two actions and the system is not doing that much more at this particulair point in time. So that should give me a frequency of around 50 MHz or am I still missing out on some details?

Bye, Freddy Spierenburg

Reply to
Freddy.Spierenburg

You don't get 50MHz because it takes a number of cycles for the CPU data to make it all the way to the peripheral bus.

Since the system bus is shared with other bus masters (such as the DMA controller) there must be some kind of arbitration mechanism before the CPU gets access. This may take one or more cycles. In addition, the bus itself may require a number of cycles to set up a transfer. It may have a command phase, followed by a data phase, for instance.

Normally, the CPU would use its cache memory so it can move the data across the buses in bigger bursts, which spreads out the overhead costs over multiple bytes.

Reply to
Arlet Ottens

besides pipeline effects, IO space on these devices is often DELIBERATELY slowed in speed. That's because legacy Sw/cables/perhiperals expects certain IO speeds, and to make everything faster, would break a lot of functioning systems.

Try parallel port access on your 2-3GHz PCs and you'll find exactly the same effect.

-jg

Reply to
Jim Granville

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.