XMOS Approach

Matching XU[F]216 parts with quad-E1 interface

The interface of the LIU is
  • receive data + clock (output)
  • transmit data + clock (input)
  • SPI for control (SDO,SDI,SCLK,CS) + IRQ
  • LOS (loss of signal) output (can be read via SPI, not required on controller)
Based on what we know about XMOS, this would need:
  • four 1-bit ports for rx/tx+clk per E1 Line
  • three shared 1-bit ports for SPI (shared)
  • part of a multi-bit input port as IRQ input
  • part of a multi-bit output port as CS output

As a result, a XMOS based device for four E1 ports needs 19 1-bit ports plus 2x 4-bit ports. This is possible with a XU[F]216 part in TQFP-128 package.

No I/O voltage translation is required, and plenty of pins remain unused for LEDs or control of a GPS-DO to provide a proper clock reference.

On the USB side, isochronous endpoints should be used for the bitstream. The question in terms of software is how much processing should the XMOS code do, and how much do we perform on the host CPU. Classic E1 interfaces perform functions like
  • frame synchronization
  • (optional) CRC-4
  • timeslot de-multiplex
  • (optional) HDLC inside signaling slots

Single-Port device with XU[F]208

In addition, a smaller single-port device could be done with a XU[F]208
  • its 7 single-bit ports are used for RD/RK, TD/TK, SPI_MOSI, SPI_MISO, SPI_CLK
  • a single line of one 4-bit port is used for SPI_CS generation
  • a single line of one 4-bit port is used for IRQ input

This means that a smaller single-port device should be possible to support from the same firmware, as even the CS/IRQ will use a partial 4-bit port, like in a 4-port design.

So I think in terms of a hardware architecture, it is quite clear how a design would look like, if I ever find time to actually implement it.

Note: an a-least-two-port device is particularly useful in case one wants to do E1/T1 protocol tracing.

Add picture from clipboard (Maximum size: 48.8 MB)