Project

General

Profile

Actions

Feature #2484

closed

Architecture of USB E1/T1/J1 adapter

Added by laforge over 6 years ago. Updated over 3 years ago.

Status:
Resolved
Priority:
Low
Assignee:
Category:
-
Target version:
-
Start date:
09/02/2017
Due date:
% Done:

100%

Spec Reference:
Tags:
E1

Description

So far we have for many years the Osmo-e1-xcvr board which remains unused. It contains the LIU but no logic that can actually control the LIU and/or process the data.

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

Related issues

Related to E1/T1 Hardware Interface (including icE1usb) - Feature #3242: develop software for E1 framing / deframing, CRC4, alignment FSMResolvedlaforge05/06/2018

Actions
Related to E1/T1 Hardware Interface (including icE1usb) - Feature #3237: Come up with GPS-DO design for E1 InterfaceRejectedvogelchr05/04/2018

Actions
Actions #1

Updated by laforge over 6 years ago

  • Status changed from New to Stalled
  • % Done changed from 20 to 40
In addition, a smaller single-port device could be dne 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.

Actions #2

Updated by laforge over 6 years ago

  • Subject changed from Architecture of USB adapter to Architecture of USB E1/T1/J1 adapter
Actions #3

Updated by laforge about 6 years ago

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

Actions #4

Updated by laforge about 6 years ago

Dieter has had the idea to build this using the PRU unit[s] of a TI AM335x processor.

The idea would be to at least prototype using a beaglebord + the PRU-Cape

The main differences of a PRU based solution are:

+ could run OsmoBSC or OsmoMGW or whatever one would want to run on the ARM core
+ can directly provide Ethernet, so no worries with custom USB drivers on Windows (Dieter)
0 no need to learn about XMOS programming (But then, PRU programming...)
- need to investigate Linux kernel interface to PRU (remoteproc, rpmsg, virtio)
+ not having to rely on exotic low-stock part (XMOS)
0 both variants could be produced in series
- LIU+XMOS likely lower cost than AM335x-SOM+LIU
- not possible in a "USB Adapter form factor for usb-powered use" with Laptop or as general peripheral. Well, actually, yes, using USB gadget on the AM335x, but it will be rather large

where "+" means advantage for PRU, while "-" means disadvantage of PRU compared to XMOS. "0" is neutral.

Actions #5

Updated by laforge almost 6 years ago

  • Related to Feature #3242: develop software for E1 framing / deframing, CRC4, alignment FSM added
Actions #6

Updated by laforge almost 6 years ago

  • Related to Feature #3237: Come up with GPS-DO design for E1 Interface added
Actions #7

Updated by laforge almost 6 years ago

thread about clock indications: http://listserv.isdn4linux.de/pipermail/isdn4linux/2018-May/006316.html (make sure to read all three messages)

Actions #8

Updated by laforge almost 6 years ago

  • Tags set to E1
Actions #9

Updated by laforge over 3 years ago

  • Status changed from Stalled to Resolved
  • % Done changed from 40 to 100

by now the ICE40 based approach pretty much won.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)