Example SPDIF decoder

[mikepurvis]

Hey XCore folk,

I'm curious to understand more about the design of the SPDIF decoder which is available on this page:

http://www.xmos.com/products/software%20components

It's based on polling a 12 Mbps wire at 50Mhz, with a state machine that handles the case wherein a bit is sampled five times instead of four—and the logic is all hand-tuned ASM. All of that seems a little insane—shouldn't it be possible to write a thread that simply blocks on an input pin transition, and then references a high-resolution timer to determine if multiple same-bits were received between transitions?

Are there limitations in how events/interrupts work which would have led to the design of the SPDIF example, or is there something else there which I'm not seeing?

Thanks!

[mikepurvis]

Anyone have thoughts on this? I haven't been able to acquire development hardware yet, but I'm trying to understand this example in order to get a better sense of the capabilities of the XMOS architecture and XC language.

[Ross]

Hi mikepurvis,

Welcome to the forum.

Yes it is not exactly the easiest starting point - it is highly optimised! Its written for speed and can deal with 192kHz even when other threads are active.

Anyone have thoughts on this? I haven't been able to acquire development hardware yet, but I'm trying to understand this example in order to get a better sense of the capabilities of the XMOS architecture and XC language

I would say that other examples may be a better starting point for this, maybe even the S/PDIF tx code - this is all in XC.

[mikepurvis]

Hi Ross,

Thanks for the reply!

I can definitely see that it is a very optimized implementation of the polling approach to the problem. What I'm struggling to understand, though, is why that approach is necessary or superior to an event-based approach. Based on my limited understanding of the XC select statement (and other evented IO systems), it seems it should be possible to simply block the thread on a pin transition, rather than having to rapidly poll.

Does select not work this way, or is there some overhead or other cost which I'm not seeing? What is it about this approach which makes it less efficient than rapid polling?

Thanks again.