Old dog learning new tricks here. Noob ahoy...
I'm utterly ignorant of XMOS. I'm working on a project that's a "dog's breakfast" of technologies. The standard "open the parts catalog" design approach leads to a large board loaded with components. The "do it all in an FPGA" implementation style results in a lengthy development schedule with significant project risk.
Although I have known about XMOS for many years and even purchased a development board or five to play with, I never quite found a good application fit for XMOS. I believe that has changed for this project but I want to check in with the cognoscenti here.
The highly proprietary nature of what I'm doing precludes me from sharing the details of this work here but in essence a X200 device coupled with a small, cheap FPGA provides the necessary processing.
There are two major interfaces:
1. UAC 2 USB to audio spigot -- This project does involve audio in the traditional sense. UAC 2 is just a convenient way of getting discrete time data to/from a Linux application with almost no fuss. Drivers? We don't need to write no stinkin' drivers. If you want to do UAC 2 USB to Audio, XMOS is a very good choice.
2. EtherBone interface. EtherBone was developed at CERN; it's a bridge between UDP packet data and a WishBone bus. WishBone is an on chip bus often used to interconnect the components of a SoC. There is nothing magic about WishBone save its simplicity. AXI could be used as well. The FPGA is configured over the "EtherBone", too. XMOS's "hardware is software" approach, makes it easy to parse data in a UDP packet and wiggle pins to emulate a simple bus. IP over USB (CDC_ECM) could have be used but the long term goal is to eliminate USB.
In just two days, I was able to get a first cut "EtherBone" implementation running on a X200 Explorer using the XMOS Gig-E networking application note as a starting point. EtherBone took six months to implement directly in an FPGA since implementing ARP and DHCP are required. The throughput and latency of the EtherBone implementation done on XMOS isn't quite as fast as an FPGA implementation but it seems "good enough".
I also was able to customize the UAC2 app for the X200 MC audio board for my nefarious purpose. Mostly by removing unneeded digital audio interfaces like SPDIF. Only I2S is necessary which is connected to the FPGA.
I managed to get four USB to UART bridges working on ten (yikes!) cores starting with lilltroll's two USB to UART example. Creating the necessary descriptors was a PITA. Ten cores seems a bit expensive for such a simple function. Goodbye (maybe), FTDI.
Not bad for a weekend's work. I have several questions....
1. Is there anything I might have missed? An example is the requirement for xud to run on a core with at least 80 MIPs of performance. I'm still not entirely sure that I understand the limitations on assigning software functions to cores.
2. Has the throughput of the XMOS TCP/IP stack been measured? I believe its based upon uIP which both good (small footprint) and bad(low throughput).
3. Are multiple UDP ports supported by the XMOS TCP/IP stack? Different UDP ports can be used to segregate FPGA configuration data from normal bus transactions.
4. Does the X200 series have a "low power" mode? (USB suspend and resume must have been implemented.) The entire X200 device can just be "turned off". No clocks, no core power, etc. This project requires a super lower power "sleep state" where either elapsed time or an external signal can wake the system up. No "state" needs to be maintained across power cycles. I'm trying avoid using an external MCU that runs continuously to manage power.
I welcome your comments. Thanks for reading this query and providing insight....
Farangutan
XMOS for UAC2 / EtherBone
-
- New User
- Posts: 2
- Joined: Fri Feb 26, 2021 4:22 am
-
- XCore Expert
- Posts: 580
- Joined: Thu Nov 26, 2015 11:47 pm
2. The TCP/IP stack is slow. I use the LwIP implementation and I can get about 25kByte/sec per port when connected to telnet (raw) on Linux. I am sure it can be optimized further but I don't need more than that.
3. Multiple TCP ports are supported. I haven't tried multiple UDP ports, but I don't see why not. Like I say, I use LwIP, not uIP.
3. Multiple TCP ports are supported. I haven't tried multiple UDP ports, but I don't see why not. Like I say, I use LwIP, not uIP.