Feature #2484
closed
Architecture of USB E1/T1/J1 adapter
Added by laforge over 6 years ago.
Updated almost 4 years ago.
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
- 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.
- Subject changed from Architecture of USB adapter to Architecture of USB E1/T1/J1 adapter
an a-least-two-port device is particularly useful in case one wants to do E1/T1 protocol tracing.
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.
- Related to Feature #3242: develop software for E1 framing / deframing, CRC4, alignment FSM added
- Related to Feature #3237: Come up with GPS-DO design for E1 Interface added
- Status changed from Stalled to Resolved
- % Done changed from 40 to 100
by now the ICE40 based approach pretty much won.
Also available in: Atom
PDF
