Help me choose a starter kit

[AaronD]

So, Digilent has a deal for a USB oscilloscope, where you can "Receive $200 off of an Analog Discovery 2 just by buying one of our FPGA or SoC boards costing over $100!"

That looks on the surface like something worth pursuing (specifically looking at doing this with the 'scope), and I do have some projects in mind that might use one of those other boards, but I don't know enough yet to pick one:

• Processing at least 1080p30 video (preferably higher, but I'm unsure of what to call "enough" yet) with absolute minimal latency.  Thinking maybe 2 pixels' worth of delay maximum, since there's nothing involving the neighbors.  (grayscale, color-invert, attenuation, chroma/luma-keying, that sort of thing)  Plus some additional signals to control which features to enable at the moment and by how much.  The keyer input should be a USB "display", as a PC would see it, and there should also be a USB capture function for the PC to record the final result.  The USB connections can afford to be buffered, but the critical path between the dedicated video I/O must be immediate.
• DSP audio, probably fixed at 48kHz with 24-bit converters all around or better, or direct-digital to a set of class-D chip amps or something like that.  Total of 6 channels in and 6 channels out physically, plus 8x8 over USB for recording/playback, USB HID for control by a custom PC app, and some GPIO for physical controls and indicators.  (potentiometers, encoders, buttons, and LED's)  The functions here are a smattering of EQ's, gains, crossover filters, limiting, mixing, and the occasional A/B switch instead of a mixer just to keep the other input out of the way.  Like the video processor, this also needs to have absolute minimal latency between the dedicated audio connections - thinking maybe 2 samples max. at 48kHz - but the USB side can afford a good buffer.

Those should be separate devices, not combined, so that a problem with one doesn't take down the other.  And I'm okay to build up to all that instead of expecting it to "just work" as a complete n00b: a stereo-to-2.1 USB sound card with my own custom DSP, for one example of an intermediate project.


I know nothing about FPGA's at the moment, except for the basic theory and one freshman "intro to logic" lab class in college about 10 years ago (I went a slightly different direction), and my proficiency in the "sequential world" is only on 8-bit MCU's, so I'll need to start from almost-scratch no matter which way I go, and build up to it.  And because of the tight latency requirements, I suspect that I'll have to write my own code instead of using a 64-sample library or something like that.

_{The latency requirement isn't completely naive, although it could be a little bit.  I'm thinking about completely replacing an actor's vision while in character, and avoiding an audio comb filter through an inch or two (a few cm) of foam, while replacing what doesn't get through the foam's acoustic lowpass.  (mic outside, speaker inside, and vice versa for speaking, plus an off-the-shelf radio pack to connect it to a larger sound system)  For most applications, including a "normal" USB sound card or live sound reinforcement, 64 samples of latency at 48kHz is probably fine: you'll get more of a difference by moving a mic or speaker, or the listening position, by just 2 feet (less than 1m).}

Does anyone know a good starter board for that goal (the bullet points, and where I'm starting from), that would work with this deal from Digilent?
(or is there something even better that I haven't seen yet?)

It might not matter yet at this point, but the end project will probably require all custom PCB's just to fit everything in - dev boards are too bulky for the space I'm going to have - so I'd also need to have good documentation of what the chip itself actually needs, and be able to get the chip and its support parts on their own in single quantities...probably a couple of years from now.

[fluxgate]

Your undertaking seems a little bit too much, to start off from.
First off: Running Logic at ~100MHz is usually no problem. However, above that you need to be very carefully about timing in your design. This alone is a university course worth topic.

I don't really understand your goal, do you want to pass uncompressed 1080p30 Video Data through USB?
 
For processing Video Data there are ready to use logic blocks for Vivado, however they usually involve a cpu for configuration and control, which uses quite complicated AMBA Bus.

The Zybo Boards have HDMI out and In. The Zedboard only has 1 HDMI output port, but is probably the best documented board.
However, getting used to the Zynq environment including everything around it, is an absolute cluster fuck for a beginner.

With FPGAs you should do very little steps, otherwise you'll get frustrated very quick.

[AaronD]

Your undertaking seems a little bit too much, to start off from.

Well, I do have some other project ideas to tackle first, to build up from practically nothing to where I *can* manage the ultimate goal.  The USB stereo-to-2.1 sound card that I mentioned in the OP is just one of them, but all have something to do with live sound or video.

First off: Running Logic at ~100MHz is usually no problem. However, above that you need to be very carefully about timing in your design. This alone is a university course worth topic.

That's part of what I need to learn.  If I just throw a bunch of Verilog at it, will the toolchain figure all that out for me?  (within the chip, at least)  Or is that something I need to watch out for as well, in addition to the relative trace lengths on a custom PCB?  (once I get to that point of course; I'm pretty sure I'll be starting on a dev board that has all of the PCB work done already)

I don't really understand your goal, do you want to pass uncompressed 1080p30 Video Data through USB?

Not necessarily.

My primary goal with that one is to have a strobe light appear on the display in significantly less than 1 frame after that light hits the camera.  Preferably less than one line, and ideally just a handful of pixels' worth of delay.  No explicit buffer of any kind in that path: just send the pixel data straight through, with changes as it goes, and delay the original sync's by just that much.  Definitely an "analog" feel here, in the sense of having already made a VGA processor with an entirely analog signal path and the sync's literally wired straight through.
That low latency is made possible by not having any kind of processing that involves neighboring pixels.

The PC and USB connections are auxiliary to that, and are only to have a "computer monitor" input to key over the critical path(*), and to give the same PC something to record.  Whether the USB is compressed or not is immaterial for the high-level requirements.  I suspect it would have to be, as uncompressed HD video is a LOT of data, even though USB 3 can technically cope with it.
_{(*) For each pixel independently, if the PC's pixel = 0,0,0 show camera, else show PC; and "no valid signal" from the PC (USB unplugged, for example), also shows the camera.}

I was kinda hoping, though, to just drop in a library for each that would play nice together, and end up with a composite USB device that appears to every PC without installing drivers, as a display adapter and a capture card.  Nothing special about either of those on the PC side, and they "just work" up to and including their respective frame buffers that I can then interact with.  My custom code would then be entirely focused on the super-low-latency camera-to-physical-display path, which would manage its own physical connections to those devices, and access the USB libraries' frame buffers asynchronously.  That might be what you were thinking of next, perhaps?:

For processing Video Data there are ready to use logic blocks for Vivado, however they usually involve a cpu for configuration and control, which uses quite complicated AMBA Bus.

Like I said earlier in this post, do I really have to mess with that configuration and complicated bus?  If I just throw a bunch of Verilog and static settings at it, will the toolchain figure all that out for me so that it "just works"?
(demonstrated by my custom code simply copying one frame buffer to the other as proof-of-function, possibly with a bitwise-NOT (easy color-inversion, or photographic negative) in between, to show that it is indeed using my code)

The Zybo Boards have HDMI out and In. The Zedboard only has 1 HDMI output port, but is probably the best documented board.
However, getting used to the Zynq environment including everything around it, is an absolute cluster fuck for a beginner.

Hmm...  Is there a "video playground" sort of thing, like Analog Devices' SigmaDSP chips and SigmaStudio IDE for audio?  Cheap hardware, free IDE, put a bunch of blocks together and mess with your HDMI camcorder and/or computer monitor in weird, wacky, wonderful, and fun ways?  It probably won't have the sub-frame-instant throughput that I'm looking for in the final project, but at least it's *something*, right?  (and it would probably be enough to find a permanent home in one of my "build-up" projects)

With FPGAs you should do very little steps, otherwise you'll get frustrated very quick.

Likewise with the 8-bit MCU's that I'm presently familiar with.  I wasn't an instant expert with those either, which is part of what the "build-up" projects are for, in addition to each having its own usefulness.
(you *might* argue that a Configurable Logic Cell (CLC) peripheral in an 8-bit MCU is a *very* limited FPGA, but that's probably stretching things a bit)


I think my university did a disservice by making it look so easy 10 years ago, although I'm not really sure what else could have been done for a freshman intro class.  Like I said earlier in this post, we pretty much just threw some Verilog at it and watched it work.  I forget which chip or IDE it was, but it was one of the larger fine-pitch packages that's not BGA, on a university-owned dev board.  Waaay overkill for what we were doing with it, but that's pretty much how it worked for us in class.

[asmi]

Sorry to break it to you, but you are in for a big shock. USB on FPGA is super-complex topic because this bus by design heavily leans on a software. There is no "USB library" for FPGA, you can buy a commercial USB device IP (for a lot of $$$), but it will also require a software stack on top of it. In short, unless you are intimately familiar with USB spec, this will be a major undertaking.

You seem to fundamentally misunderstand what FPGA is. If you think it's the same as MCU (hence your notion of "libraries"), you can not be farther away from thuth. So if you really want to get into this, you've got to start from the basics first so that you will get an understanding what they are, what they can do, and what it takes to do something with them. It's a super complex device by neccessity, as it's as close as an average person can ever get to designing your very own custom digital integrated circuit. So when you design for FPGA, you are not writing the code, but describing the hardware. it is crucial to understand this (and all that this implies), otherwise you are going to be running into problems.

Also, if you want to know what it takes to design a custom board for FPGA, take a look at the project in my signature. I've specifically designed it for beginners to help them get into this topic, as well as to provide a template for their own projects.

[SMB784]

Before you start working with an FPGA, ask yourself this:

Could you wire up a circuit on a breadboard that multiplies or adds two numbers together? What about a circuit that computes a moving average? Could you wire up a working CPU on a breadboard using only logic gates? Would you know where to begin?

When you work with FPGAs, that's exactly what you are doing. The on-chip FPGA fabric (i.e. the LUTs, BRAMs, DSPs, interconnects, etc) is your breadboard. The code you are writing isn't a procedural language like C or Python, it's a list of commands that tell the place & route software how to link up the various circuit elements to create whatever circuit design you want to implement. If you want to performs a certain calculation, you first have to design a circuit that can make that calculation, and then you have to actually wire it up in the FPGA fabric. If you want to create a USB interface, you have to wire a circuit that can handle USB traffic correctly, which means basically emulating a dedicated USB chip inside your FPGA.

This is really hard. It's not really a project for a weekend, more like a couple of years to really get it right. Furthermore, other people have already done it, and in fact some have even made a business out of selling a chip that they probably designed and tested in an FPGA that will do exactly what you are looking for.

Why spend years reinventing the wheel while senselessly spinning your own?

FPGAs are great tools and can be a ton of fun to learn and work with. There is, however, a steep learning curve, and you can waste years of your life doing something that won't perform the way you hope, and that someone else has probably already done better. This is almost always true for something like USB, Ethernet, HDMI, etc

It's far easier to just find (or buy) some IP cores, and spend your valuable time learning how they work and how to link them together. Then you can focus your time on the part of the design that is truly unique and specific to your task.

If you want an example of the level of effort involved in doing something that sounds simple, check out this thread: https://www.eevblog.com/forum/fpga/fpga-vga-controller-for-8-bit-computer/

BrianHG has created an open source DDR3 memory controller from scratch. The incredible job he did took him over a year and he was already an expert with years of experience before he started.

[dietert1]

There is no easy trick, it's hopeless to optimize at the beginning. When i wanted to learn FPGA i got a chinese Spartan 2 kit from ebay. The IDE was a free Xilinx download. Soon i found interesting open/free IP downloads and i had some digital audio going after half a year. It was a digital crossover with SPDIF in and 6 analog channels out. The Spartan 3AN implemented a DSP, plus a picoblaze to handle LCD and the knobs, plus all the glue.

To be honest, later i made something similar with an Arm Cortex and a TFT touch screen. It was all digital with fiber links in and out and with the DACs inside the active speakers.

Regards, Dieter

[AaronD]

Sorry to break it to you, but you are in for a big shock. USB on FPGA is super-complex topic because this bus by design heavily leans on a software. There is no "USB library" for FPGA, you can buy a commercial USB device IP (for a lot of $$$), but it will also require a software stack on top of it. In short, unless you are intimately familiar with USB spec, this will be a major undertaking.

You seem to fundamentally misunderstand what FPGA is. If you think it's the same as MCU (hence your notion of "libraries"), you can not be farther away from thuth. So if you really want to get into this, you've got to start from the basics first so that you will get an understanding what they are, what they can do, and what it takes to do something with them. It's a super complex device by neccessity, as it's as close as an average person can ever get to designing your very own custom digital integrated circuit. So when you design for FPGA, you are not writing the code, but describing the hardware. it is crucial to understand this (and all that this implies), otherwise you are going to be running into problems.

I guess I was over-generalizing the term "library", to mean "a block of stuff" that someone else made, at least some of which does something useful in my project.  For an MCU, that library is a collection of procedures; for an FPGA as I presently envision it, it's a collection of pre-fab logic chunks.  A multiplier, for example, or a (de)serializer between a specific protocol and a large array, etc.

Take the input array of bits as the input to an array of inverters, which then feeds the output array of bits, with HDMI (de)serializers on each end, and I've inefficiently made a real-time negative image.  More efficient would be to keep it serial and run the 4 decoded bit streams through only 3 inverters for the 3 colors, 1 per color, and 1 gate delay for the video clock to keep it lined up.  There might also be some logic to only process certain parts of the stream and leave the rest unchanged so that it's still a valid HDMI signal, but you get the idea.
(this is bit-wise digital inversion, not an analog inverting opamp, but if the color information is unsigned full-range, then inverting all the bits does indeed reverse the range)

An FPGA as I presently envision it, can take several different forms, all of which are a collection of independent logic functions that don't necessarily even have a clock, although a clock is still handy for a lot of low-mid-level functions like flop-flops and counters/timers.

• In one form, it's just like a bunch of CMOS logic chips on a breadboard, except that you have a sea of them instead of just a handful.  The programming is to connect them, or not, in the correct pattern to do what you want it to do.
• In another form, it's a bunch of lookup tables instead of any primitive logic functions at all.  Want a 2-input NAND?  Program that lookup table to 1,1,1,0 for the relevant inputs, and copy that pattern so that the remaining inputs don't matter for that cell.  Then connect those "custom gates" together as in the previous point.

You *could* make an MCU in there, that runs a sequential program, but you don't *have* to.  What's the boundary anyway, between a general-purpose MCU that can itself be programmed later, and a single-purpose hard-coded USB stack?  Both are sequential state machines, which can be made with just a ton of discrete logic and a clock.

_{I actually did make an MCU from scratch in Ladder Logic for an industrial project, that ran my own custom instruction set.  It was even multithreaded!  The purpose was to have each thread track an assigned piece through a machine while doing a series of operations on it, with multiple pieces in the machine at the same time.
(For those of you that aren't familiar with it, Ladder Logic was originally invented to describe electro-mechanical relay schematics with lots of individual relays (sound familiar?), and was later adapted to describe a computer program that tries to emulate that functionality with improvements.  I was using one of the many software versions.)}

I was just thinking that "USB display adapters exist" and "USB capture cards exist", so surely someone has a complete hardware-logic implementation of each that I can just drop in, right?  But I guess I shouldn't be surprised to find that they're stupidly expensive (and probably behind NDA's) compared to having an additional HDMI pigtail that goes to a mass-produced thing.

Also, if you want to know what it takes to design a custom board for FPGA, take a look at the project in my signature. I've specifically designed it for beginners to help them get into this topic, as well as to provide a template for their own projects.

Thanks!  I'll have to spend a while looking that over.

[AaronD]

There is no easy trick, it's hopeless to optimize at the beginning. When i wanted to learn FPGA i got a chinese Spartan 2 kit from ebay. The IDE was a free Xilinx download.

I wonder if this would be a decent playground to grow into?  I'll have no idea what I'm doing with it to start with, or what projects to use it for, but it seems to have elements of everything.  And for $100 itself, it's (barely) eligible to get me $200 off the USB oscilloscope and logic analyzer that I mentioned in the OP.  I should probably learn about the ARM core on something smaller and cheaper (maybe a RasPi Pico?), but I'll have this available once I do...

Soon i found interesting open/free IP downloads and i had some digital audio going after half a year. It was a digital crossover with SPDIF in and 6 analog channels out. The Spartan 3AN implemented a DSP, plus a picoblaze to handle LCD and the knobs, plus all the glue.

To be honest, later i made something similar with an Arm Cortex and a TFT touch screen. It was all digital with fiber links in and out and with the DACs inside the active speakers.

Regards, Dieter

Nice!  And yeah, I'm leaning heavily towards a sequential MCU for audio DSP as well.  Lots of instructions per sample, even when spread across a bunch of channels at a fast sample rate.  Compared to video, which has millions of pixels at a very low sample rate, but the sheer number of "channels" (counting each color of each pixel separately) adds up fast.

[dietert1]

Yes, Digilent is a good choice and Zynq is a good choice. Cora boards are for learning, they have their limitations. Digilent provide downloads to get users going, e.g. Petalinux. The boards come with built-in USB programmer, so if you succeed to install and run Xilinx Vivado, that's a good start. It gets pretty complex once you try to build and connect peripherals, but Digilent provide examples for that, too. Meanwhile the web has many free Zynq examples.

Regards, Dieter