By itself this is not *that* odd. It happens if the size of your code is larger than your first level code-cache and different functions start to kick each other out of the cache. However, in my little toy program this was unlikely. I had only around 20kb of code and the code-cache is 32kb in size.

Better safe than sorry I thought and took a look how the caches are configured. Big and pleasant surprise: Two of them are running at half the maximum size for no good reason:

In my case after DSP-boot I got:

Level 1 Data-Cache 32k
Level 1 Code-Cache 16k
Level 2 Cache      32k

However, the maximum possible cache sizes for the BeagleBoard are

Level 1 Data-Cache 32k (no change)
Level 1 Code-Cache 32k (16kb larger)
Level 2 Cache      64k (32kb larger)

So 48kb of valuable cache has been left unused. Changing the cache sizes is easy:

  #include < bcache.h >

  // and somewhere at the start of main()
  BCACHE_Size size;
  size.l1dsize = BCACHE_L1_32K;
  size.l1psize = BCACHE_L1_32K;
  size.l2size  = BCACHE_L2_64K;
  BCACHE_setSize (&size);

That still leaves you the 48kb of L1DSRAM for single cycle access and 32kb of L2RAM to talk with the video accelerators. Oh – and it gave a noticeable performance boost.

Btw- it’s very possible that this only applies to the DspLink configuration that I am using.

Update:

It turned out that the reason for the smaller cache-sizes is the default DspLink configuration. You can override this if you add the following lines to your projects TCF-file. Just put them somewhere between utils.importFile(“dsplink-omap3530-base.tci”); and prog.gen():

prog.module("GBL").C64PLUSL2CFG  = "64k";
prog.module("GBL").C64PLUSL1DCFG = "32k";
prog.module("GBL").C64PLUSL1PCFG = "32k";

var IRAM = prog.module("MEM").instance("IRAM");
IRAM.len = 32768;

This will configure the OMAP3530 DSP with:

L2-Cache:     64kb
L1 Data-Cache 32kb
L1 Code-Cache 32kb
L1SDRAM       48kb
IRAM (L2 Ram) 32kb

When I did some profiling on my BeagleBoard, and I got some surprising results: The code run a faster as it should. This was odd. Never happened to me.

Fast forward 5 hours and lots of micro-benchmarking:

The 16 bit multiplies SMULxy on the Cortex-A8 are a cycle faster than documented!

They take one cycle for issue and have a result-latency of three cycles (rule of thumb, it’s a bit more complicated than that). And this applies to all variants of this instruction: SMULBB, SMULBT, SMULTT and SMULTB.

The multiply-accumulate variants of the 16 bit multiplies execute are as documented: Two cycles issue and three cycles result-latency.

This is nice. I have used the 16 bit multiplies a lot in the past but stopped to use them because I thought they offered no benefit over the more general MUL instruction on the Cortex-A8. The SMULxy multiplies mix very well with the ARMv6 SIMD multiplies. Both of them work on 16 bit integers but the SIMD instructions take a packed 16 bit argument while the SMULxy take only a single argument, and you can specify if you want the top or bottom 16 bits of each argument. Very flexible.

All this leads to nice code sequences. For example a three element dot-product of signed 16 bit quantities. Something that is used quite a lot for color-space conversion.

Assume this register-values on entry:

              MSB16      LSB16

          +----------+----------+
      r1: | ignored  |    a1    |
          +----------+----------+
          +----------+----------+
      r2: | ignored  |    a2    |
          +----------+----------+
          +----------+----------+
      r3: |    b1    |    c1    |
          +----------+----------+
          +----------+----------+
      r4: |    b2    |    c2    |
          +----------+----------+

And this code sequence:

    smulbb      r0, r1, r2
    smlad       r0, r3, r4, r0
 

Gives a result: r0 = (a1*a2) + (b1*b2) + (c1*c2)

On the Cortex-A8 this will schedule like this:

  Cycle0:

    smulbb      r0, r1, r2          Pipe0
    nop                             Pipe1   (free, can be used for non-multiplies)

  Cycle1:        

    smlad       r0, r3, r4, r0      Pipe0
    nop                             Pipe1   (free, can be used for non-multiplies)

  Cycle2:        

    blocked, because smlad is a multi-cycle instruction.

The result (r0) will be available three cycles later (cycle 6) for most instructions. You can execute whatever you want in-between as long as you don’t touch r0.

Note that this is a special case: The SMULBB instruction in cycle0 generates the result in R0. If the next instruction is one of the multiply-accumulate family, and the register is used as the accumulate argument a special forward path of the Cortex-A8 kicks in and the result latency is lowered to just one cycle. Cool, ain’t it?

Btw: Thanks to Måns/MRU. He was so kind and verified the timing on his beagleboard.

DSP MMU Error Fault!  MMU_IRQSTATUS = [0x1]. Virtual DSP addr reference that generated the interrupt = [0x85000000].

Outch!

I was aware that the DSP of the OMAP3530 has a memory management unit, but so far I never had to deal with it. Dsplink initialized the MMU and enabled access to all the DSP memory and all peripherals I accessed so far.

However, this time I passed a pointer to a memory block allocated via CMEM to the DSP. This triggered a page fault. Now what? I did some research and figured out that the CodecEngine enables access to the CMEM memory. I don’t use the CodecEngine, so I have to do it on my own.

Fortunately the TI folks have thought about that! The PROC module has functionality to modify the DSP MMU entries. Here are some ready to use functions:

int dsp_mmu_map (unsigned long physical_ptr, int size)
///////////////////////////////////////////////////////////
// Maps a physical memory region into the DSP address-space
{
  ProcMemMapInfo mapInfo;
  mapInfo.dspAddr = (Uint32)physical_ptr;
  mapInfo.size    = size;
  return DSP_SUCCEEDED(PROC_control(0, PROC_CTRL_CMD_MMU_ADD_ENTRY, &mapInfo));
 }

int dsp_mmu_unmap (unsigned long dspAddr, int size)
//////////////////////////////////////////////////////////////
// Unmaps a physical memory region into the DSP address-space
{
  ProcMemMapInfo mapInfo;
  mapInfo.dspAddr = (Uint32)dspAddr;
  mapInfo.size = size;
  return DSP_SUCCEEDED(PROC_control(0, PROC_CTRL_CMD_MMU_DEL_ENTRY, &mapInfo));
}

All nice and dandy now? No, it’s not. You can only map a limited number of memory regions (around 32 I think). That’s not enough for my needs. Also I don’t feel like tracking memory regions and swap them as needed. So the way CodecEngine does it is probably better: Enable access to the whole CMEM address-space: These two functions do this, but without CodecEngine:

int dsp_mmu_map_cmem (void)
/////////////////////////////////////////
// map first cmem block into the DSP MMU:
{
  CMEM_BlockAttrs info;

  if (CMEM_getBlockAttrs(0, &info) != 0)
    return 0;

  return dsp_mmu_map (info.phys_base, info.size);
}

int dsp_mmu_unmap_cmem (void)
//////////////////////////////////////////
// umap first cmem block into the DSP MMU:
{
  CMEM_BlockAttrs info;

  if (CMEM_getBlockAttrs(0, &info) != 0)
    return 0;

  return dsp_mmu_unmap (info.phys_base, info.size);
}

All problems solved. Great!

I could have stopped here, but I was eager to know if the MMU has any impact on the memory throughput. Is it possible to completely disable the MMU? Sure, this opens a can of worms. A bug in my code or a wrong DMA transfer could write to nearly any location. It could even erase the flash. But on the DaVinci I didn’t had a MMU and I never run into such problems. So I did some research, and:

It is simple!

The MMU has a disable bit, and the TRM sais that you have to do a soft-reset of the MMU if you fiddle with the settings. I gave it a try and it worked on the first try! You don’t even need a kernel-module for it. The following code will do all the magic from linux-user mode under the restriction that you need read and write access to /dev/mem.

Call this between PROC_load and PROC_start:

int dsp_mmu_disable (void)
//////////////////////////
// Disables the DSP MMU.
// Sets virtual = physical mapping.
{
  volatile unsigned long * mmu;
  int result = 0;

  // physical addres of the MMU2 and some register offsets:
  const unsigned MMU2_PHYSICAL = 0x5d000000;
  const unsigned MMU_SYSCONFIG = 4;
  const unsigned MMU_SYSSTATUS = 5;
  const unsigned MMU_CNTL      = 17;

  // needs Read+Write access to /dev/mem, so you'll better run this as root.
  int fd = open("/dev/mem", O_RDWR);

  if (fd>=0)
  {
    // get a pointer to the MMU2 register space:
    mmu = (unsigned long *) mmap(NULL, 4096, PROT_READ | PROT_WRITE, MAP_SHARED, fd, MMU2_PHYSICAL);

    if (mmu != MAP_FAILED)
    {
      time_t start;

      // A timeout of 10 milliseconds is more then plenty.
      //
      // Usually the reset takes about 10 microseconds.
      // It never happend to me that the reset didn't
      // succeded, but better safe than sorry.
      time_t timeout = (CLOCKS_PER_SEC/100);

      // start MMU soft-reset:
      mmu[MMU_SYSCONFIG] |= 1;

      // wait (with timeout) until the reset is complete.
      start = clock();
      while ((!mmu[MMU_SYSSTATUS]) && (clock()-start < timeout)) {}

      if (mmu[MMU_SYSSTATUS])
      {
        // disable MMU
        mmu[MMU_CNTL] =0;

        // set result to SUCCESS.
        result = 1;
      }
      // remove mapping:
      munmap((void*)mmu, 4096);
    }
    close (fd);
  }

  // failed:
  return result;
}

And to answer my own question: No, the MMU does not has any negative impact on the performance. Also the MMU tables reside in the DDR2 memory, the pages are so large that the extra memory traffic for the MMU table-walks can’t even be measured.

Btw – I’ve made a little easy to use library out of the above functions and I’ll release them under the BSD license, so everyone can use it. Get it here: dsp_mmu_util.tgz

The next question would be: Can the DSP jail-break and disable it’s own MMU? That would be of little practical use but interesting to know..

The order of the transfer-controllers has been reversed. On the DaVinci TPTC0 was ment to be used for system critical controls with low latency and TPTC1 for longer background tasks. On the OMAP3530 this order is exactly reversed. And by the way: Ever wondered what the difference between those two controllers is? On the OMAP3530 the first controller has a FIFO-length of 256 bytes while the second only has 128 bytes. The transfer speed is the same, but transfers issued on the controller with the shorter FIFO have lower latency, so the data reaches the destination a tad earlier.

Btw, while I fooled around with the EDMA I made some speed measurements. I think these can be interesting..

• DSP DMA transfer, internal to DDR2 RAM: 550 mb/s
• DSP CPU transfer (memset) to DDR2 RAM: 123 mb/s (outch!)
• DSP CPU transfer (memset) to internal RAM: 3550 mb/s

For reference I made the same memset test on the CortexA8:

• CortexA8 DDR2 memset (cached): 417 mb/s
• CortexA8 DDR2 memset (uncached): 25 mb/s

All numbers taken with GPP-clock at 500Mhz and DSP-clock at 360Mhz. Caches have been enabled and the transfer-size was one megabyte.

Well – I still don’t have sound output, but I have made some significant steps:

• I got the DSP working!

  That does not sound like much, but it is a key component for my software-architecture. Getting everything working smoothly wasn’t that hard, but there have been some nice and unexpected pitfalls on the road. I may later write about some of the things that will go ẃrong on the first try if you want to run DSP code on the OMAP3530.

• I can now talk to the TWL4030 codec via I2C.

  That has been an unexpected task as well. My assumption was that I could simply use the I2C driver and talk to the chip from Linux user-space. Unfortunately it was not that easy. Long story short: A bunch of drivers is blocking the I2C bus to the TWL4030, so you can’t just send the I2C commands without confusing the existing drivers. However, the drivers expose an interface to the kernel, so all it took was to write a kernel-module that exposes the interface to the user-space.

• I got the EDMA3 controller on the DSP working as well.

  The EDMA3 peripheral on the OMAP3530 is exactly the same as on the DaVinci family. I’ve already worked with this DMA, so that part was easy.

And why all the hassle?

My plan is to move the entire sound output code to the DSP-side of the OMAP. That’ll way I can do all sound processing on a system without any operation system. The good realtime capabilities of the DspBios and the performance of the DSP will allow me to do my sound processing with minimal latency. I estimated that 2ms latency will be no problem, but we’ll see where I end up.

Next steps:

Compile a kernel with all McBSP and sound support disabled. Then write a McBSP driver for the DSP and do some noise

Some weeks ago someone on the beagle-board mailing-list asked how to optimize a color to grayscale conversion for images. I haven’t done much pixel processing with ARM NEON yet, so I gave if a try. The results I got where quite spectacular, but more on this later.

For the color to grayscale conversion I used a very simple conversion scheme: A weighted average of the red, green and blue components. This conversion ignores the effect of gamma but works good enough in practice. Also I decided not to do proper rounding. It’s just an example after all.

First a reference implementation in C:

void reference_convert (uint8_t * __restrict dest, uint8_t * __restrict src, int n)
{
  int i;
  for (i=0; i<n; i++)
  {
    int r = *src++; // load red
    int g = *src++; // load green
    int b = *src++; // load blue 

    // build weighted average:
    int y = (r*77)+(g*151)+(b*28);

    // undo the scale by 256 and write to memory:
    *dest++ = (y>>8);
  }
}

Optimization with NEON Intrinsics

Lets start optimizing the code using the compiler intrinsics. Intrinsics are nice to use because you they behave just like C-functions but compile to a single assembler statement. At least in theory as I’ll show you later..

Since NEON works in 64 or 128 bit registers it’s best to process eight pixels in parallel. That way we can exploit the parallel nature of the SIMD-unit. Here is what I came up with:

void neon_convert (uint8_t * __restrict dest, uint8_t * __restrict src, int n)
{
  int i;
  uint8x8_t rfac = vdup_n_u8 (77);
  uint8x8_t gfac = vdup_n_u8 (151);
  uint8x8_t bfac = vdup_n_u8 (28);
  n/=8;

  for (i=0; i<n; i++)
  {
    uint16x8_t  temp;
    uint8x8x3_t rgb  = vld3_u8 (src);
    uint8x8_t result;

    temp = vmull_u8 (rgb.val[0],      rfac);
    temp = vmlal_u8 (temp,rgb.val[1], gfac);
    temp = vmlal_u8 (temp,rgb.val[2], bfac);

    result = vshrn_n_u16 (temp, 8);
    vst1_u8 (dest, result);
    src  += 8*3;
    dest += 8;
  }
}

Lets take a look at it step by step:

First off I load my weight factors into three NEON registers. The vdup.8 instruction does this and also replicates the byte into all 8 bytes of the NEON register.

    uint8x8_t rfac = vdup_n_u8 (77);
    uint8x8_t gfac = vdup_n_u8 (151);
    uint8x8_t bfac = vdup_n_u8 (28); 

Now I load 8 pixels at once into three registers.

    uint8x8x3_t rgb  = vld3_u8 (src);

The vld3.8 instruction is a specialty of the NEON instruction set. With NEON you can not only do loads and stores of multiple registers at once, you can de-interleave the data on the fly as well. Since I expect my pixel data to be interleaved the vld3.8 instruction is a perfect fit for a tight loop.

After the load, I have all the red components of 8 pixels in the first loaded register. The green components end up in the second and blue in the third.

Now calculate the weighted average:

    temp = vmull_u8 (rgb.val[0],      rfac);
    temp = vmlal_u8 (temp,rgb.val[1], gfac);
    temp = vmlal_u8 (temp,rgb.val[2], bfac);

vmull.u8 multiplies each byte of the first argument with each corresponding byte of the second argument. Each result becomes a 16 bit unsigned integer, so no overflow can happen. The entire result is returned as a 128 bit NEON register pair.

vmlal.u8 does the same thing as vmull.u8 but also adds the content of another register to the result.

So we end up with just three instructions for weighted average of eight pixels. Nice.

Now it’s time to undo the scaling of the weight factors. To do so I shift each 16 bit result to the right by 8 bits. This equals to a division by 256. ARM NEON has lots of instructions to do the shift, but also a “narrow” variant exists. This one does two things at once: It does the shift and afterwards converts the 16 bit integers back to 8 bit by removing all the high-bytes from the result. We get back from the 128 bit register pair to a single 64 bit register.

    result = vshrn_n_u16 (temp, 8);

And finally store the result.

    vst1_u8 (dest, result);

First Results:

How does the reference C-function and the NEON optimized version compare? I did a test on my Omap3 CortexA8 CPU on the beagle-board and got the following timings:

C-version:       15.1 cycles per pixel.
NEON-version:     9.9 cycles per pixel.

That’s only a speed-up of factor 1.5. I expected much more from the NEON implementation. It processes 8 pixels with just 6 instructions after all. What’s going on here? A look at the assembler output explained it all. Here is the inner-loop part of the convert function:

 160:   f46a040f        vld3.8  {d16-d18}, [sl]
 164:   e1a0c005        mov     ip, r5
 168:   ecc80b06        vstmia  r8, {d16-d18}
 16c:   e1a04007        mov     r4, r7
 170:   e2866001        add     r6, r6, #1      ; 0x1
 174:   e28aa018        add     sl, sl, #24     ; 0x18
 178:   e8bc000f        ldm     ip!, {r0, r1, r2, r3}
 17c:   e15b0006        cmp     fp, r6
 180:   e1a08005        mov     r8, r5
 184:   e8a4000f        stmia   r4!, {r0, r1, r2, r3}
 188:   eddd0b06        vldr    d16, [sp, #24]
 18c:   e89c0003        ldm     ip, {r0, r1}
 190:   eddd2b08        vldr    d18, [sp, #32]
 194:   f3c00ca6        vmull.u8        q8, d16, d22
 198:   f3c208a5        vmlal.u8        q8, d18, d21
 19c:   e8840003        stm     r4, {r0, r1}
 1a0:   eddd3b0a        vldr    d19, [sp, #40]
 1a4:   f3c308a4        vmlal.u8        q8, d19, d20
 1a8:   f2c80830        vshrn.i16       d16, q8, #8
 1ac:   f449070f        vst1.8  {d16}, [r9]
 1b0:   e2899008        add     r9, r9, #8      ; 0x8
 1b4:   caffffe9        bgt     160

Note the store at offset 168? The compiler decides to write the three registers onto the stack. After a bit of useless memory accesses from the GPP side the compiler reloads them (offset 188, 190 and 1a0) in exactly the same physical NEON register.

What all the ordinary integer instructions do? I have no idea. Lots of memory accesses target the stack for no good reason. There is definitely no shortage of registers anywhere. For reference: I used the GCC 4.3.3 (CodeSourcery 2009q1 lite) compiler .

NEON and assembler

Since the compiler can’t generate good code I wrote the same loop in assembler. In a nutshell I just took the intrinsic based loop and converted the instructions one by one. The loop-control is a bit different, but that’s all.

convert_asm_neon:

      # r0: Ptr to destination data
      # r1: Ptr to source data
      # r2: Iteration count:

    	push   	    {r4-r5,lr}
      lsr         r2, r2, #3

      # build the three constants:
      mov         r3, #77
      mov         r4, #151
      mov         r5, #28
      vdup.8      d3, r3
      vdup.8      d4, r4
      vdup.8      d5, r5

  .loop:

      # load 8 pixels:
      vld3.8      {d0-d2}, [r1]!

      # do the weight average:
      vmull.u8    q3, d0, d3
      vmlal.u8    q3, d1, d4
      vmlal.u8    q3, d2, d5

      # shift and store:
      vshrn.u16   d6, q3, #8
      vst1.8      {d6}, [r0]!

      subs        r2, r2, #1
      bne         .loop

      pop         { r4-r5, pc }

Final Results:

Time for some benchmarking again. How does the hand-written assembler version compares? Well – here are the results:

  C-version:       15.1 cycles per pixel.
  NEON-version:     9.9 cycles per pixel.
  Assembler:        2.0 cycles per pixel.

That’s roughly a factor of five over the intrinsic version and 7.5 times faster than my not-so-bad C implementation. And keep in mind: I didn’t even optimized the assembler loop.

My conclusion: If you want performance out of your NEON unit stay away from the intrinsics. They are nice as a prototyping tool. Use them to get your algorithm working and then rewrite the NEON-parts of it in assembler.

Btw: Sorry for the ugly syntax-highlighting. I’m still looking for a nice wordpress plug-in.

So what’s CMEM all about?

In a nutshell CMEM is a kernel-module that allows you to allocate contiguous memory on the OMAP3, map this memory it into the address-space of a user-mode program so you can read and write to it.

CMEM also gives you the physical address of these memory-blocks.

This is important if you want to share some memory with the C64x+ DSP as the DSP has no idea what the memory manager of the Cortex-A8 is doing. It also allows linux user-mode programs to allocate memory that can be used with DMA.

Things you need:

• The sources of the libutils from the TI website (registration is required but free). I’ve used release 2.24 which works fine with my 2.6.29-omap1 kernel image.
• The linux kernel-sources for the beagleboard. If you use OpenEmbedded and you have already compiled an image you’ll most likey find them at $OE_HOME/tmp/staging/beagleboard-angstrom-linux-gnueabi/kernel/.
• A cross-compiler toolchain for ARM. I still use the CodeSourcery 2007q3 light release. Works for me.
• A beagleboard. Also not strictly required it makes perfect sense to have one.

Howto compile CMEM:

1. Untar the linuxutils package. The place where to untar them is not important.
2. Go into the CMEM subfolder. For the 2.24 release it’s the ./packages/ti/sdo/linuxutils/cmem/ folder.
3. Take a look at the Rules.make file. Messy, ain’t it?  Remove the write protection.. chmod +w Rules.make will do that. You now have to adjust the pathes in that file or if you’re like me – delete it and write it from scratch:Here is my copy with everything not needed removed:

   # path to your toolchain. Yes, you need to set it twice (don't ask...)
   MVTOOL_PREFIX=/opt/CodeSourcery/bin/arm-none-linux-gnueabi-
   UCTOOL_PREFIX=/opt/CodeSourcery/bin/arm-none-linux-gnueabi-
   
   # path to the kernel-sources:
   LINUXKERNEL_INSTALL_DIR=${OE_HOME}/tmp/staging/beagleboard-angstrom-linux-gnueabi/kernel
   
   # some config things:
   USE_UDEV=1
   MAX_POOLS=128

4. That’s it.. If all pathes are correct “make release” should build the kernel module and some test applications.

Howto test CMEM:

1. Copy the kernel-module to the beagleboard. For the test I’ve just copied it into /home/root/. You’ll find the kernel-module at ./src/module/cmemk.ko
2. On the board, check your U-Boot boot-parameters. Since CMEM manages physical memory you have to restrict the amount of memory managed by linux. To put aside some memory add the  mem=80M directive to the bootargs. You can of course use a different setting if you want to, but the following examples assume 80M for the linux-kernel and the rest for DSP and CMEM.
3. Boot the beagle and login as root.
4. Load the kernel-module. Let’s keep things simple. We create a single 16mb memory pool. To do so load the module like this:

   /sbin/insmod cmemk.ko pools=1x1000000 phys_start=0x85000000 phys_end=0x86000000

   If everything worked as expected you’ll find the following line in the kernel-log (type dmesg to get it):

   cmem initialized 1 pools between 0x85000000 and 0x86000000

   If not – well – CMEM will give you a bunch of hints in the kernel-log if it had problems during initialization. Most likely you’ve got the addresses wrong. As the start-address you should pass 0×80000000 plus the size you’ve specified in the u-boot bootargs. Add the sizes of all of your CMEM-pools and use this as the end address.

5. While the module is loaded you’ll find a file under /proc/cmem with some statistics.
6. If everything worked so far you can run some of the demo-applications like apitest. They’re are located in the ./apps/apitest/ folders.

Compile an ARM program that uses CMEM:

This is easy. Copy ./src/interface/cmem.h to a place where the cross-compiler will find it and add one of the cmem.a libraries to your project. Since I like to keep things simple I’ve just added the interface source to my project. It’s  ./src/interface/cmem.c.

Now you can allocate contiguous memory and get the physical address of it. Big deal, eh? Honestly, like I said CMEM only makes sense if you want to make use of the C64x+ DSP or the SDMA of the OMAP3.

]]> http://hilbert-space.de/?feed=rss2&p=14 10