2 Replies Latest reply on Jul 22, 2011 9:40 AM by vjain27

    How does LUT in SCC work?




      I am unable to comprehend how LUT on a core in SCC translate the physical address to system address and expands the

      address space to 64 GB. If there is a one to one mapping between physical address and a system address how does the address space get increased?

      How can an application actually make use of the LUT ? For e.g. if a an application wants to access different SRAMs during execution should it keep on updating the LUT while running. I am highly confused. Could anybody please explain this concept with an example or two ?

        • 1. Re: How does LUT in SCC work?

          An application usually need not deal with the details of the LUT. The LUT is mostly used by the operating system when setting things up. An application program program would access a LUT when it wants to write or read a configuration register. The RCCE application library writes LUTs when it wants to hijack some of the private memory used by SCC Linux and treat it as shared memory. (Note that hijacking is a legacy and is going away.)


          If you are writing your own OS or if you are operating as baremetal (no OS), you will want to manipulate LUT entries.


          Our data center systems are 32 GB systems, not 64 GB systems. The RockyLake board takes 8 DIMMs. A 64 GB system would have 8 GB DIMMs. We have 4GB DIMMs.


          The chip has 48 cores and 4 memory controllers. By default 12 cores are mapped to each memory controller, and each memory controller controls 2 DIMMs or 8 GB for our Data Center systems.


          The core is a P54C, and it has a 32-bit virtual address space. This gets translated into a 32  physical address, and it’s this physical address that gets presented to the LUT. It’s 32 bits, but it doesn’t mean that the core can address 4 GB of physical memory. Some of the addresses are resolved as memory –mapped I/O allowing access to SCC configuration registers.


          The 32-bit physical address passes through its least significant 24 bits. Its upper 8 bits select a LUT entry. The LUT entry returns 22 bits that are prepended to the 24 bits that were passes through. Ignore the most signficant bit. The next 8 bits identify the location of the memory controller. The lower 10 bits are prepended to the 24 bits that were passed through to get a 34-bit address, which addresses 16 GB. With 4 memory controllers this is 64 GB. This doesn’t mean there are 64 GB out there. Our data center machines have 32 GB.


          It also doesn’t that one core can access all the memory that is there. Much of that memory is private memory to a particular core. For example, by default for SCC Linux <= 1.4.0,  a core has 320 MB or private memory. Some of that memory is taken up by the operating system. A memory controller has 12 cores, and so you can see the cores under a memory controller accessing 12 * 320 MB or 3840 MB, which is 3 GB. And then by default each memory controller provides an additional 16MB of shared memory.


          Each LUT entry can throretically address 16 MB; this comes from the 24 bits that are passed through. It doesn’t mean that there are 16 MB attached to each LUT entry. Sometimes it’s just a configuration register. And sometimes it’s accessing the MPB, and the MPB is on-chip, not on the DIMMs.


          A good way to see how the LUT works is to look at its values. One way to see the LUTs is just to boot SCC Linux on less than 48 cores or to copy the linux.obj and boot with it in a different directory. That’s just a way of arranging to not use the pre-merged facility. Then in  /tmp/sccKit_yourname/obj, look at the text file lut_init.vi.

          • 2. Re: How does LUT in SCC work?

            Awesome explanation! Thanks a lot!!