"The Thing": FPGA + STM32

An homemade FPGA board with an Arduino STM32, "Multicomp" compatible

Similar projects worth following
Two dev boards into one: a STM32 based Arduino ("Maple Mini" compatible) and a Cyclone II FPGA dev. board to start playing with VHDL/Verilog. It is also "Multicomp" compatible ("Multicomp" is a modular VHDL design to "run" some famous retro 8 bit CPUs made by Grant Searle) giving the option to "run" easily a VHDL SOC with a Z80/6809/6502 CPU and I/O, including HD (on SD) and a color VDU.


The Thing is the the "natural" evolution of the CPLD Fun Board. The idea was to make a  FPGA board using cheap and easy to find components, with a STM32 Arduino used as "stimulus generator" or "companion" processor for the FPGA, and with a 512KB SRAM and common I/O as GPIOs, VGA and a PS/2 keyboard to "run" HDL SOCs.

More, it has the option to "run" easily Multicomp VHDL SOCs having the needed HW.

Multicomp is a modular VHDL design to "run" some famous retro 8 bit CPUs made by Grant Searle and described here.

Here the details of the PCB. Please note that the PCB in the following image has an ENIG surface finish. This is not absolutely required. You can use a cheapest HASL surface finish:

The PCB leaves the choice to solder a "legacy" SD socket (as in the previous images) or a micro-SD socket as shown in the following images:

Here The Thing in action "running" a Multicomp Z80 with CP/M 2.2 as OS:


The STM32F103C8T6 MCU is used as "stimulus generator" or "companion" MCU for the FPGA, and is easily programmed using the friendly Arduino IDE through the USB connector.

Five push buttons (RST, BUT, USER1-USER3) and a led (PB1) are reserved to the MCU.

There is also a dedicated GPIO connector (GPIO1).

The STM32F103 MCU side is "Maple Mini" compatible, so it possible to use the STM32F103 Arduino core provided by (more info here). For a short story about the Maple Mini and the stm32duino see here.

You need to flash the bootloader first using a cheap "St-Link V2" dongle through the SWD connector (or using a serial-USB adapter on the SERIAL connector. More info here).


To configure the FPGA (EP2C5T144C8N) it is used the Quartus II IDE (the v13sp1 free edition is the last one supporting the Cyclone II FPGA) and a cheap "USB Blaster" dongle through the JTAG or AS connector.

To permanently store the FPGA configuration into the eeprom you can use the AS connector or also the JTAG connector with the SFL IP core as well explained in this Intel video.

... Read more »

application/pdf - 373.27 kB - 02/27/2019 at 09:51


A191117 - BOM.ods

BOM file.

spreadsheet - 17.39 kB - 02/27/2019 at 13:31


A191117 - Components Additional

Some components references.

x-zip-compressed - 2.14 MB - 02/27/2019 at 13:35


A191117 -

PCB Gerber files.

x-zip-compressed - 291.43 kB - 02/27/2019 at 08:46


A191117 - PCB Layout

PCB Layout Guide.

x-zip-compressed - 192.67 kB - 02/27/2019 at 13:36


  • The "MP/M experiment"

    Just4Fun07/19/2019 at 07:32 0 comments

    This is a crazy experiment that I've done using my own HW, just because I was curious to see a MP/M system running in a "real" situation with 4 concurrent terminal/users.

    The FPGA board runs a VHDL Z80 Multicomp with MP/M 2.1, HD on SD and 4 serial ports (I've ported it from the Retrobrew site adding the needed modifications):

    One FPGA serial port (Serial 1) is connected to the STM32 MCU inside the board, and the STM32 runs a "sketch" to act as a serial-USB bridge. So the USB connector is used to power the board and also to connect the Serial 1 port of the Multicomp (inside the FPGA) to a terminal emulator (on a PC):

    Here the setup I've used:

    and the video:

  • Dual-channel RS-232 adapter board is out!

    Just4Fun07/16/2019 at 11:54 0 comments

    The dual-channel RS232 board is out. All the details here.

    This board is intended as a RS-232 level adapter for Multicomp with multiple serial ports.

  • uTerm-S preview: a VT100-like terminal for multi-user OS

    Just4Fun04/24/2019 at 07:31 0 comments

    Wanting to test some multi-user MP/M configurations, I've decided to make a VT100-like "stand-alone" terminal starting from the uTerm, the VT100 terminal for the Z80-MBC2 board.

    I've decided to use THP parts (of course the STM32 is SMD only...) so it may be easier to build for others "retro" stuff too.

    Here a first preview of the uTerm-S. In this version the "transparent" serial-USB port can manage the RTS/CTS HW handshaking (the RTS/CTS signals must be present on the serial-USB adapter):

    Of course this is not enough. An other board must be done with at least a 4-ports (for 4 users/terminals) serial RS232 adapter for the "The Thing" board...

    ...or a couple of 2-channels RS232 adapters with both DB9 or screw connectors, and two specular TTL connectors (J1 and J2) so I can rotate the board by 180° and choose the most handy position:


    Now testing the "stand-alone" VT100 terminal with RS232...:

    ...with the RTC/CTS handshaking on the "transparent" serial-USB connector:

  • Multicomp preview...

    Just4Fun04/07/2019 at 19:06 0 comments

    Here is some previews of Multicomp VHDL I'm currently porting and testing. Here a Z80 system running MP/M 2.1 (a multi-user time-sharing OS for the Z80 CPU):

    ...and here a session using a simple sketch for the STM32 to use it as a serial-USB bridge attached to a VHDL serial port on the FPGA:

    In this way it is possible use The Thing with only the USB cable, connecting it to a terminal emulator on a PC:

    Here MP/M 2.1 with two concurrent users, one connected to the local VDU/Keyb and the other connected with a VHDL serial port "redirected" to the STM32 serial on USB (using the UART "bridge" sketch on the STM32 and managed by a terminal emulator on a PC):

    And here playing Gorilla:

    Stay tuned...

  • Multi-functional display/leds/keys custom controller. Project example

    Just4Fun03/06/2019 at 15:30 0 comments

    This is a ready to use example of a custom "multi-functional" controller for a 4 digits 7-segments led display (single segment "graphic" drive mode with digits multiplexing), plus 3 status leds, plus 3 push buttons, using a bidirectional data bus (DATA_0-7) and a register selection bus (SEL_0-2). The command signals are an active low write signal (WR_EN) and an active low read signal (RD_EN). The behavior is very similar to a SRAM device.

    To make things easier, in this example it is used the schematic editor and the 7400 devices family library, but note that this is not the best way to use a FPGA (the "right way" is to use VHDL/Verilog languages...).

    The schematic is the following (this is an Hi-Res image. You can also use the Quartus II schematic editor to view it, opening the project):

    The input clock for the multiplex comes from the 50MHz oscillator, and is divided by two 1:256 dividers (74393).

    The internal digit registers are 8 bits wide, because each single segment can be controlled, and there is a 3 bits register for the three leds LED1-3 (LED4 is a status led and isn't user "addressable").

    Only DATA_0-3 lines are really bidirectional, DATA_4-7 lines are not used in "read" mode and are tied to "1" using internal pull-up resistors.

    A logic "1" in the DATA bits means "led turned on" or "push button pressed".

    In the "read" mode there is no real register involved, so the SEL_0-2 lines are all "don't care".

    The complete Quartus II project ( can be downloaded from the repository.

    Unzip it taking its directory structure, and open it from the main Quartus II menu with "File" -> "Open Project..." selecting the file .qpf (is the extension for the Quartus II projects):

    Upload the configuration into the FPGA  using the JTAG connector, or with the AS connector to store it in the eeprom.

    WARNING: Because this is a bidirectional interface, take in account the considerations done in the "The DEV_OE switch and led" Log.

    The sketch for the MCU side (S030319_MultiFun.ino) can be downloaded from the repository.

    The result is shown in this short video:

    Note that the USR1-3 and BUT buttons are managed directly by the MCU (see the A191117 schematic). At the end of the video it is possible see the effect of the DEV_CLRn button (clears all the FFs inside the FPGA) and the DEV_OE switch (forces all the I/O pins of the FPGA in HiZ). The effect here is "visually" the same, but the inner behavior is different.

  • USB Blaster connection and disconnection procedure

    Just4Fun03/04/2019 at 17:45 0 comments

    Here are shown the connection and disconnection procedure for the USB Blaster programming device. The board in the videos is different but the procedures will apply to the JTAG and AS connectors of "The Thing" too.

    USB Blaster connection procedure

    After that you are ready to upload the configuration into the FPGA you must follow the suggested steps as described in the Usb Blaster User Guide:

    1.  Check that the target (the board) is not powered;
    2.  Connect the Usb-Blaster programmer first to the Workstation USB;
    3.  Connect the JTAG cable to the target;
    4.  Power the target. This means connect the board USB connector to an other USB port on the Workstation.

    Remember that the USB Blaster can't power the target. The power comes from the USB connector.

    Here a short video about how to connect the USB Blaster dongle:

    USB Blaster disconnection procedure

    Now, to disconnect the USB Blaster dongle you must follow the suggested steps as described in the Usb Blaster User Guide:

    1.  Power off the target. This means disconnect the board USB cable;
    2.  Disconnect the JTAG cable from the target;
    3.  Disconnect the Usb-Blaster programmer from the Workstation USB.

    Here a short video about how to disconnect the USB Blaster dongle:

  • The DEV_OE switch and led

    Just4Fun03/04/2019 at 17:34 0 comments

    As already said in the previous Logs, the DEV_OE switch forces all the FPGA I/O pins into a HiZ state. When the DEV_OE switch is in the HiZ position, the DEV_OE led is on.

    This switch comes handy in various way. A possible application is the case in which you want only use the STM32 "side" of "The Thing", and use the TEST1-2 connectors as GPIOs pins of the MCU as a "Maple Mini" clone. In this way you can simply "freeze" the FPGA holding the configuration inside.

    But there is a situation in which this switch comes very very handy. Imagine that you are testing a custom interface loaded into the FPGA, and simulating this interface in a "real" situation using the STM32 as "stimulus" generator. Imagine that you have some output pins (signals from the FPGAto the STM32) and some input pins (signals from the STM32 to the FPGA).

    Now what it can happen if you want change, for any reason, an input as output and an output as input in the same change?

    Well, if you update the FPGA configuration at first, the new configuration will change an input as output, so this can generate a short circuit between the FPGA and the STM32 because there would be two output connected together.

    So you can decide to upload the new sketch at first with the new "scenario", but in this new sketch a STM32 pin will be changed as an output, so you have two output connected together too!

    The only way to break this "deadlock" is to use the DEV_OE switch to force all the FPGA I/O pins to an HiZ state and then upload the new FPGA configuration and the new sketch for the STM32 with the input/output accordingly updated. Only when both FPGA and the STM32 are updated you can safely revert the FPGA from HiZ with the  DEV_OE switch again.

    Remember that the DEV_OE needs to be explicitly configured in Quartus II IDE (the DEV_OE LED will turn on also if not configured!), as explained in the Log: How to configure Quartus II. Step by step guide,

  • How to configure Quartus II: step by step guide

    Just4Fun03/04/2019 at 17:10 0 comments

    In the following I'll use Quartus II version 13.0SP1 (Service Pack 1) because it is last version supporting the  Cyclone II FPGA series.

    After installing Quartus II IDE (you can get it from here after a registration) it is necessary change some default setting on your Quartus II project to better suit "The Thing" (the default configuration is potentially dangerous for the board).

    This setting must be used for every new Quartus II project.

    From the Quartus II menu select "Assignments" -> "Devices..."

    click on the "Device and Pin Options..." button

    set the "Enable device-wide reset (DEV_CLRn)" and "Enable device-wide output enable (DEV_OE)" check boxes. In this way you enable the "DEV_CLRn" key and the "DEV_OE" switch in the "The Thing" board.

    These are two important functions: the first will reset all the FFs inside all the LEs (Logic Elements) with the "DEV_CLRn" key, and the second will enable the possibility to set all the FPGA pins to HiZ using the "DEV_OE" switch.

    Some important notes about these two function:

    • The DEV_CLRn key is active also when all the FPGA pins are in HiZ;
    • When all the FPGA pins are in HiZ by means of the DEV_OE switch, the "DEV_OE" led is ON;
    • If you doesn't enable the "Enable device-wide reset (DEV_CLRn)" check box, the DEV_CLRn key will not operate;
    • If you doesn't enable the "Enable device-wide output enable (DEV_OE)" check box, the DEV_OE switch will not operate, but the DEV_OE led will turn ON anyway. This because it is not possible from the outside to know if this function is enabled or not.

    Now you will set up the state of all the unused FPGA pins. "Unused" here means not referenced explicitly in the "programming" phase.

    From the above windows, on the left side, choose "Configuration":

    Check that the Active Serial mode is selected.

    From the above windows, on the left side, choose "Unused Pins":

    and in the "Reserve all unused pins" field set "As input tri-stated weak pull-up". This is the best (and safer) option for the "The Thing" board.

    From the above windows, on the left side, choose "Dual-Purpose Pins":

    and select "Use as regular I/O" for the nCEO pin.

    All done!

View all 8 project logs

Enjoy this project?



JudgeBeeb wrote 12/28/2019 at 15:52 point

Thanks for this. Very cool design. Successfully built this over the holiday week. Flashed the bootloader into the STM32 and got your MultiFun demo working. Now to see what else I can get it to do.

  Are you sure? yes | no

Just4Fun wrote 01/04/2020 at 13:13 point

Thanks! The repository on Github is far to be completed... I'm currently playing with others things...

  Are you sure? yes | no

Gobo wrote 07/13/2019 at 11:06 point

I did not find the description of the jumper settings SJ1, SJ2 and SJ3.
What are they used for?

  Are you sure? yes | no

Just4Fun wrote 07/16/2019 at 10:07 point

Ops... I forgot to mention them... Just added a paragraph in the Details section.

  Are you sure? yes | no

bobricius wrote 04/14/2019 at 17:08 point

I like Multicomp feature, if this will support Spectrum or C64 I build one ;)

  Are you sure? yes | no

Philip Walker wrote 03/07/2019 at 23:45 point

I'm very interested in this board but also in the process of building the "CPLD Fun Board".

(The Chinese PCB house seems to have made a good job with the Gerbers)

I am wondering if there is any critical reason to use the 0402 size capacitors as they are a ***** to mount - especially if you are no longer under 25 with perfect eyesight or a handy pick-and-place machine. (0402 caps also tend to have poorer dielectrics for the higher capacitances, I try to stick with X7R if at all possible)

I am considering having to try KiCAD (rather than my usual layout software) to modify the artwork if necessary otherwise I'll have to start from scratch/schematic.

Greatly appreciate the amount of detailed info on these boards.

Nice to have something with a good chance of working.

  Are you sure? yes | no

Just4Fun wrote 03/08/2019 at 10:41 point

Hi, I've decided to use 0402 because they are... small... :)

Using a 2-layer PCB this is very important.

To assemble the board I use an optical stereoscopic microscope by hand. With that it is easy, using solder paste and an hot hair soldering station (I mean... enough easy...). No pick-and-place machine is needed.

Here you can see the "making"...: (automatic English translation).

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates