No Subject

Weng Tianxiang

wtx@umem.com
wengtianxiang@yahoo.com

Micro Memory Inc.
9540 Vassar Avenue
Chartsworth, CA 91311
Tel: 818-998-0070
Fax: 818-998-4459



----- Original Message -----
From: Richard Iachetta <iachetta@us.ibm.com>
To: <pci-sig@znyx.com>
Sent: Friday, June 22, 2001 11:51 AM
Subject: Re: Endian Mapping


> >One of our customers is using a Power PC system. What he is trying to do
> >is trying to use our PCI device on that system.
> >And to do so, he is connecting addr 0 of our PCI chip (little endian) to
> >addr 31 of his Power PC (Big endian) system and
> >so on for all data[31:0] and cbe[3:0] lines.
> >
> >Does this type of approach work ?
> >Does this really solve big endian to little endian mapping ?
>
> Hi Amit,
>
> How is he connecting your device to the system?  There must be a PCI
bridge
> in the system, right?  Such a device would bridge the PowerPC local bus to
> the PCI bus (and probably also bridges to the memory bus).  In that case
he
> should just connect to the PCI bus as usual (bit 0 to bit 0).  He should
> consult with the system spec. to find out how the PCI bridge deals with
> endian issues.  I've worked on some PCI bridges in the PowerPC embedded
> world and can tell you the way we did it -- perhaps his bridge works the
> same.
>
> Unfortunately, this is a confusing subject.  I agree with Neal Palmer that
> it is pretty much impossible to do a general hardware mapping of a big
> endian bus to a little endian bus that works for all sizes of transfer
> (byte, word, dword, etc) because the kind of swapping that must be done is
> based on the size of the data as it was "originally stored" rather than
> being dependent on the size of the data transfer.  But the hardware device
> can't know in general the sizes of each piece of data but rather only
knows
> the size of the current transaction.
>
> So because you can't translate big to little endian on the fly, Dimiter is
> correct that the key is to treat the data as little endian on both busses.
> The way to do that is to map the page as little endian in the PowerPC
> processor (some support this, some don't) or to use the "load byte
reverse"
> and "store byte reverse" instructions.  All the PowerPC processors have
> these instructions I think -- the processors that allow you to map pages
as
> little endian just perform load/store reverse automatically instead of
> having to code it explicitly in software.  A load reverse of a byte is the
> same as a load.  A load reverse of two bytes swaps the two bytes.  A load
> reverse of 4 bytes maps byte 3 of the incoming data to byte 0 in the
> processor, byte 2 to byte 1, byte 1 to byte 2 and byte 0 of the incoming
> data to byte 3 of the processor.  Same for the store reverse.  What this
> accomplishes is taking a piece of data that was written on a little endian
> system and bring it into a big endian processor or device.  For it to
work,
> the sizes of the loads and stores must match the size of the data.  As a
> quick example, lets say a 4-byte quantity (AABBCCDD) exists in PCI memory
> at address 100.  Since PCI is little endian, this means that address 100
> contains DD, 101 contains CC, 102 contains BB and 103 contains AA.  Now
you
> want the PowerPC processor to read this 4-byte quantity into one of its
> 32-bit registers.  How do you map the bus so that the processor will end
up
> with AABBCCDD in its register?
>
> The way we do it is with a mapping called "Byte Lane Preservation".  The
> map is as follows:
>
> PCI AD          PPC Data   Byte Lane
> =====================================
>  07:00           00:07         0
>  15:08           08:15         1
>  23:16           16:23         2
>  31:24           24:31         3
>
> This maps byte lane 0 on PCI to byte lane 0 on PPC.  Byte lane 1 to byte
> lane 1, etc.  The bits within the bytes are reversed just because little
> endian uses bit 0 as the least significant bit and big endian uses bit 0
as
> the most significant bit.  Big/Little endian imply two things: byte
> ordering and also bit ordering even though its technically two separate
> issues.  Its obvious that this mapping produces the correct results for
> bytes.  If you read a byte at address 100 from PCI, it is put on AD(7:0)
> and arrives at PPC(0:7) where it belongs.  Read a byte at address 101 and
> it arrives at PPC(8:15) where the CPU expects it.  What about larger
> datums?  Let's say you want to read that 4-byte quantity AABBCCDD.  PCI
> puts AABBCCDD on AD(31:0), i.e. AA is on AD(31:23) and DD is on AD(7:0).
> This goes through the Byte Lane Preservation map and arrives on PPC (0:31)
> as DDCCBBAA, i.e. PPC (0:7) will contain DD.  But since the PPC processor
> did a 4-byte "load byte reverse" or simply marked the page as little
> endian, the DDCCBBAA quantity ends up in the PPC register as AABBCCDD.  At
> first glance it seems that in this case we've swapped the bytes just to
> swap them back but this mapping ensures that the data arrives in the right
> place for all data sizes (byte, word, dword).  Hope this helped.
>
> Rich Iachetta
> IBM Microelectronics Division -- Austin
> World Wide Field Design Center
> Phone: 512-838-6305   Tie Line: 678-6305
>
>
>