SUMP2 – 96 MSPS Logic Analyzer for $22




2016.22.22 : SUMP2 now also available for RaspPi+icoBoard here.

2016.12.13 : Great video on SUMP2 from Bil Herd at Hackaday.

2016.10.31: Thanx to SteveDC, a 3D printed case is now available for SUMP2 here.

2016.10.30 : SUMP2 5V Input shield is now available from OSH-Park for $5. BML can also design similar shields for RS232,RS422/485,LVDS and CAN Bus if there is any interest.

2016.10.24 : Black Mesa Labs has an ongoing mission to develop easy to use and fully capable open-source hardware and software tools that make engineering electronics easier. One such tool is this new low cost open-source logic analyzer called SUMP2 for people who otherwise work in the blind without an oscilloscope or logic analyzer on their bench top.  BML’s 1st incarnation called SUMP1-RLE in 2014 was a 16bit FPGA based logic analyzer that performed real-time hardware compression and decompression. The decompressed data was streamed out over USB using the open SUMP protocol ( hence the name ), allowing it to be used with the excellent Java software from the original 2007 project. The SUMP1-RLE project was later enhanced from just 16 triggerable events to also include 2 DWORDs of “data” ( additional 64bits of non-triggering non-compressed signals ) and advanced triggering options. Including the data DWORDs made SUMP1 a useful tool for complex FPGA development debugging of internal FPGA event nodes and data paths. These new features required new custom software, written by BML in .NET for Windows. The software was functional, but graphically slow and was mostly used for trigger setup and then exporting captured data as VCD files into GTKwave for viewing. SUMP1 also did not scale in width, depth or time, it was fixed at 16 events, 2 DWORDs and a 2^20 timestamp ( 1 Million Samples ) both in hardware and software. In 2016 BML decided to do a complete start-over on the SUMP RLE concept and developed SUMP2-RLE ( or just SUMP2 for short ). New Hardware, New Software. More features, better scaling – introducing SUMP2:


The sump2.v verilog file is designed to work inside any FPGA or ASIC containing block RAM and scales in complexity from 1-4 bytes of events ( 8-32 triggerable and RLE compressible signals ) and 0-16 DWORDs of up to 512 non-compressed data bits. Depth and width of RAM scales on instantiation to best fit a wide range of FPGA technology. The full featured SUMP2 configuration is designed to be used on internal nodes within very large $100 – $1000 FPGAs. In this configuration for analyzing internal FPGA nodes it is very similar to proprietary FPGA vendor solutions such as Xilinx ChipScope and Altera SignalTap. SUMP2 has the advantage of being fully open and also offers RLE compression that can offer 10x – 1000x the time storage of similar FPGA logic analyzers not aided by hardware compression. Duty cycle hardware applications such a pulse-echo radar can readily achieve 5,000x compression using the new RLE engine with 2^32 timestamps. The scalability of SUMP2 also permits it to work in ultra low cost ( sub $5 ) FPGAs such as the Lattice iCE family. The Lattice iCEstick eval board at only $22 with included FTDI USB interface and PROM programming provides for a perfect SUMP2 platform for electronic debugging of Arduino and Raspberry Pi like projects involving 3V serial ports and GPIO. Communication between hardware and software over USB is all done using the Mesa Bus Protocol , an open serial protocol for transferring 32bit PCI reads and writes over UART, SPI and SERDES serial links between computers and FPGAs.




To fit within the iCE40HX1K FPGA, sump2.v verilog RTL design is instantiated for 16 input events, no DWORDs and 1k depth of RLE capture RAM sampling at 96 MHz. The graphical backend software is, a PyGame application used for arming the hardware and dumping and displaying the capture for analysis. Compared to the SUMP1 .NET app, the PyGame SUMP2 version is very fast. Although supports exporting and importing VCD files, it is entirely not necessary to use a standalone VCD viewer such as GTKwave or Modelsim.

A simple example of a Unit Under Test.  Below pictured is a 10 MHz ( 100ns period ) oscillator driving a 74ACT161 4bit counter with a 74HC08 AND gate on the d(2) and d(3) upper bits of the counter. A push button switch to ground with a 10K pullup resets the counter. 8 nodes of interest are connected via Dupont ribbon cable to the iCEstick PMOD header.


Short demonstration video of the PyGame application:

The initial full capture of the reset button being released. The capture represents 4168 samples at 96 MHz using only 1K of RAM by utilizing RLE compression. RAM is hard partitioned 50/50 pre and post trigger.sump2_0003.png

SUMP2 has the ability of masking input events prior to arming which allows for greater RLE time compression. By double-clicking and “Hiding” the clk_10m signal prior to a new acquisition, the highly active clock signal is masked. This next capture without the 10 MHz clock is twice the length, or 83uS.  Also notice the very short reset switch bounce captured. Masking the LSB counter bits would further increase total capture time.


Mouse scroll wheel can be used for zooming in and out in time, allowing for rapid detailed analysis and cursor measurements.


Right-Clicking the mouse launches popup menus for tool selection.


The left side popup allows for selecting a signal and then assigning it as a rising or falling edge trigger.


Steps for building your own open-source SUMP2 Logic Analyzer for the Lattice iCEstick.

What is needed:

  1. $22 iCEstick from Mouser, Digikey or direct from Lattice. ( ICE40HX1K-STICK-EVN )
  2. Free FPGA Diamond Programmer software from Lattice.
  3. Windows Device Driver for the FT2232H USB chip from FTDI ( this may also be included with Lattice Programmer ).

and this free stuff from Black Mesa Labs:

  1. Bitfile for SUMP2 for the Lattice iCE40HX1K FPGA.
  2. – a Python TCP server for communicating to hardware over USB.
  3. – a Python PyGame application. Handles triggers and waveform viewing.
  4. FPGA Design Files ( Optional, only needed if not using prebuilt Bitfile ).
  5. 5V Input shield PCB design in CopperConnection ( Optional ).

And finally, a bunch of text file documentation from Black Mesa Labs:

  1. Installation Instructions
  2. FAQ
  3. Program Launching instructions
  4. Troubleshooting guide
  5. Pinout for connecting flying leads to iCEstick
  6. Change Log for Software and Hardware
  7. Bug Report

EE Times Article by Clive “Max” Maxfield on SUMP2

Hackaday Article by Jenny List

Please enjoy SUMP2, a 96 MSPS 16bit 3V logic analyzer for only $22. Follow BML on Twitter for updates on SUMP2 and other open-source software and hardware projects from Black Mesa Labs.


Nice article ( in Russian ) and SUMP2

SUMP2 – 96 MSPS Logic Analyzer for $22

37 thoughts on “SUMP2 – 96 MSPS Logic Analyzer for $22

  1. I do not understand if you use icestorm tools. But if you do, would be a good platform for your project. I would even send you a board for free because Clifford Wolf would love to see complex trigger condition programmed on the fly in the bitstream.

    it seems as you use windows only so my guess is that you do not use
    We even do have a FTDI board to connect the icoBoard to your laptop if you do not like to work with RaspberryPi.


    1. Hi Eduardo. I attempted to contact you directly via email. I do not use icestorm. I am open to including icestorm project file and generated bitfile on my site, but I would ask that someone familiar with it download my Lattice project and recreate in the icestorm environment as a starting point.


    1. Yes. That should work. A cheaper solution for some might also to just build a resistor divider network. Couple of 100-ohm resistors to divide 5V Voh to 2.5V Vih would work well for most applications.


    2. I just uploaded Gerbers for a SUMP2 5V input shield to OSH-Park where it can be purchased for $5 ( for Qty-3 PCBs includes shipping ). It uses a SN74LVC244AN DIP-20 that can be purchased for $0.60 from Digikey ( a person could order one along with the iCEstick ). If there is any interest for 16bit version, I could probably design and assemble and ship a surface mount version for $10-$15 within the US. If enough users express an interest, I will look into it.
      This 8bit version is designed for users with average soldering skills to assemble themselves.

      The purchase link is


  2. SteveDC says:

    Kevin, I get the traces to display but whenever I right click and select an item that should have sub-options I just get a message in the command window such as “I think you know what the problem is just as well as I do.” and various other ‘funny’ messages. If I select an item that doesn’t have a sub-menu then sump crashes with errors similar to this…

    Traceback (most recent call last):
    File “”, line 6091, in
    main = main();
    File “”, line 521, in __init__
    proc_cmd( self, words[0],words[1:] );
    File “”, line 2321, in proc_cmd
    val1 =;
    AttributeError: ‘NoneType’ object has no attribute ‘name’

    Any thoughts?



    1. It might be you didn’t left-click to select a signal name 1st. When you right-click in the left signal name field, it is expecting 1 or more signals to be selected ( brackets should show up around the signal name ). I may have failed to check for nothing being selected.


  3. SteveDC says:

    Thanks for the quick response 🙂

    I will experiment more and let you know how I get on.

    On a side note, is it possible to run without any trigger? I can select rising or falling now (possibly wasn’t selecting the signal previously as you mention, but it remembers settings so can’t undo it).

    No trigger would be useful to check the static states of signals.

    When I right click on the trace area and select “acquire” shouldn’t I see options to start an acquisition ?



    1. No ability to view live signals ( common issue, Saleae has same limitation ). Acquire has a sub-menu beneath it. Try moving mouse to the right of “Acquire” – it Should then say “Acquire_RLE” and “Acquire_Stop” I believe. PyGame doesn’t come with any window widgets, so I had to make my own, sorry about the learning curve on the quirky ness.
      Are you talking to hardware?


  4. SteveDC says:

    Love your support. Thanks 🙂

    We use Saleae all the time at work and I am fairly sure there is a way to immediately trigger,It might be when in analog mode though, can’t recall exactly at the moment though.

    OK, got the menu working. I was expecting to click on the items but as you say, simply moving to the extreme right does in fact work correctly 🙂 User error 🙂 Even managed to view the manual !!! 🙂

    Regarding immediate mode I will play with the RTL since I would expect it should be fairly simple to ‘fake’ a trigger when the ‘go’ command is received, which cold then be used if no other trigger is defined.

    I believe I am talking to the hardware since the server seems happy and a link to the server is established.

    On a side note, why didn’t you integrate the COM port reading code directly into SUMP2 so that a single application could be run, rather than starting 2 different processes? I know I am going to forget to start the server many times 🙂

    Thanks for sharing your work though. It is VERY much appreciated.



    1. Steve – EXCELLENT! It sounds like you have everything up and running already. The SUMP2 setup steps are non-trivial, so you are already an advanced user on a short list of engineers. If you need test stimulus, I direct a bunch of signals out the unused 10 row “header”. I usually just bridge a thru-hold resistor from one side to another. Regarding the need of, yes- I totally understand what you are saying. I have my reasons for this, and there are some benefits ( and draw backs ) as you mentioned. At work I am strictly a Hardware Engineer (ASICs and FPGAs ). At home, I like to design small FPGA boards, IP and also software to talk to them. I’ve written multiple “” like applications over the years for talking to hardware for various application. Having a TCP “server” like allows me to separate the low-level hardware protocol from the high-level ( I just want to talk to registers ) application. It also allows me to write in different languages and on different platforms ( Linux to Windows, etc ) as TCP sockets is so portable. It ALSO allows me to have somebody across the country / world ( Intranet ) run on remote hardware, which I can then run talkig to the hardware from my cozy cube in Washington State ( I don’t like to travel for many resource, fossil fuels, CO2, bad hotels, all the wasted time “working” in airports). Anyways, actually supports 4 different low-level hardware protocols, the version you see are the ones that are open-source. There are some import calls for talking to other devices drivers that are not for the world to see and I use my tools myself places other than at home. It makes for a great “security” firewall layer for me to separate my 100% open-source software from software that needs to include some closed-source elements for professional reasons. All this said, I may decide to change this if gains in popularity. Or maybe have spawn the process. I don’t fully trust Windows with this, but I can look into it. I have another application “bd_shell.exe” written in .NET, that actually supports 2 protocols ( Poke,MesaBus) over 3 different low-level connections ( TCP to BD_Server, COMn UART, FTD2XX.DLL ). It gets very complicated, but it works. One other advantage is running, it allows multiple clients to talk to the hardware at once ( well, round-robin ). For example, running sump.p2 logic analyzer side by side with bd_shell.exe for manual register access. I would hate to give that feature up.
      Thank you for the feedback! Great to hear about tech heads like myself using it around the world! -Kevin


      1. One more comment. I have another project (back burner currently ) that is interfacing the FTDI FT600 USB 3.0 to FIFO bridge chip to one of my Spartan6 FPGA breakout boards. Goal is to provide a Windows/Linux to FPGA interface over USB that is at least 100x faster than what I use today ( 1Mbp USB FTDI VCP ). Talking to this chip requires their D3XX DLL. I already have a Powershell .NET version of bd_server that talks to their D2XX DLL, so this is my path to getting a Python application talking to a FTDI DLL, using TCP as the go between Python and .NET.


  5. [ Launching and then with a single click. ]
    I created this batch file that seems to work on my Windows 7 setup. This will launch and then launch with a single mouse double-click. What is EXTREMELY annoying is that Windows doesn’t return the same COM port search string, so the bd_server.ini line “usb_port = AUTO” no longer works. It doesn’t find the FTDI COM port. For now, substitute “AUTO” with “COM99” ( where 99 is your assigned COM number ) and I think this is a decent solution for launching both tools together. Attempts to spawn in Python was a disaster in Windows ( as expected ).

    [ sump2_launcher.bat ]


  6. SteveDC says:

    Thanks for the feedback. I fully understand the flexibilty the server gives you. Nice approach.

    For USB hardware I type to use the TI Tiva 123 since it has built in USB1.1 support and I have code which enumerates as a virtual com port. It is modified from the TI examples and as such allows me to receive data to the Tiva at pretty close to 12Mbps. In cases where the Tiva is also the end point for the data it is great. I also have applications where I de-serialize and push out as clocked parallel, again with pretty high data rates.

    The thing I like about this is that the baud rate of the virtual com port is unused and data is transferred as fast as Tiva can handle it, which is close to the full 12Mbps. It also enumerates just as a standard VCP so no need to mess with FTDI driver configuration (i.e. force set as a com port etc… every so often)

    I am also a hardware engineer and work very heavily with FPGA systems. Love ’em 🙂 I also do a lot of work with embedded micros and analog hardware too, but not much on the higher level software side of things.

    Thanks for the tips on the test outputs. Very useful.


  7. SteveDC says:

    Good old Windows…
    If I try to launch the server/front end scripts directly by double clicking on the .py files then the front end complains that PyGame isn’t installed. If I open a command window first, then use “python” all is good.

    Upshot is that I needed to modify the batch file to the following…

    start python
    start python

    Hopefully will help others 🙂

    Liked by 1 person

    1. Frederick Burton says:

      I think maybe you have either : multiple pythons installed (one with pygame, one without), and the one associated with the .py extension differs from the one first in your path .. or possibly some environment variable is overriding your python path.


  8. Very neat project! Finally have a justification to pick up an icestick 🙂 Have you looked at sigrok at all? At the very least you could take advantage of PulseView that works with a bunch of other devices.


    1. I have not used Sigrok at all, but I am definitely open to working with the Sigrok software community if they have any interest in supporting the SUMP2 hardware design on the iCEstick.


  9. Sieg says:

    Hi, amazing project,
    You just made me order an icestick within 10 minutes reading your blog.
    about the 5V input shield, you said that you could also help to support CAN bus or LVDS, i would be really interested in those 2 for my project (opening my car’s display while keeping original controls)
    Thanks !


    1. Probably based on your assessment. Since you are an FPGA beginner though, I’d recommend sticking with the $22 IceStick. Regarding 80 MHz SPI bus, you would want an FPGA capable of 160 MSPS at least


  10. Sig Mund says:

    How hard would it be to direct the data to an external phy chip and from there to a rj45 connector. Can you point me to the right direction on which design file should I start poking at? Thank you.


    1. The data is downloaded from a standard UART serial link. The link is converted into a virtual PCIe “Local Bus” inside the chip by all the Mesa Bus verilog files. The sump2.v design is independent of the Mesa Bus serial link and could be hooked to any other bus interface that is capable of single cycle 32bit reads and writes.


      1. Sig Mund says:

        Sorry to be a bother. This is my first touch with fpga. So I should just ditch all the mesa* files in the project and work my way there. (Leaving top.v, core.v, sump2.v,spi_byte2.v,spi_prom.v, top_pll.v) Which one of these files specifically should I be looking at to start building the phy communication. This is a pretty big pill to swallow with no prior knowledge of verilog. Thank you.


      2. Bil Herd says:

        Hi Sig Mund,
        This is fairly advanced code in my opinion, and doubly so if you don’t have a a high level of comfort and familiarity with Verilog (and/or VHDL as Black Mesa’s style is to include a lot of extra definitions as if writing for VHDL which is not a bad thing).

        My advice is usually to get hold of a development board and compile code a few hundred times as the experience can be the real takeaway from the exercise. In other words, compile as many interesting examples as you can find until you can write bigger and bigger things yourself. If starting with this design I would recommend making small changes to get comfortable with structure and make sure that you are also comfortable wit simulation of the design. Maybe adding or subtracting a channel would prove to be good experience as you would have to tough a lot of teh structures and see how they inteact.

        The ICEstick used is a cheap development board and powerful in the hands of master coders like Black Mesa, but doesn’t include the memory or gig-ethernet (if that is what you meant by RJ45) that you mentioned, you would have to re-target a different device to add external memory due to pin limitations (the pins are all used or close to it) or reduce the number of inputs to free up pins, and then find a development board that has the desired architecture for what you want to do (laying out you own PCB is a different conversation). Just for the heck of it I took the code and re-targeted an Altera device and had a couple of days in it just redoing the clocking and PLL structures and other support functions even before I got to the core functions.


        Liked by 1 person

  11. Sig Mund, Bil gave some great advice which I agree with completely. Start with your own small FPGA design. Build your custom bus interface for it, write and read some simple custom FPGA registers – and then build up from there. -Kevin


  12. AjG says:

    Hello Kevin,
    I have built your ICESTICK Verilog and have it running on an Olimex Ice40hx8k-EVB which has a 256Kx16 SRAM on board. I did a diff between the sump2.v in the Olimex folder and (newer) sump2.v in your file set that includes the deepsump folder and noted the additions for deepsump.
    I would like to use the ram on Olimex board. Which file set should I start with.



    1. There were some minor additions to sump2.v to support deep_sump.v. The newer sump2.v ( October 25,2018 ) is fully backwards compatible with the existing GUI software. I’d start with the deepsump fileset.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s