SUMP2 100 MSPS 32bit Logic Analyzer for icoBoard+RaspberryPi

2016.12.22 : After publishing SUMP2 96 MSPS Logic Analyzer for $22 iCEstick, BML was contacted by the icoBoard team in Austria inquiring the feasibility of running SUMP2 on their Lattice FPGA on the icoBoard and the RaspberryPi. BML was up for the challenge and has successfully ported the Windows + iceStick SUMP2 to work on Linux on Pi + icoBoard. This post describes how to configure the RaspberryPi and icoBoard to be a standalone 32 channel 100 MSPS logic analyzer.

File Download Area ( BML’s Dropbox ):

Note: See BML’s GitHub also https://github.com/blackmesalabs

What is needed:

  1. A Raspberry Pi Model3 ( or faster ), a USB mouse and a HDMI display.
  2. An icoBoard from icoboard.org.
  3. Free open-source software and firmware for SUMP2 from Black Mesa Labs.

Step-1 ) Download the 2GB custom Jessie-Lite image. Full details on this image ( and how to recreate from scratch if desired ) are available here. This image is a console only Linux that has Python modules pre-installed and a boot mechanism for installing files from a AppData.tgz file on a USB stick. Users may choose to manually install contents of AppData.tgz on their existing Linux Pi images, but no support for this is offered by BML.

Step-2) Burn the 2GB image to a uSD card using Win32DiskImager or similar tool. Warning – if you use a 2GB card, it might not work if it has fewer sectors than the 2GB card used in the generation of the image. Recommend using a 4GB uSD just to be safe.

Step-3 ) Boot the Pi with the new card.  It should boot up to a “Hello World” message.

Step-4) Download and Copy AppData.tgz and install_software.txt files from BML to a USB flash drive’s root directory.

Step-5) Boot the Pi with the USB flash drive. It should now install and launch the SUMP2 GUI.

Step-6) Configure the FPGA PROM by right-clicking in the waveform area of the screen ( not the signal name area ) and select System, Load_FPGA.  After this has completed, right click again and select System,Reboot. Remove the USB stick to prevent software from re-installing on the next boot.

Step-7) After the reboot the SUMP2 firmware and software should be fully functional.

sump2_0000.jpg

[ About the design ]

bml_sump2_on_ice_stick (1).png

SUMP2 is entirely open-source hardware ( Verilog RTL FPGA design ) and open-source software ( Python GUI ).   The open-source Hardware and Software design files for the icoBoard version are all available here.  Please read the original SUMP2 for iCEstick blog for more detailed information on SUMP2. The icoBoard version uses a Lattice iCE40HX8K which roughly has 8x the FPGA fabric resources as the iCE401K on the iCEstick. Instead of using asynchronous 1 MHz serial communication ( FTDI 921,600 baud over USB ), the icoBoard uses the Raspberry Pi’s built in SPI interface running at 32 MHz. Both versions of SUMP2 use Mesa Bus Protocol for transferring 32bit virtual PCI write and read cycles over serial interfaces. SUMP2.py for icoBoard communicates directly with the hardware, unlike SUMP2.py for used TCP sockets for communication to bd_server.py as a hardware/software abstraction layer. Setup for SUMP2 on icoBoard is much easier as the open-source nature of the Pi platform allows BML to design for a walled garden environment ( made completely of open-source mind you ). BML provides the OS and the Application and the user provides the hardware of which there is a single choice, icoBoard and a Pi Model 3. Only variable to test for is differing HDMI screen resolutions.

IMG_1924.JPG

[ PMOD Pinouts ]

Screenshot at 2016-12-25 18-11-03.png

The icoBoard has 4 0.100″ 2×6 PMOD connectors labeled P1-P4. Each connector is 1 of 4 byte inputs to SUMP2 for LVCMOS 3.3V signals.  P1 corresponds to events[7:0], P2 events[15:8], P3 events[23:16], P4 events[31:24].

[ SUMP2 on a small HDMI Display ]

File_005.jpeg

Large LCDs are fantastic, but if you want a small footprint dedicated logic analyzer to sit next to your bench scope, SUMP2 can do that too. With the exception of optional signal renaming, the SUMP2 software interface is entirely mouse driven, no bulky keyboard required to operate. No Linux login required. SUMP2 boots and runs like an oscilloscope – OS is completely in the background, hidden from the end user ( but absolutely still available to them for tinkering ). The final BML setup for SUMP2 on icoBoard uses a small 7″ 800×480 LCD and the Pi+icoBoard easily attaches in the rear with some doubled sided velcro tape. Although the standard Linux text console (shown above) is much too small to read at 800×480 on 7″, the SUMP2 menu option Misc,Font_Larger or Font_Smaller allows for changing font size on the fly to make for a compact and readable display (shown below).  Note that this setup uses the -bundle option in the sump2_wave.txt file to group multiple signals into a single “bus” that is then displayed as hexadecimal instead of a binary waveform. More details are available in the file sump2_manual-txt.

File_000 (1).jpeg

[ Executing from USB Flash Drive ]

stick.JPG

BML opted to execute the SUMP2 software from an external USB stick instead of the on board Pi uSD card. To accomplish this, simply copy the folder ~/AppData to /media/usb0 ( or do this from a PC ).  The advantage of running SUMP2 from USB is that transferring screen captures ( PNG, JPEGs ) and VCD exports from SUMP2 from the Pi to a PC much easier. If running SUMP2 with only a mouse ( no keyboard ), signal renaming is still possible by removing the USB stick with the Pi off and manually editing the ./AppData/sump2_wave.txt file using Vi or similar editor prior to booting the Pi. Configuration of the GUI is all clear text within sump2.ini and sump2_wave.txt files.

[ Flying lead adapter to PMOD ]
bml_sump2_pmod_wire_adapter.png

For just $1, this PCB may be ordered from OSH-Park that labels and adapts a PMOD connector to signal and ground pair 0.050″ pitch vias for making a flying lead adapter with dedicated signal ground returns for optimal signal integrity.

bml_sump2_pmod_100mil_wire_adapter.png

A slightly different version available here instead breaks out the PMOD to a 1×8 0.100″ row along with a single GND pin and 3V pin suitable for slow signals and dupont cables.

bml_pmod2pmod.png

This PMOD2PMOD board allows 2 PMODs Masters to plug into each other, for example 2 icoBoards can interact with 2 of these for 16 IOs between them. Useful for using SUMP2 on one icoBoard for debugging another FPGA design. 3V are not connected, only signals and grounds. Note that the signals are twisted 0->7, 1->6, etc and should be untwisted in the FPGA fabric.

 

[ Making PMOD inputs 5V Tolerant ]

5v_to_3v_pmod_adapter.png

The PMOD inputs of the icoBoard are 3V only and are NOT 5V tolerant. Since both the iCEstick and icoBoard use the same PMOD connectors, the 5V tolerant input adapter designed by BML for the original SUMP2 on iCEstick may also be used on the icoBoard. The bare PCBs may be ordered at this link direct from OSH-Park for $5.  With the bare PCB, a simple 2×6 0.100″ right angle male header and a DIP SN74LVC244AN may then be soldered to provide a 3V input to icoBoard that is also 5V tolerant.  Total cost of parts and PCBs for 3 PMOD connectors total is only about $10. WARNING: Care must be taken not to configure the FPGA GPIO features as outputs to prevent damaging the FPGA. By default, the FPGA powers up with PMOD pins configured as inputs, allowing safe operation with this adapter.

[ GPIO Feature ]

servo-samples.jpg

But wait, there is more.  The Lattice iCE40HX8K FPGA on the icoBoard has 8x the resources of the iCEstick, so along with the SUMP2 logic analyzer engine, the FPGA design also includes 8 PWM ( pulse width modulators ) and GPIO ( General Purpose Input Output ) capabilities for all 32 PMOD signals.  Completely unrelated to SUMP2, this feature bundled in the same FPGA bitstream may be used as a general purpose port expander for the Raspberry Pi.  With time-multiplexing, the design actually supports controlling 32 RC servos ( only 8 in motion at once ).  By default, the GPIO portion of the FPGA design powers up with a 32 PMOD signals as inputs, allowing SUMP2 to operate on external signals without programming the GPIO registers. Refer to the ./source/reg_space.txt file for detailed register descriptions on programming the GPIO module. The example file ico_gpio.py included in AppData.tgz demonstrates how Python and Mesa Bus Protocol can be used for configuring the GPIO features. Conversely, the SUMP2 FPGA bitstream may be used without ever using SUMP2 if a Pi user simply wants to add more IO capabilities to their Pi.  Look for future GPIO FPGA only design from BML for the iCEstick that may be used for bit-banging any 3V device from a PC using Python ( including writing and reading SPI and I^2 PROMs ). $22 makes for a very nice platform for controlling devices and monitoring switches from any PC with a USB port.

[ Built in Self Test (BIST) Feature ]

The GPIO feature of the FPGA design and the included ico_gpio.py software may be used to drive test stimulus to all 32 PMOD pins.  This feature is useful for testing that all the SUMP2 software and hardware is operational. The electronic stimulus is provided by the SPI interface between the FPGA and Pi and the 8 PWM units.  WARNING : Enabling this feature drives the test data as FPGA outputs to the PMOD connectors, so it is important that nothing be connected to them ( including the 5V to 3V translation boards ). Running ico_gpio.py which enables all the output buffers of the FPGA may damage the FPGA if other devices are also driving the PMOD pins. Only run ico_gpio.py if you are certain nothing is electrically connected to the PMOD pins.

Step-1 ) From SUMP2 GUI, select System, Quit.

Step-2 ) From Linux command line, type %python ico_gpio.py   ( Configs GPIO outputs )

Step-3 ) From Linux command line, type %source start_app.sh   ( relaunches GUI )

[ Demo at 33C3 ]

Clifford of icoBoard.org demonstrated SUMP2 running at the 2016 Chaos Communication Congress (33C3) festival in Hamburg Germany.

 

[ In Closing ]

Please enjoy SUMP2, a 32 channel 100 MSPS open-source logic analyzer for icoBoard and RaspberryPi.  Follow BML on Twitter for updates on SUMP2 and other open-source software and hardware projects from Black Mesa Labs.

EOF

SUMP2 100 MSPS 32bit Logic Analyzer for icoBoard+RaspberryPi

25 thoughts on “SUMP2 100 MSPS 32bit Logic Analyzer for icoBoard+RaspberryPi

  1. VS says:

    Impressive work! Looks like quite an upgrade over my DP Logic Sniffer, especially because I’ve never been able to get Logic Sniffer’s RLE compression to actually work. As I understand, the python software doesn’t currently decode the I2C protocol?

    Like

    1. Thanx. Correct, SUMP2 doesn’t include any protocol decoders. I think it would make more sense for the Sigrok project to talk to the SUMP2 hardware instead of trying to add Sigrok protocol decoders to SUMP2 software. I’m also a huge fan of Saleae and use their Logic for UART and SPI decoding that I need ( so I don’t have much of an incentive ).

      Like

  2. Hi Kevin, Liking this LA a lot! I’ve just folded the logic into Orbuculum on a HX8 as part of the open source toolchain for SWD+SWO for Arm CORTEX-M (See https://github.com/mubes/orbuculum) but I’m having a few stability issues with the Python side in particular. I’m not sure I’ve got the latest versions of everything since there seem to be a few in different places….can you please point me to the right place to get the latest and greatest of everything? I’m seeing errors like “Assertion ‘q->front’ failed at pulsecore/queue.c:81, function pa_queue_push(). Aborting.” at the moment. The ice40 logic seems quite stable though, so I think it’s just the python side that’s giving me issues.

    Regards

    DAVE

    Like

    1. thx Dave! Google on github sump2 to find the latest sump2.py file. Different versions of both Python and PyGame make complete compatibility difficult. Please let me know what you find. -Kevin

      Like

      1. Hi Kevin,
        Yup, thats the one I’m using…but getting the frontend error as above. I’ve only tried with current python 3.6.3 though – do you have a version you recommend or that you use? That version is set for full-screen under Linux though so I had to change a few platform tests to make it run in a window….if this is the latest then I’ll start investigating the issues….will keep you posted.
        DAVE

        Like

      2. I run it on Python 3.5 under Windows 7/10 for certain. I’m not sure about running on RaspPi, but I think it may be older like 3.3. Feel free to contact me via my email on my blog home page with more detailed info, or DM me on twitter @bml_khubbard

        Like

  3. The Yoshter says:

    Is there an easy way to use more of the FPGA’s pins? For example, I would like to analyze 48 signals… I know this FPGA has 200 or so pins… I say easy b/c I would like to use this device for a project – but I don’t have a lot of time to edit verilog or traverse source files.

    Like

    1. Yes totally, the sump2.v hardware and sump2.py software supports up to 32 events ( RLE compressed signals that can be used as triggers ) and up to 16 DWORDs ( 512 non-compressed signals ).

      Like

      1. The Yoshter says:

        Is there anything I should modify? I have experience with VHDL not much verilog. I would like to use 40 pins on the Lattice ICE40HX8K. What should I change in sump2.v – and what assignments might I need to update in the IceCube planner. Does the sump2.py need to be modified? I do have some experience with python.

        Like

      2. The Yoshter says:

        I see
        input wire [31:0] events_din,
        and
        input wire [127:0] dwords_3_0,
        input wire [127:0] dwords_7_4,
        input wire [127:0] dwords_11_8,
        input wire [127:0] dwords_15_12,
        inside sump2.v. I imagine I just need to place these signals appropriately in the pin planner?

        Like

  4. sump2.v shouldn’t require any changes. When you instantiate it, you can specify the number of event bytes to use ( up to 4 bytes for 32 event signals ) and how many data DWORDs ( which aren’t compressed ). Assuming you aren’t using DWORDs ( which are typically used only for internal FPGA node captures ), all you need to do is assign the events_din[31:0] to appropriate pins on your FPGA. You’ll need a clock too of course.

    Like

    1. The Yoshter says:

      OK. Thanks for the prompt response. I think I understand what I must do now. And from my understanding, the sump2 protocol inherently handles informs python of the amount of signals present.

      Like

    2. Bracket Master says:

      This is the Yoshter again. I’ve been away for some time and never got around to playing sump2. What do you mean by instantiate? Should I change the parameters in module sump2. When opening up the icecube project for the hx1k, I see
      parameter depth_len = 1024,
      parameter depth_bits = 10,
      parameter event_bytes = 4,
      parameter data_dwords = 16,.
      I also only get to assign 37 pins in pin planner, 8 of which are d[0] – d[7]. What if I want to get 16 or 32 different lines? Also, what is a dword(a double word) – if so what is the word size? Why is dwords set to 16, but i only see d[1] through d[7]? I think i understand where to assign the ftdi pins on the hx8k board, but what are wires like p116 and p56 for? I downloaded the icestick schematics to try to sleuth it out, but I’m still a little lost. Please help me out here – I’m fairly new to the FPGA scene – I’m only 19.

      Like

      1. Bracket Master says:

        Perhaps this is an easier question to answer and really gets at the answer I need. How do I modify sump2 so that I can use 40 pins on the HX8k as LA signals? I’ve had experience with the Hx8k before and written some logic that displays video on an old CRT screen – so I’m quite comfortable with pin assignment – just not sure what to change in SUMP2.

        Like

    1. Hey no problem. Reading RTL ( Verilog / VHDL ) can be difficult. Often times is is just structural – meaning if it was drawn in a schematic it would be more clear. Regarding signal hookup:
      input wire [31:0] events_din,
      input wire [127:0] dwords_3_0,
      input wire [127:0] dwords_7_4,
      input wire [127:0] dwords_11_8,
      input wire [127:0] dwords_15_12

      events_din[31:0] can be 8,16,24 or 32 signals you want to capture/trigger from that sump2 will store using RLE compression.

      The dwords come in groups of 4, so 0bits, 128bits, 256bits, 384bits or 512bits which sump2 will store centered around your trigger point. They are not compressed. What this means is depending on what you are capturing and how many RAM blocks you use, you might get 100uS of events stored and only 1uS of dwords. This is normal. Good luck with your project!

      Like

  5. Bracket Master says:

    Thanks, I’ve made a good deal of progress and sump2.py partially works now. I shot you an email with some particular questions though.

    Like

    1. Bracket Master says:

      I’m able to see 16 events in pygame although I’m pretty sure the events_loc wire in top.v is 24 bits deep. Also, I am unable to use acquire. I sent an email to your spam proof address I found on your welcome page.

      Like

  6. Wise says:

    Hello. Im using the free IO pins to transmit data from the icestick. (112-119) Are sump2.v and top.v the only files needed for sump2 to function? I intend to stream to data continuously instead of trigger events. What reg should I be looking at for the data streaming? (Could save me a few hours) Thank you very much.

    Like

    1. Sorry, I don’t fully understand your question. All the Verilog files are required. The other files are the FTDI UART to Local Bus interface which allow the computer to communicate with the SUMP2 engine. Regarding “data streaming” – SUMP2 doesn’t work that way. It stores samples in real time to the FPGA memory. After a triggered acquisition is complete, the PC then slowly downloads samples over the 1 Mbps FTDI UART interface. If you want a streaming device, buy a Saleae Logic Analyzer. They’ll stream to PC DRAM in real time.

      Like

  7. George Weatherford says:

    I just tried installing the software on my rpi with bad results. Downloaded the jessie image and installed it on a sd card.(32GB) and it booted with the “Hello world” and then downloaded the appdata.tgz and the install_software.txt (which only has a ) into a flash drive and rebooted the rpi and it booted to the “hello world” prompt again. is there something missing in the install_software.txt file? Is there another source for this file?

    Like

    1. If both appdata.tgz and install_software.txt ( which is just a flag, contents are ignored ) are on the USB Flash drive, on bootup it should install appdata.tgz and on the next boot the application should run.

      Like

Leave a comment