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

On Nov 28, 2:30 pm, Freddy.Spierenb...@gmail.com wrote:

> 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:

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.

Hi,

On 28 nov, 15:27, Arlet <usene...@c-scape.nl> wrote:
> 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.

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

Freddy.Spierenburg@gmail.com wrote:
> Hi,
> 
> On 28 nov, 15:27, Arlet <usene...@c-scape.nl> wrote:
>> 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.
> 
> 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?

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.

Freddy.Spierenburg@gmail.com wrote:
> Hi,
> 
> On 28 nov, 15:27, Arlet <usene...@c-scape.nl> wrote:
> 
>>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.
> 
> 
> 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?

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