Lee

I think you should look in to MIPI from a hardware protocol perspective before committing to that route. The issue isn’t the physical connector, but the complexity of the protocol. I found some open MIPI cores. idk if you’re allowed to use open cores, but if they fit in your FPGA (with whatever other logic you need for your CPU and glue logic), then that may work, but if I were a student I’d probably be looking for a simpler interface where I can have the FPGA control the flow of data (like request 1 row of pixels at a time given the memory constraints).

Outputting to VGA with an FPGA is fairly easy, but depending on what you mean by “image processing”, this may be too big of a project given you’re the only hardware engineer or maybe all you mean is to take the video input and output it to VGA without any further processing. You did mention wishbone, so I guess if you’re planning to reuse a bunch of Open Cores, that could simplify some things.

How much RAM do you have on your dev board? How long of a video do you want to do?

USB2 is fast enough for uncompressed 640x480 @ 24 fps @ 24bit color: 640 * 480 * 24 * 24 = ~177Mbit/s (plus misc overhead) USB isn’t so bad to get working on an FPGA dev board (I didn’t see you mention which you’re using) as it probably has a transceiver chip already along with drivers available. Even if not, you could add a cheap USB interface chip (FTDI makes some popular ones, but there’s many others like CP2102, etc). I’d not try to do more modern USB (3+) as it’s not needed, but also higher speeds bring more problems. I’d actually try lower quality video (lower res, framerate, and not 24bit color). As you increase the amount of data you need to transfer, you have more potential for issues related to buffering the video (and the extra memory required) or timing requirements (ensuring the video is arriving by the time it needs to, but not too much before).

If I’m understanding your main concern, it’s how to get the video data in to your hardware? Generally:

• camera module (that outputs uncompressed image/pixel data, idk how difficult these are to get running, drivers often abstract a lot of complexity)
• video stored on memory chip like an eeprom (may be impractical given size)
• storage device like SD, compact flash, or even an IDE hard drive (idk how difficult SATA is to work with). if you go this route, I recommend avoiding file systems.
• stream over USB2 from a laptop (whether it’s pre recorded file, built in camera, some USB camera or capture device kind of doesn’t matter from your hardware perspective)

Other communication interfaces (like ethernet) are probably going to be a lot more effort although I’ve seen a serial to ethernet interface that worked similarly to those UART <-> USB chips. idk cost or how easy they are to use though.

Especially considering when I looked yesterday, they didn’t have any kits, just individual parts and no right controllers. I guess it’s good to get the word out for people who already have a set and need replacements or want spares.

1. Why not both? Packaging multiple releases, documenting, and support is lessened with a single release. Officially supporting more ways to install is extra time and effort that is considerably worse with PHP than applications written in most (maybe all?) other popular languages due to the variety of ways people can configure PHP and how the web server executes it is huge and trying to support all of that is considerable. Even if you just narrow down to a single http server, there’s a lot of variations just how the http server executes the scripts and that’s ignoring the PHP/PHP extension level differences. I can’t think of any popular languages that are worse or even in the same ballpark as PHP on execution environment inconsistencies.

2. The existence of the docker release doesn’t prevent you from running it outside of docker and the Dockerfile/image serves as a reference implementation. It provides you the exact steps and working configuration to deploy it outside of docker.

Consider a PHP application with install instructions, you follow them and it doesn’t work due to some non obvious configuration difference. With the docker image you have a reference of what should work and can use that to narrow down what is different between your PHP install/configuration and a working system.

If you’ve not run in to these kinds of situations, consider yourself lucky. It was a nightmare back in early 7.x releases and older.

Years ago I’d have one PHP app that required version X of PHP and another that required version Y and my distro often only had one of them (or you couldn’t install both simultaneously), so I’d have to either compile myself (or later use a 3rd party repo). All solvable of course, but then throw in MySQL version requirements and PHP extensions and it’s just extra crap that containers just take care of for you. I’ve had this kind of inter app requirements conflicts with stuff other than PHP, but I’ve had by far more of it with PHP. For a while I used FreeBSD jails to help, but jails was kind of a pain. I enthusiastically embraced docker for PHP stuff early on.

A benefit for application developers, particularly PHP is there’s a lot of differences between distros and how people install and configure PHP. Even like which PHP extensions are available and their settings. Other languages things tend to be more consistent at the system level and customizations are app are usually application level (contrast with PHP extensions and system level configurations). It really helps reduce support issues due to distro/user differences if a developer just provides a working dockerfile as a reference implementation and in my experience this is far more likely with PHP than other languages. I realize this is mostly applicable outside of PHP, but I actually personally see more benefit with PHP based on my past experiences.