Ultra simple ISO-7816 Interface

While laying out a PCB for my SWP reader project I realized that I haven’t ever tested the ISO-7816 (aka contact) interface yet. I probably forgot that because it’s not all that difficult and not that interesting, but I’d rather see it working before I order PCBs.

So I spend an hour or two in the internet looking for inspiration how other people did it. There are lots of specialized chips for this purpose out there, but sourcing is always a problem and since it’s “just” a simple serial interface I was more interested in a simple hack that will work.

Turns out there are a lot of simple SIM/Smart-card readers out there that just do this, and they pretty much all look like this:


Here Q1 is running as a open collector driver with R1 as a pull-up resistor. This transistor will invert the signal, that’s why there is an additional inverter A1 in front of the base. R2 and C1 are the usual base-resistor and speed-up capacitor.

You’ll find variations of this basic circuit all over the net. Sometimes they omit the speed-up capacitor, sometimes you find buffers in the RX-UART path, but that’s it basically.

I heated up my soldering iron and gave this circuit a test drive, and lo and behold: It works as expected (aka good enough in practice).
So problem solved, move on.

Not so. In the middle of the night it came to me, that almost the entire circuit is unnecessary. What does it really do? On the Q1 collector we see a replica of the TX-UART signal. The SIM card IO pin (which is just an open collector IO-pin) is able to pull the signal down at will without causing a short to TX-UART.

RX-UART picks up this signal and echoes back either what comes from TX-UART or from IO. Neither pin is pulling up the signal, that’s what R1 is doing.

So how about this:


It’s working just the same, just faster and with less parts.

In case that TX-UART is transmitting, and IO is listening the singal will just pass R1. If TX-UART stops transmitting the UART will go into idle-state (logic high). This effectively ties R1 to VCC and we have exactly the same behaviour as with the more “complex” circuit.

If the SIM transmit something SIM-IO just pulls the line down to ground. A bit of current will flow out of TX-UART, but that’s fine. Compared to drive a LED from a GPIO pin that’s nothing.

If you feel inspired to try this out, here is a short how-to:

  • Configure the UART on the micro-controller side for 9600 baud, 8 data bits, two stop-bits and even parity.
  • Power the SIM VCC pin, have reset low.
  • Apply a clock signal 372 times the UART baud-rate: 3.57 Mhz.
  • Wait a little for the SIM/SmartCard to stabilize.
  • Raise the reset line to taking the SIM-card out of reset.

And then watch the Answer to Rest (ATR) signature arriving at your micro-controller UART-RX pin. You’re now ready to implement the ISO7816-3 T=0 or T=1 protocol and do some real data-exchange. With practically any micro-controller and just a simple resistor.

Oh, by the way. You’re allowed to let the IO pin of the SIM to pull down up to 500µA, so if you get problems with stray capacitance just lower R1. Minimum values are:

  • 3.6k for 1.8V supply
  • 6.6k for 3.3V supply
  • 10k for 5V supply.
Posted in Uncategorized | Leave a comment

NFC SWP Physical Layer – How it works

As I’m currently building an NFC-SWP reader device I have to tackle quite some challenges simply because there there is no single chip solution out there that you can simply connect to USB and a SIM card. Most NFC Controllers can of course talk SWP, but they will not work as a simple and transparent bridge. Therefore I’ll design my own solution.

To do so, it is crucial to understand how the protocol works on the lowest level.

The SWP physical layer is quite a unique thing. It allows the NFC SIM-card and the NFC controller to exchange data at a rate of 1.7 megabit/second full duplex over just a single wire. And they not only transmit bidirectional data, they transmit a clock signal for synchronization as well.


How do they pulled that off?

First have a look at the S1 signal. This is the signal that transmits the clock and the data from the NFC controller towards the NFC SIM. Each bit gets transmitted using a full cycle, and the pulse-width of the signal defines if a zero or one bit gets transmitted.

Here is a picture of the S1 signal transmitting a stream of zeroes:


Each bit starts with the raising edge. The voltage high duration of each cycle is 25% of the cycle length. This is interpreted as a zero-bit. Likewise, if the voltage high duration is 75% of the cycle length a one-bit gets transmitted. Again a picture of one-bits to illustrate this:


Extracting the clock and data from this signal is easy. Each clock-cycle starts with the raising edge of the signal. For the clock extraction the falling edge can simply be ignored.

Getting data-bits is easy as well. All you have to do to extract the bits from this signal is to take a look at the voltage at the middle of the cycle. In the images I’ve aligned the numbers denoting the bit-value to this place. I use this method when I debug SWP signals taken with a logic-analyzer. In a hardware-design it is probably not feasible because you’ll never know where exactly the middle of the cycle is until the cycle has ended. I don’t know for sure, but I bet they measure the durations of the high and low periods and extract the bit from that.

For completes sake, here is a picture of a signal with some one and zeros:


This is how one side of the communication works. I’ve simplified a bit and left out things like fall- and rise-times, voltage-levels, tolerances and so on. Also it is worth noting that the clock-rate is not fixed. The NFC-controller is allowed to change the clock rate at will as long as you stay within the allowed range.

How does the SIM transmits data?

Now we have seen how the NFC-controller talks to the SIM-card and how the synchronization works. But the SIM card probably wants to transmit data as well. How does this work?

The NFC-SIM can not transmit data by applying a voltage to the SWP link because the link is always driven by the NFC-Controller. However, the NFC-SIM can draw current from the SWP-link without interfering with the NFC-controller.

Take a look at one of the S1 signal images again. In each clock cycle there will always be voltage high period. During these high periods the SIM can load the SWP link and draw some current. During the voltage low periods it can’t because to draw a current a voltage must be present.

This leads to the fact that the signal from the SIM (S2) will always be modulated by the signal S1 generated by the NFC-controller.

To make things a bit more easy to understand here is a picture of signals S1 and S2. The voltage domain is shown in blue while the current domain is shown in red.

First S1 transmitting some one and zero bits while S2 (the SIM) transmitting a stream of zeros:

s2-zeroesNot much going on on the S2 signal. That’s how zero-bits look like.


And now S1 transmitting the same data again while S2 is transmitting a stream of ones:s2-onesOn the S2 signal, one bits become a copy of the S1 bits.


And finally both signals transmitting a bunch of bits:s2-bitsYou probably already guessed it. One bits in S2 become copies of S1, zero bits are just a flat line.

The NFC-controller can read the S2 bit-stream by measuring the current consumption of the SWP link just before it generates the falling edge.


Timing, Timing and Levels:

In the general case communication over SWP must be done at a frequency between 200 kilobit/second up to 1 megabit/s. A SIM card may also announce the capability to go faster (up to 1.69 megabit/s) or slower (down to 100 kilobit/s).

And they mean it! While troubleshooting I’ve tried to run SWP at a slower clock-rate. It didn’t worked at all. There is some wiggle room, but not much.

The S1 (voltage) is in practice a 1.8V digital signal regardless of the SIM-card supply voltage. The levels that define the high and low regions change somewhat with the different supply voltage classes, but if you provide a clean digital 1.8V signal you won’t run into issues.

In practice it seems that NFC SIM-cards are very forgiving about the voltage applied to the SWP-pin as long as you don’t exceed the supply voltage.

Note that these are ballpark figures, within 10% or so of the real thing. You’ll find the exact values in the specification ETSI TS 102 613 (you’ll find it via Google), chapter 7.1.3.

The S2 (current) signaling definition is much simpler. Independent of the class, a logic high is defined by drawing 600µA or more. The SIM should not draw more than 1mA though.

Why did they came up with such a oddball protocol?

To be honest, I don’t know exactly.

A couple of years ago, while I was working on a NFC middle-ware, I had good contacts with a NFC chip manufacturer. While on site, during lunch I asked exactly this question. The answer was more pragmatic than I expected:

During the stone ages of smart-cards the contact interface (aka the gold pads on your SIM that makes contact with the phone) has been defined. The same interface has been re-used by SIM-cards because SIMs *are* just small smart-cards.

Back then writing to smart-cards required a dedicated programming voltage. Nowadays no one needs the programming voltage anymore, so the pin was always unconnected. Since they wanted NFC functionality in their SIM’s they re purposed this pin and use it for SWP now.

If they had two free pins we would probably have something much simpler. Doing stuff in the current domain has a price: It consumes power. Now SIM cards usually end up in mobile phones. Going low power and having having a long standby time is a thing so I’ve heard. Fortunately the SIM is not communicating over SWP most of the time.

There is one thing that I don’t understand at all though: Going current domain and doing three things over a single wire: All fine. But if you read the specification of SWP you’ll find a lot of details where some crazy timing constraints are required. The requirement bit-rates up to 1 megabit per second for example, let alone 1.7 megabit/second in the high-speed case. I can’t come up with any use-case that even remotely needs such a high bandwidth.

Posted in Uncategorized | Leave a comment

About a failed Circuit Idea

I had a circuit idea in mind that I’ve never been able to try out. I’m working on a SWP reader device right now (that’s a device that should directly talk to NFC enabled SIM cards).

So recently while browsing through semiconductor lists I across the TSH70 OpAmp. This is a great part and it’s much cheaper than the OpAmp I’m currently using and the specs are just about the minimum requirements that I have.

Also contrary to the OpAmp I’m currently using it’s a normal voltage feedback OpAmp This allows for a new transceiver design that I came up with.


Here you’ll see the idea in action: The SWP-TX signal (1.8V digital logic) goes directly into the non-invertig input. The OpAmp circuit itself is just a voltage follower with a transistor booster (Q1).

The voltage seen at the C6 input of the SIM card should be identical to the SWP-TX signal, and in fact it is.

If the SIM card wants to transmit data it does so by drawing current (Rule of thumb: 1mA current equals to a logic one). So the task is to measure current at high speeds.

If the SIM card draws current this current will be sourced by the Q1 emitter and not the OpAmp output. The majority of current that passes Q1 emitter is again sourced from the collector.

On the top of the circuit you’ll see Q2 and Q3. These form a current-mirror. E.g. whatever current is drawn from the Q2 collector will also be drawn from the Q3 collector.

Long story short: The current drawn from the SIM card will appear at the collector of Q3 (just mirrored). Adding a load-resistor R5 converts this voltage to a current and we can measure it.

And here is how it looks like in a spice simulation:


Blue is the control signal that controls the SIM current. If it’s high the current flowing into C6 is 1mA.

Red is the SWP-TX signal. I’ll show it along with the other curves so you can see that the actual voltage across the SIM does not affect the output much.

Green is the SWP-RX signal.

This green signal looks great eh? Nice, defined edges, just a little bit of ripple. Very low propagation delay. I could directly connect this signal to a micro-processor pin and start reading data.

Except it won’t work like this. I completely missed to add some parasitic capacitance across the emulated SIM card.

Here is the same circuit with C1 added in. I’s just a tiny 10pF capacitor that should emulate the capacitance of the SIM card itself along with sockets and so on.


And this is the signal response after the capacitor has been added:


Now the received signal rings a lot, and there is also the propagation delay went completely over the roof. It’s almost half as long as the impulse itself!

What happened? Once the capacitor has been charged, and the SWP-TX signal goes back to zero there is no quick way for the capacitor to discharge!. Q1 can only source current to C1, not sink any. The only way to lose charge and lower the voltage across C1 is to slowly leak through R4. And this completely messes up the negative feedback loop of the OpAmp (not his fault!).

I could lower R4 to allow for faster discharge, but then again more current will flow through the transistors and I mess up my nice green output signal.

I could probably replace Q1 with a proper push-pull stage. That’s something I’ll try one day. Right now I’m staying with my “tried and trusted” SWP analog front-end. It has a different topology where the parasitic capacitance actually speed things up! It requires the much more expensive current-feedback OpAmp I’ve mentioned, but but it doesn’t show this defect.

Lesson learned: small parasitics can mess up things much more than expected.

Posted in Uncategorized | 5 Comments

DSP default cache-sizes not optimal?

While debugging some DSP code yesterday I came a cross a performance oddity. Adding more code lowered the performance of an unrelated function.

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.


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
Posted in Beagleboard, DSP, OMAP3530 | 7 Comments

Faster Cortex-A8 16-bit Multiplies

I did a small and fun assembler SIMD optimization job the last week. The target architecture was ARMv6, but since the code will run on the iPhone I tried to keep the code fast on the Cortex-A8 as well.

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:

    smulbb      r0, r1, r2          Pipe0
    nop                             Pipe1   (free, can be used for non-multiplies)
    smlad       r0, r3, r4, r0      Pipe0
    nop                             Pipe1   (free, can be used for non-multiplies)
    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.

Posted in Beagleboard, OMAP3530 | 5 Comments

C64x+ DSP MMU faults, and how to disable the MMU.

Two days ago, while testing some image processing algorithms on the DSP I got the following message for the first time:

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


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..

Posted in Beagleboard, DSP, Linux, OMAP3530 | 2 Comments

More on EDMA3 on the BeagleBoard/OMAP3530

Didn’t I mention that the EDMA3 on the OMAP3530 is identical to the EDMA3 of the DaVinci? As I found out this is not exactly true. There is a subtle but important difference:

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.

Posted in Beagleboard, DSP, OMAP3530 | Leave a comment

2009/2010 Status Update

So, 2010 has arrived. Time for a little status update on my multi-effect project for the BeagleBoard.

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 :-)

Posted in Uncategorized | Leave a comment

ARM NEON Optimization. An Example

Since there is so little information about NEON optimizations out there I thought I’d write a little about it.

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);

  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.


      # 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


      # 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.

Posted in Beagleboard, OMAP3530 | 37 Comments

Compiling CMEM for the Beagleboard…

Since I tend to forget these things, here’s a little tutorial how to compile the Texas Instruments CMEM and SDMA kernel-modules for the beagleboard. I don’t like the codec-engine build process, therefore I’ll compile the kernels by hand.

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...)
    # path to the kernel-sources:
    # some config things:
  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 0x80000000 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.

Posted in Beagleboard, DSP, Linux, OMAP3530 | Tagged | 9 Comments