Found nasty bug in 68030 CPU!

[Oliver_A]

Hi guys,

as I am currently writing the software for the upcoming ACA630/1230 cards, I encountered a possibly undocumented bug in the MC68030 CPU line. This bug is so subtle and hard to find, probably no coder has ever noticed it, but as it happens, it drove me crazy for several days, since of course I blamed our hardware design for it first, but later realized that it was perfectly reproducable on all kinds of hardware.

I formulate the bug now in one sentence, and explain what it means:

On longword accesses, the 68030 ignores the Cache Inhibit (CIIN) pin

What does that mean? The 68030 has a Cache Inhibit pin, which is used to disable the instruction and data caches for certain memory areas. In case of the Amiga, this usually contains all the register areas, since the contents of certain chipset registers change dynamically, so the 68030 needs to be told not to cache any data being written to those registers.

Most Amiga chip registers are write-only. Any readback yields unreliable bus trash. Like this:

move.w #$dead,$dff180
move.w $dff180,d0

Chances are high that d0 contains a trashed value, which are remains of the electrical state of the data bus, when no device is driving the data lines. The point being made is: the 68030 reads the actual bus value.

Now do this longword access with activated caches:

move.l #$deadbeef,$dff180
move.l $dff180,d0

Now, d0 ALWAYS contains "deadbeef", no matter how often you perform the read. Switch back to reading words: the trash values are back. How can this happen? Answer: the 68030 is reading from its cache on the longword access!

Try the same now with disabled caches, and now the trashed values also appear on longword accesses. The 68030 is now reading again the actual bus values!

This bug ONLY appears on long word read/writes, which is probably the reason why most accesses to chip registers, which are usually word sized and most probably do not involve reading-back status registers using londwords, like DMACONR, do work.

However, I am sure that any potential reader who has the expertise to interpret this stuff can imagine lots of potential scenarios, which might be rare, but which can lead to very confusing, nasty and hard to find bugs. This might be valuable information for WHDLOAD patches, since I know that lots of games do weird and nasty stuff, which probably triggers this bug in some cases.

[Predseda]

How this bug affects those upcoming cards? And is it possible to avoid?

[Oliver_A]

Originally Posted by Predseda

How this bug affects those upcoming cards? And is it possible to avoid?

Repeat: this is not a bug in our hardware. It has always been present in the 68030 CPU and therefore affects all Amiga accelerators having this CPU. It might even be present in the 68020, though I would have to test that.

I made this report here primarily for coders, since it might affect behaviour in old games. Since from AmigaOS2 on, cache behaviour is taken into account, this shouldn't affect any "clean" code.

How to avoid? Don't read status registers using longwords, especially chipset registers. Flush caches after DMA operations.

[Minuous]

Well spotted. Have you told Freescale about this bug?

[r.cade]

"The assertion of CIIN is ignored when the appropriate cache is not enabled or when cache inhibit
out (CLOUT) is asserted. It is also ignored during write cycles or translation table searches. "

Not sure if that applies here, but that is from the Motorola manuals. I would think something that big would be by design or at least well-known.

[DDNI]

is this related to the 68030 cache bug referred to by Dave Haynie in the A3000 system spec? (page 23, para 1, line 6)

http://www.thule.no/haynie/research/...ocs/a3000p.pdf

[yaqube]

Originally Posted by Oliver_A

On longword accesses, the 68030 ignores the Cache Inhibit (CIIN) pin

Well, the 68030 ignores the CIIN signal during all write cycles. It's not a bug, it's written in the 68030 user's manual.

If the WA (Write Allocation) bit is set in the CACR register every long-word aligned long-word write will allocate an entry in the data cache.

[Oliver_A]

Originally Posted by yaqube

Well, the 68030 ignores the CIIN signal during all write cycles. It's not a bug, it's written in the 68030 user's manual.

Which means that the data, including word acesses, is written in the cache, but not retrieved during a read cycle (otherwise, this pin would hardly serve any purpose). And yet, on longword reads, it is retrieved, which is clearly faulty behaviour.

If the WA (Write Allocation) bit is set in the CACR register every long-word aligned long-word write will allocate an entry in the data cache.

Yes, but again, this has nothing to do with this faulty behavior. It merely describes how data words have to be aligned in order to be written into the cache lines. CIIN prevents read backs from cache (effectively disabling them), which obviously does not happen here when longword acesses are made.

Point remains: data should never ever be retrieved from cache during a read cycle when CIIN is asserted. This IS a hardware bug.

[yaqube]

Originally Posted by Oliver_A

Which means that the data, including word acesses, is written in the cache, but not retrieved during a read cycle (otherwise, this pin would hardly serve any purpose). And yet, on longword reads, it is retrieved, which is clearly faulty behaviour.

If it's in the cache it's also retrieved on byte, word and long-word accesses. And it's not a faulty behaviour. That's the way the cache works.

The purpose of the CIIN input is to prevent the data read from the memory to be put into the cache. It doesn't prevent the data from the cache to be accessed by the CPU. There is no way to find out from the outside of the CPU what is the address of the data the CPU wants to access until there is a cache miss and an external bus read cycle is started. During this cycle the CIIN input can be used to prevent caching of the accessed data. I think it's very clear.

CIIN prevents read backs from cache (effectively disabling them), which obviously does not happen here when longword acesses are made.

It seems you miss the point what the purpose of the CIIN input is.

Point remains: data should never ever be retrieved from cache during a read cycle when CIIN is asserted. This IS a hardware bug.

If data is in the cache there is no way to prevent to access it unless the cache is disabled.

The problem is caused by writing a long-word to long-word aligned address with the WA (Write Allocate) bit set. In this case an entry in the cache is always allocated regardless of the state of the CIIN input and all successive reads from this location will access the data in the cache (unless it's flushed) with no external bus read cycle generated.

Since it's documented it's a feature and not a bug.

[Zetr0]

@yaqube

I am sure I heard M$ use that line "Since its documented it's a feature and not a bug" =D

I would be curious to know if this feature/bug is inherent in the 020.

[yaqube]

Originally Posted by Zetr0

I would be curious to know if this feature/bug is inherent in the 020.

The 020 has no data cache so this doesn't apply to it.

[Wepl]

whdload slave authors should be aware of this behavior

using the options SnoopOCS/ECS/AGA WHDLoad will detect all reads to write-only and writes to read-only custom registers, with that problems caused by this behavior can be detected without much effort
also if MMU is used custom/cia regions are marked as uncacheable

it should also be noted that write allocation is only needed if usermode and supervisor mode acceses the same memory, for several games running only in supervisor mode WA can be disabled