A general question about MPC83xx Load/Store Unit.. Just for personal interest.

[ShawnBai]

Hello, here is a question with Load/Store Unit. The CPU is MPC837xE

Let's say that,  there is one Nor Flash locating at CS0 of eLBC,

and its data width is 16-bit, that is, 16-bit data comes  out when it is read each time.

There is no hardware signal like ' byte selection from the 2 bytes ' .

The base address of CS0 is 0xFF800000.

now, let's read one byte in this nor flash, for example,

unsigned char ch = 0;

ch = *(unsigned char *)(0xFF800000);

After disassemble,   this C statement is as following in assembly language:

lis r5, 0xFF80

lbz  r31,  0(r5)   //  an register  indirect with immediate index mode addressing

this is the point  I am interested in .

lbz is a load instruction, which indicates a read command. and

0(r5)  indicates the address where  data locates.

This address will enter into Nor flash CS0 address space.

 READ command  and Address will validate CS0, OE#, address lines  in Nor Flash.

After this read, Nor Flash chip will return 2-byte data to eLBC.

But,  how is it determined that which of these 2 bytes data is needed ?

I am very curious about this ?

Is there another layer underneath the assembly language?

Assembly language codes will  be transformed into kinds of hardware signal, aren't they ?

Is there anyone who can help with this question and go any further?

[TomE]

The Power architecture has a long history involving IBM, Motorola and Apple. There are a large number of inplementations of this architecture. It wouldn't be worth putting everything about the CPU into every implementation's manual.

The manuals are written like the Harry Potter Series. If you pick up the last one in the series it is ASSUMED you've read all the previous ones. The same applies here - sort of, except there's a big branching tree of books rather than a single linear series. Maybe reading "War and Peace" is a better example :smileyhappy:.

So there are Architecture Reference Manuals, specific Core Reference manuals and so on.

The Reference Manual for the MPC8306 states at the top of the "e300 Processor Core Overview":

For additional information, see e300 Power Architecture™ Core Family Reference Manual.

That manual refers to previous implementations (like the MPC603e) and assumes you know all about that one.

However the section "3.1.1 Data Organization in Memory and Memory Operands" is what you should read to answer your question.

"Big Endian" versus "Little Endian" goes back to Gulliver's Travels:

http://en.wikipedia.org/wiki/Big_endian#Etymology

Tom (A Random Poster)

[ShawnBai]

Well.

I get what you mean, but, I don't think what I ask is the same with what you reply.

In my opinion, it's not the question with endian.

ok, then, let's say, MPC837xE is running in big-endian, ok?

Assume there are two bytes addressed from offset zero from flash bank base address,

Offset      0          1

Data      0xab    0x12

this nor flash is 16-bit width. so every time reading it , 16-bit data will be returned.

It's real that between GPCM and nor flash chip, isn't it?

The things following are interesting.

How does GPCM know which one of the two bytes should be tranferred to processor core ?

The code may look like this:

u8 data = 0;

data = *(u8 *)(Flash_Base_Address + 0);

processor core tells GPCM the address is Flash_Base_Address + 0,

but what's the way that processor core tells GPCM it wants one byte?

Load instruction   lbz r4, 0(Flash_Base_Address)

will be converted into hardware signal, but how is this done to tell GPCM that it is one-byte-read instruction ?

What I want to know is that the core wants one-byte, and GPCM gets 2 bytes from nor flash chip.

How does GPCM(or, with other parts in MPC837xE) accomplish it ?

How interesting it is ! 

Don't you think so?

[TomE]

The whole 32-bit address gets sent to the GPCM together with signals that give the "width" of the read (or write). You'll notice the GPCM has two "Write Enable" signals for when you write to only one byte on the 16-bit bus.

There is lane-swapping hardware all over the place in that chip. The CPU has a 64-bit data bus coming out of it for one thing. The GPCM handles 16 bit wide transfers, so it has to read and write 16-bit-wide lanes from the CPU upper and lower halves of a 32-bit bus (or maybe the four 16-bit wide parts of a 64-bit-wide data bus) to and from the correct external lanes. If the GPCM is programmed to access an 8-bit part it has to transfer 8 bit lanes all over the place.

Moreover, if you perform a 32-bit read from an 8 bit chip, the GPCM performs the four byte-wide reads, packs them properly in 32 bits and then sends that off to the CPU in one cycle.

Some chips have multiple internal "bridges" between different bits of hardware with different width and speed busses, and they do some of this work. Some of these chips have PCI controllers, and they have to handle "internal lanes and byte ordering" to the PCI ones, which in the case of the Power chips are the reverse endian order to the CPU too.

It gets more complicated. The X86 CPUs have always been able to handle unaligned data. So if you read 32 bits from address "1" it reads bytes 0-3 and 4-7 (assuming 32-bit memory) then shifts the first 3 bytes from the first read, shifts and combines the single byte from the second read and presents the full 32 bits to the CPU.

You can't do that on an old ARM CPU. Try that trick and it traps. In order to make the chip with less silicon (so it is smaller and cheaper and lower power) all transfers have to be aligned properly.

The Power architecture usually allows misaligned accesses, except when it doesn't. For instance the MPC5200 I'm using will handle misaligned transfers to and from SRAM, but if you do a misaligned read from its "LocalBusPlus" (same function as the GPCM) then it will return only one byte out of the two or four you've read, and in the wrong lane, with no warning or trap at all. That's really bad for something that is mapped into memory and looks exactly like all the other memory in the system which does handle the misaligned transfers.

This isn't mentioned in the Errata for this chip. Instead it is listed as:

9.2 Features
LocalPlus has the following features:
• Interface to memory mapped or chip selected devices

• (other features) ...

• NO support of misaligned accesses

That took me a few weeks to sort out when it went wrong and started corrupting the file system.

Tom

[ShawnBai]

Thanks so much.

Let's go much further.

As you say, there are "write enable" signal. there signals layout between Core and GPCM, or between GPCM and flash chip.

The Nor flash we used is SST39VF6401B.

There are no "write enable" signals on it.

Do you mean, there are byte selection signal between Core and GPCM?

But referencing MPC837xE reference manual eLBC module, there is not this kind of signals explained in eLBC module.

If what you say is right, i.e. there are ways Core can tell GPCM how many bytes it want this read operation, it gets clear,

although I would died to know what on earth it is.

[TomE · Accepted solution]

Further on in the same manual:

8.2 Overview of Core Interface Accesses
The e300 core contains an internal coherent system bus (CSB) that interfaces the core to the peripheral
logic. This internal bus is very similar in function to the external 60x bus interface on the MPC603e
processor.

So if you really want to know how it works, download and read all the manuals on the MPC603e, because that tells you how the MPC603e's external bus works. That bus is "internalised" in the newer chips.

"Which byte to read and write" is extremely trivial when compared with everything else the bus does - the snooping, pipelining, overlapping operations, queues and so on.

Then you can die happy :smileyhappy:

Tom

[ShawnBai]

Hi, Tom,

Additionally,  could you explain or give some guidance about how assembly language  is converted into hardware signal?

Like the instruction which load one byte, lbz r0, 0(r3), at last, r3 will be present on address bus of CSB, read commond will be present on control bus of CSB.

Are there any materials which can get this clear ?

Thanks.

[TomE]

Have you read the 603e manuals yet? Please don't ask me about things in references I've already given you.

There are three of these manuals:

http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPC603E&fpsp=1&tab=Documentation_Tab

MPCFPE32B 
Programming Environments Manual for 32-Bit Implementations of the Power Architecture

MPC60XBUSRM 
The Bus Interface for 32-Bit Microprocessors that Implement the PowerPC Architecture

MPC603EUM 
MPC603e RISC Microprocessor Users Manual

"Table 3-3. Aligned Data Transfers for 64-Bit Data Bus" in the Bus Reference Manual details how the TSIZ and ADDRESS signals are used to designate which bytes are to be read/written.

Tom

[ShawnBai]

Yes, I'm reading MPC630e user manual, and learn that there are signals called transfer type, transfer size, transfer burst.

They are what I need.

There are no other questions.

Thanks a lot.

[TomE]

These CPUs are immensly complicated, and really hard to understand. I think I have it easier than most, as I've been "following the history" for a long time.

I think I understand these CPUs pretty well because I started out in the 6800 era, and they were simple enough to be completely described in a rather small book. The next step up (in complexity) was the 68000 and 68010 with 32-bit internals (actually 16 bit internals emulating 32 bits) and a 16 bit external bus. Then came the 68020 with a more complicated 32-bit bus, which could be understood better by watching the 8 - 16 - 32 bit evolution from the 6800 to 68010 to 020. Then more complexity with the 68030 and 68040. Add caches. Add floating point. Add memory management. All incremental upgrades that only needed to be understood as an "add on" to the previous ones.

Cue the Coldfire chips, which are "68000 meets RISC". A lot of the weird things that the Coldfire chips do (like the excellent interrupt structure) is best explained as being backwards-compatible to or an evolution of the 68000 design (which owes a lot to the DEC PDP-11 which I know well too).

Cue the 88000 which went nowhere, but the bus design ended up in the Motorola/Freescale Power series, MPC601, MPC860 and so on.

So why are the Freescale MPC PowerPC chips the way they are? When Apple went from the 68k Macintosh to the Power Mac they got the CPU design from IBM, but wanted Motorola to make the silicon. Motorola added the 88000 bus. Apple also wanted some custom mods (combined cache rather than separate ones). That formed much of the basis for the Power chips that followed. Trying to explain the instruction set of the PPC (LIS, "@ha", RLWIMI, EIEIO and the huge (34 PAGES!) of "simplified mnemonics") is beyond me though...

Tom

[ShawnBai]

Thanks a lot.

[ShawnBai]

ya, Why not after you get how you want, ha?

I will check the MPC603e manual to find out the things.

Speaking of whether or not being trivial, I am just very very curious about it, what it does, how it does.

That's what it all adds up to.

Appreciate your so kind answers very much.