A USB-C industrial camera where the sensor and the lens are both swappable

Two interchangeable parts, and the point of the design

The headline is the interchangeability. The camera is built around an interchangeable MIPI sensor and an interchangeable C-mount lens, with the electronics behind them.

That matters because the hardest constraint in a machine vision design is rarely the USB link. It is the sensor. A sensor has a fixed lane count, a fixed bit depth, a fixed frame rate and a fixed pixel format, and a camera that hard-wires those decisions has to be redesigned when the imaging requirement changes. Here the sensor sits on its own board behind a standard C-mount, so a different sensor module can be used with the same FPGA, camera and USB design, and the lens is standard too, which means the optics can be chosen for the working distance and the field of view without touching the electronics.

The other half of the design is the compute. A Lattice Crosslink-NX FPGA does the image signal processing, and a Cypress FX3 handles USB 3.0. Between them they turn a raw sensor stream into something a host can read.

The repository holds the three things a hardware project like this needs to publish: the FPGA firmware, the USB controller firmware and the hardware design files, split across FPGA_Firmware/, Cypress_FX3_USB_Firmware/ and Hardware/. The primary language listed for the repository is Verilog, which matches the FPGA being where the work is.

The author also points to a newer CHC5 Open Source Camera in the same organisation, and the tip sits at the very top of the README, so the newer design is the one to look at if you are starting today.

MIPI CSI-2 in, USB 3.0 out, with decoupled clocks

The data path is the standard industrial camera shape. A MIPI sensor sends a CSI-2 stream over up to four lanes into the FPGA, the FPGA runs the image signal processing pipeline, and the result is handed to the FX3 over a 32-bit GPIF interface and leaves the device over USB 3.0.

The architectural decision worth understanding is that the output pipeline is decoupled from the MIPI clock. The output side runs on its own output clock, which is what makes the frame rate of the USB link independent of how the sensor happens to be clocked. The README states this directly: the output clock is independent of the MIPI clock. In a camera that has to be driven by whatever sensor the customer fits, that decoupling is what makes a single FPGA design reusable across sensors with different timing.

The USB side has its own limits, and the project is honest about them. The FX3 32-bit GPIF can do a maximum of 160 MHz, and the FX3's own specification limits the maximum GPIF clock to 100 MHz. Those two numbers bound the achievable output rate regardless of how fast the FPGA fabric is, which is a useful thing to know before designing a camera around a particular resolution and frame rate.

On the input side, the MIPI bus clock is supported at 900 Mbits per second per lane with up to four lanes, giving a total sensor bit stream of 3.6 Gbits per second, and the project says this has been tested up to 900 Mbits per second with 8x gear.

Throughput, stated as the project states it

The performance figures in the README are the project's own, and they are specific enough to be checked against a datasheet.

The pixel processing pipeline can be configured for 2, 4 or 8 pixels per clock, and the project states that it can run above 110 MHz on a Lattice Crosslink-NX LIFCL-40 High Speed device, which it converts to a processing rate of up to 880 megapixels per second. From there it derives roughly 120 FPS at 4K resolution, around 30 FPS at 8K, and up to 3000 FPS at 640 by 480 as long as the camera and the MIPI wiring allow it, with the note that a faster FPGA would do more.

The ISP itself is described as having no virtual restriction on supported frame rate or resolution, with testing beyond 4K using an IMX477 at 4056 by 3040, and 8K at around 30 FPS or higher claimed provided the FPGA is fast enough for the needed frame rate and the board has enough memory to store the minimum four lines worth of pixels. That memory requirement is a real design constraint, not a footnote, because it is what forces the block RAM and DDR sizing in the hardware.

Read together, these numbers describe a camera aimed at machine vision and high speed inspection rather than at desk use, and they are worth quoting in a design review precisely because they are stated with their conditions rather than as a single headline figure.

Four parameters, and changing them means regenerating IP by hand

The FPGA design is parameterised, and the parameters are the interface between the sensor and the logic.

The maximum RAW pixel width is selectable, and the module auto detects the package type at runtime with RAW14 selected as the maximum, so RAW10, RAW12 and RAW14 are detected and processed without reconfiguring the FPGA. The number of MIPI lanes is configurable between 2 and 4. The pipeline size is configurable at 2, 4 or 8 pixels per clock, with a constraint that 2 pixels per clock is only available with 2 MIPI lanes and 8 pixels per clock only with 4 lanes. And the MIPI gear ratio is selectable between 16x and 8x, since most DDR and MIPI PHYs support 8x while few support 16x.

The cost of that flexibility is stated in one sentence that any integrator should read twice: the block RAM and DDR PHY IPs need to be manually regenerated if the gear, pixel width, lane count or pixels per clock is changed. The runtime auto detection removes the need to recompile for a new bit depth, but a change of lanes, gear ratio or pipeline width means re-running the vendor IP generation before the design will build.

Two further options are there for awkward sensors. The MIPI continuous clock mode lets you choose between low power clock based frame synchronisation and frame start and frame stop packet based synchronisation, for sensors that do not support going to low power mode during frame blanking. And a ROM based sample generator can be activated for ISP debugging, with two ROM lines holding even and odd lines to exercise the full image path.

The sensor test matrix is the most useful page in the README

The Tests section is a catalogue of what has actually been run, and it is the part an engineer will use most. It covers three sensor families.

For the IMX477 in 4 lane 12 bit configuration, the listed modes are 4056 by 3040 at 15 FPS full sensor, 2028 by 1520 at 60 FPS binned 2 by 2, and 2028 by 1080 at 100 FPS. The same sensor in 4 lane 10 bit reaches 1332 by 990 at 150 FPS binned 4 by 4, 640 by 480 at 400 FPS and 640 by 128 at 2400 FPS. The 2 lane 12 bit configuration gives 4056 by 3040 at 10 FPS, 2028 by 1520 at 35 FPS and 2028 by 1080 at 50 FPS, while 2 lane 10 bit gives 1332 by 990 at 100 FPS, 640 by 480 at 200 FPS and 640 by 128 at 1200 FPS.

The IMX219 is listed in 4 lane 10 bit, from 3280 by 2464 at 30 FPS down through 1280 by 720 at 240 FPS, 1920 by 1080 at 120 FPS, 640 by 480 at 400 FPS, 640 by 128 at 1300 FPS and 640 by 80 at 2000 FPS, with the 2 lane configuration running at roughly half those rates. The IMX290, IMX327 and IMX462 are covered in 12 bit, at 1280 by 720 and 1920 by 1080 with 120 FPS in 4 lanes and 60 FPS in 2 lanes.

Two things fall out of the table. The high frame rates are all achieved by binning, so they trade resolution for speed rather than being free. And the sensor itself sets the ceiling, which is why the swap-in sensor board is such a central idea.

Only the PHY is vendor specific

Portability is the claim the project makes about the design, and it is narrower than a greenfield rewrite but wider than a locked reference design. The README states that the code is easily portable to Xilinx or any other FPGA, and that no vendor specific components are used except the PHY itself, which can be replaced by another vendor's DDR PHY and embedded block RAM. Only the debayer and demosaic stage and the output reformatter need block RAM, and that block RAM can in turn be replaced by a vendor's RAM.

That is a specific and believable claim, because the MIPI receiver, the ISP and the USB interface are standards-based blocks with a narrow vendor surface: the physical layer and the memory interface. An engineer moving to a different FPGA family inherits the receiver and the pipeline and redoes the physical layer and the memory IP.

The other approach to the same problem is to skip the FPGA entirely and use a USB camera module that already presents a UVC device to the host, or a commodity board with a CSI camera. The difference is where the work goes. That route gives you a working camera in an afternoon and leaves the sensor and the ISP as fixed vendor decisions, while this design costs you a Verilog bring-up and a USB firmware bring-up and gives you a sensor interface, a programmable ISP and a product you can put your own name on.

Licence, repository shape and what a reader is not given

The licensing is stated in the README as Creative Commons Attribution 4.0 International, with a licence badge on the work and on the images. The repository's own licence field is listed as unknown, so for a hardware design with bill of materials, gerbers and firmware in the same tree, the practical step is to read the licence file and the individual subdirectories rather than assume a single grant covers the firmware as well as the documentation.

The repository is small in structure, with four top level entries: README.md, Hardware/, FPGA_Firmware/ and Cypress_FX3_USB_Firmware/. There is no board file for a simulator, no testbench harness for the ISP and no bring-up documentation for the USB firmware, and the README does not give installation or first-light instructions, so the repository is best read as a specification with source, not as a tutorial.

There are no GitHub releases, so the design has no versioned distribution, and the last push was on 2026-09-13. A project blog post linked from the README covers the open source USB-C industrial camera with the C-mount FPGA design, and the newer CHC5 camera in the same organisation is where ongoing work appears to have moved.

Editorial conclusion

This camera suits a hardware engineer who needs a MIPI sensor on a USB 3 link and wants the image signal processing pipeline in a FPGA they control and can port, or who wants the sensor test matrix in the README as a starting point for their own design. It does not suit a buyer who needs a working camera with a datasheet, a compliance report and a distributor to call. Verify first which sensor and lane configuration your application needs, because the README states that changing the gear ratio, pixel width, lane count or pixels per clock requires the block RAM and DDR PHY IP to be regenerated by hand, and check the licence terms for your product before shipping anything built on the design.

Frequently asked questions

Official sources

1. circuitvalley/USB_C_Industrial_Camera_FPGA_USB3 on GitHub
2. Issues
3. README