Good Audio FPGA Development Board Candidate

rolfs · Joined: Mar 20, 2014 Posts: 2 Location: germany

I bought a new Cyclone 5 Platform for my project. It has the ability to also include ARM functions, eg for MIDI.

And : C5 has so much power and resources for programming Smile

jksuperstar · Posted: Thu Mar 20, 2014 9:05 am Post subject:

Very similar, although they look like they're >$100US more per board.

engineer · Joined: Mar 31, 2014 Posts: 11 Location: Frankfurt / Germay

Are you satisfied with Vivado?

I am struggling no for more than 3 years and still operate with ISE if possible.

Regarding MUSIC FPGA: There is some Progress in a germin microcontroller Forum starting a universal PFGA baord suitable for Audio.

JovianPyx · Posted: Thu May 28, 2015 1:24 pm Post subject:

I'm testing Vivado WebPACK (2014.2). Anything after that requires a 64 bit machine. When I initially looked at Vivado, there was no WebPACK version. So seeing it a few days ago was a pleasant surprise. More advanced stuff, like the system generator for DSP aren't included, but the core stuff is all there and the license while node locked and device limited, is free.

JovianPyx · Posted: Thu May 28, 2015 4:10 pm Post subject:

Vivado WebPACK is working, though there was some confusion over licensing. I tried to follow the instructions in a training video that shows how to add an AXI4-Lite interface to a project. I had selected to simulate with AXI BFM simulator which failed because I don't have the (need to pay for) license for that piece - however, the interface was installed into the project since the interface itself is licensed by the ISE license. The simulator complained about the license, so only that part is not usable. I had to add the ISE license for the AXI4-Lite stuff.

I will next be messing with some hello-world things that actually does stuff on the Zybo board.

JovianPyx · Posted: Tue Jun 02, 2015 7:58 pm Post subject:

Using Vivado 2014.2 WebPACK and a Zybo devboard, I've been able to add a small project that just copies the slide switches to the LEDs. So it found and used the correct cable driver; synthesis, place and route etc all worked. Next I'll play with AXI-4 Lite.

gdavis · Posted: Sun May 08, 2016 1:49 pm Post subject:

I'm currently taking a class that's using the Zybo board and just started playing around with designing a synth with it. Have you gotten any further with yours?

I'd like to implement MIDI over USB (I have a USB midi keyboard that I could use with it) but not sure how difficult implementing USB would be without an OS. Google actually led me back here Smile

elektromeister · Joined: Feb 18, 2013 Posts: 32 Location: Freiburg

This is exactly also my question. I need a solution to attach MIDI via USB to eelctronic instruments.

This is because modern Controllers send more data per time and have only USB. I already had alook at USB, but think it is much work to do that.

A recommendation was to setup a linux system to define a fully functional host in an FPGA.

Is there an easier way? MAy<be there is a vendor with a USB host core to directly install to the FPGA and a low level app, which analyses MIDI.

I mostly need the fast controller data to drive the gear without remarkable latency.

gdavis · Posted: Wed Jan 11, 2017 2:14 pm Post subject:

JovianPyx · Posted: Thu Jan 12, 2017 7:30 am Post subject:

Agreed that USB is a PITA. I've been able to create MIDI musical instruments on several FPGA boards including the Zybo, but they all run MIDI as a serial connection at 31.25 kbaud with the standard optoisolator converter. One main reason for the is that I have older equipment.

I don't gig out, so being tied to a computer is not a problem for me and I need the computer to program the devices anyway. The UART for plain FPGAs is just some Verilog code, for the Zybo, I believe I used one of the UARTs in the on-chip I/O device array.

I'm also working with Raspberry Pi which I've found to be powerful enough to support 32 voice polyphony on several designs. Even with the Raspberry Pi, I've decided to do hardware MIDI into the serial console port because not all USB MIDI devices are support by the Raspberry Pi software. I had to write my own driver for the serial port because of kernel driver buffering weirdness. Test timing shows that I achieved a latency (MIDI note-on to sound) of 1.5 milliseconds. No idea what is acheivable with USB 2.0. I may eventually try USB to MIDI if I can find a device for which there is a Rpi driver.

State Machine · Posted: Mon Jan 30, 2017 8:18 am Post subject:

With respect to MIDI over USB, this is probably relevant to what your trying to achieve. It utilizes the PJRC Teensy board that utilizes a Freescale 32 Bit ARM Cortex MCU series. Powerful and low cost and a very tiny board Wink

.

gdavis · Posted: Mon Jan 30, 2017 1:34 pm Post subject:

Thanks, but not quite. The teensyduino can only act as a USB "device". We want to implement the opposite end of the connection - the USB "host", so that we can connect a MIDI controller directly to the synth without a host (PC) MIDI router in between.

Many people don't seem to realize this, but USB is a master/slave interface. You can't connect two slaves or two masters together, there has to be one master ("host") and one or more slaves ("device"). That's why each end of a USB cable has different connectors.

And the FPGA chip on the Zybo already contains 2 ARM cores and 2 USB controller cores, so with the Zybo we don't need the hardware. If we want to implement the USB host with an OS, we can just load Linux onto the Zybo. I was hoping to avoid that, though it's probably the easiest way to go.

I've actually started working on a bare metal USB host driver for the Zybo. I haven't gotten very far, basically just initialized the USB controller as a host to detect device attachment and establish connection at the supported speed. Trying to read the device descriptor at the moment, then need to see if I can configure the device and start receiving data.

It's been... educational. I think I'm starting to see why bare metal USB host drivers aren't common. It's a complicated process and the complete link involves several layers of communication that's really more suited to something with a task management scheme, e.g. an OS. I'm real curious to see if I can at least get some basic communication going though.

JovianPyx · Posted: Mon Jan 30, 2017 2:50 pm Post subject:

That's quite interesting gdavis. I've not yet dove into the Zybo and a USB driver is about the last thing I want to do... I'd wanted to use the Zybo FPGA to build a synthesizer and then have it controlled by the ARM either with a sequencer running there or via a way to pipe MIDI stuff into it via Linux and kernel driver. At this point, I've been able to make the Zybo FPGA work as a synth, but it uses an external (PMOD) DAC and an external connection with 6N138 to a soft UART. (path of least resistance approach so to speak).

In the Raspberry Pi world, I do use USB devices, but there are already kernel drivers for most of that. My root file system is on a USB hard drive (which is faster than the class 10 microSD card). The only mystery is, in fact, USB MIDI. I've been able to get a MIDIsport 2x2 working through a rather frustrating driver installation process. I'd purchased a sort of "generic" USB MIDI cable, but I can't find a Linux driver for it. It works under Windows because there is a driver somehow incorporated in the device that installs and then the device shows up in Windows as a MIDI device (and it works). This kind of stuff is why I opted to use the Raspberry Pi UART port (hardware UART inside the ARM) for MIDI. The fun part of that was disabling the kernel driver's activities and making the UART work at 31250 baud. Given my limited time on this earth, I'd prefer to write synth DSP code and not so much driver stuff...

blue hell · Posted: Mon Jan 30, 2017 3:21 pm Post subject:

The cable probably is a HID device, for which windows and osx come with builtin drivers .. maybe linux has something for it too?

JovianPyx · Posted: Mon Jan 30, 2017 3:32 pm Post subject:

blue hell · Posted: Mon Jan 30, 2017 4:14 pm Post subject:

The idea of HID (Human Interface Device) is that it is general purpose, and that it works just as well for cheap american junk as for cheap chinese. In other words, it is a general purpose driver and not a device specific one. HID supports keyboards, mice, MIDI and other stuff.

Re. MIDI over Ethernet. When you'd use UDP/IP latency should be OK by default. When using TCP/IP be sure to turn off Nagle's algorithm (or in windows speak: activate TCP nodelay (which is a socket option)) and then it should be fine too.

When you'd send it as plain MIDI messages with no further encoding you'd be compatible with Midi Tangle. This might save some programming time here and there. Midi Tangle supports TCP and I think it does UDP as well, and it can both be a server and a client.

JovianPyx · Posted: Mon Jan 30, 2017 5:20 pm Post subject:

Over my direct connect LAN, yeah, UDP is fine.

I'll research about HID with respect to Linux, but I've not run across it so far oddly.

Currently I'm just connecting the MIDI current loop receiver-to-logic to two different Pi boards and it works fine and I don't have ground loop noise problems (I did expect them tho) I'll probably just add another connector or two once I get a crimping tool. I now have 4 synth capable pi boards Very Happy

gdavis · Posted: Mon Jan 30, 2017 7:06 pm Post subject:

I looked up the midisport 2x2. The manual for the Anniversary Edition states that it is class compliant and will work with standard drivers for basic MIDI functionality. The M-Audio drivers are only needed to access the advanced features. Previous versions of the midisport are not class compliant and require the M-Audio drivers.

I'm hoping my MIDI controller is a class compliant MIDI device and plan to write a driver supporting that (which should be standard and work with any class compliant MIDI device) should I get that far Wink

gdavis · Posted: Fri Feb 03, 2017 11:24 pm Post subject:

Phew, I finally managed to read some of the default descriptors. What a chore, but now I know I can move data across the bus. Really need to take care to maintain data coherency between the CPU, the USB controller DMA engine and DRAM. Apparently the cache was enabled by default (thought it wasn't supposed to be in a standalone application) which caused me a lot of grief.

The device descriptor of my MIDI controller indicates one possible configuration. OK, that should simplify things a little Smile

The configuration descriptor indicates two interfaces:
Interface 0 indicates class audio and sub-class audio control.
Interface 1 indicates class audio and sub-class MIDI streaming.

I think we're onto something here.

The audio class is a USB standard class which has it's own specification. The audio class specification defines 3 sub-classes: audio control, audio streaming and MIDI streaming.

It looks like an interface with the audio control sub-class is required by the audio class specification but doesn't really do anything in a pure midi controller which doesn't support any audio.

The MIDI streaming sub-class has another specification that defines this interface. The USB architecture provides for expanding the functionality beyond the standard which would require a device specific driver, but I think the standard part of the interface should give me basic MIDI control.

BTW, there seems to be a hardware bug on the Zybo board that intermittently prevents the USB PHY from being detected, preventing the port from powering up. I did some searching and I'm not the only one who has seen this. The PHY reset signal is connected to one of the Zynq PS GPIO's, so I was able to enable that pin and toggle it during my USB initialization to reset the PHY again after power on reset. Looks like that may have done the trick but I've gone long stretches without it failing before so not quite ready to say for sure.

gdavis · Posted: Tue Mar 07, 2017 5:29 pm Post subject:

OK, finally some progress worth reporting. After being able to read the descriptors reliably and starting to gain some understanding of the USB host stack architecture, I spent some time reorganizing my code then set out to enumerate the device.

Lots of descriptors to sort through and a lot of work to parse them. And so far all I've done with all that information is to locate the MIDI In endpoint. With the endpoint identified, I can now receive MIDI messages from the controller Very Happy

I'm just dumping raw data at this point but I recognized some note on messages so it seems to be working. Now I just need to handle the messages and do something useful with them.

Hell of a lot of work for something conceptually so simple as hooking up a MIDI controller. If that was my only goal I'd say it's not worth the effort, but this is something I've been curious about so I'm happy to have learned something new.