BML S7-Mini FPGA Module


2019.05.19 : This blog posting is about the open source S7 Mini FPGA module designed by Black Mesa Labs and professionally manufactured and distributed by Trenz Electronics.  In short, it is a Xilinx Spartan7 7S25 on a 1″x2″ module with 64 Mbits of DRAM, Config PROM, 5V single supply solution and provides either 32 user I/Os on a 0.100″ (2.54mm) DIP grid or 64 user I/Os on a 0.050″ (1.27mm) grid at LVCMOS33 levels. This posting isn’t complete, but a work in progress and central point for links to example GitHub designs, purchasing links, schematics, etc.

S7-Mini Purchase Options :

  1. Direct from Trenz – warning – DHL shipping to US can be pricey ( $50 ).
  2. From Trenz partner Mirifica who will ship via low cost standard post.
  3. TBD Digikey in the future.

What else to buy:

  1. Digilent HS2 JTAG Programmer. $60 from Digikey here.
  2. FTDI 3V USB cable TTL-232R-3V3. $20 from Digikey here.

Schematics :

  1. Direct from Trenz website.
  2. Copy from Black Mesa Labs GitHub here.

I’m just getting started on this blog. It will detail multiple sample designs for the S7-Mini on my S7 Mini GitHub here. Simple Hello World” blinky light and finally the DeepSump 32/64 channel 200 MSPS logic analyzer which captures to 64 Mbits of DRAM.  I’m doing this 100% on my free time, so it might take be a bit to finish this blog posting, but it is my #1 Black Mesa Labs project.

[ History of the S7-Mini ]


The S7 Mini began in Spring of 2018 as a proof of concept Black Mesa Labs project on being able to design and assemble a 1mm pitch BGA using only a 4-layer PCB from OSH Park. Xilinx manufactured their last TQFP with ISE Specific Spartan6, so moving to Vivado and Spartan7 required a BGA design and assembly solution for Black Mesa Labs to continue. Details of the original prototype can be read on my S7-Mini Google Docs presentation .  The prototype was 100% successful aside from mass producing, so Black Mesa Labs contacted Trenz Electronic in Germany who agreed to make improvements for manufacturability and assemble, test and sell S7 Mini boards from their website. By the Fall of 2018 Trenz had working prototypes delivered to BML for evaluation. In Spring of 2019 the S7 Mini became a Trenz product for about $40 and is recognized by Xilinx on their website.


[ Plug In Boards ]

Black Mesa Labs has two 50mil ( 1.27mm ) plug in board designs for the S7 Mini that provide either 4 or 8 standard Digilent Inc PMOD connectors. Each PMOD provides 8 LVCMOS I/Os. The octa-pmod may be ordered from OSH Park here. The quad-PMOD may be ordered from OSH Park here.  TODO: In the future both designs will be on GitHub along with Gerbers, BOM and assembly instructions.

GitHub octa-pmod design link is here.


Here is a Twitter Link to a video of the Octa-PMOD board driving multiple HDMI/DVI monitors using the BML PMOD-to-DVI board that is now produced by 1bitsquared as part of the Ice Breaker crowd funded Lattice FPGA board.  Hopefully in the future the PMOD to DVI boards will also be sold separately. Will Green ( @WillFlux ) has some excellent tutorials on interfacing with these PMOD to DVI modules here. BML’s latest is PMOD to DVI provides full 24bit color using DDR and is available here.

[ GitHub example designs for the S7 Mini ]


  1. Hello World blinky LED design.
  2. PMOD template designs.
  3. Making DVI video using PMOD to DVI boards.
  4. MesaBus virtual 32bit PCI link over FTDI cable using
  5. Updating PROM firmware using + FTDI + MesaBus protocol.
  6. HyperRAM example design.
  7. SUMP2 Logic Analyzer using GUI on PyGame.
  8. SUMP2+DeepSump Logic Analyzer using and GTKwave.


BML S7-Mini FPGA Module

Reolink Argus Pro and Argus 2 Security Camera Installation and Review

2019.02.22 This blog is a quick setup guide and evaluation of the Reolink Argus family of solar powered motion activity security cameras.  I purchased both the Argus Pro and the Argus 2 which vary primarily only in the low light image sensor used.

Installation manual was downloaded from here.  Goal of this blog is to provide a simple setup guide and a camera evaluation for use in an external security scenario for capturing both pedestrians on a sidewalk and car license plates entering a confined cul de sac.

Step-1 : Unpacking.  The Argus Pro and Argus 2 cameras don’t come with on board memory but instead a uSD card slot. They accept up to a 64 GB card. First thing out of the box, insert a uSD ( about $10 for 64 GB in 2019 ).  With this, the frustration begins.  The opening is just big enough for the card, so you may need a paper clip or long finger nail to actually push it in all the way.  Once it is in – forget about ever removing it or replacing it.  I installed 3 cameras and the push-to-eject mechanism only worked on 1 of the 3 ( and stopped after a single eject ).  Why does this matter? Two reasons, chances are 3-5 years from now the flash on the uSD card will wear out. Would you rather replace a $10 flash card or a $100 camera?  Two, the camera stores standard H.264 video clips to the card in standard Windows compatible file system.  If you can eject the card, you can manually archive footage and view in a standard web browser without requiring the WiFi connection and proprietary Reolink PC Client software.  I fully expect in the future I will be opening up the housing of these supposedly waterproof cameras to attempt to extract and replace the card.

Step-2 : Camera Configuration.   Like many consumer products ( Amazon Echo for example ) your smart phone is required to configure the cameras.  I’m not a huge fan of this because it pretty much guarantees 3-5 years from now as iPhone and Android technology moves on you won’t be able to reconfigure all this camera kit you just spent $100s on.  I much prefer PC web based configuration ( like for routers, etc ) as they are much more likely to still work down the road.  But what can you do?  Anyways, for iPhone, go to the iTunes store and download the free Reolink app.  Fire it up and follow the prompts.  First it wants to know your camera information by looking at the QR code behind the battery – so before snapping the battery on the camera, run the iPhone app and point your iPhone at the QR code. Once it is recognized it will ask for your WiFi information. It probably already knows your home WiFi SSID, but you still need to enter the password in.  After this is done, your iPhone will create it’s own QR code on the phone screen. Insert the battery in the camera and point the camera at the phone until it recognized the QR code. The camera uses speech synthesis in English to prompt you – which is great ( if you speak English of course ).  That is pretty much it.  Your phone now has full control of the camera and you can use it to view live video, change settings, etc. But being a phone, this all pretty much sucks. I want the PC app for 24″ large screen video, mouse control, etc.   So….

Step-3 : PC Client Configuration. Download the PC ( or Mac ) client from the Reolink website. It comes in a ZIP file, pull out the EXE and install it.  Click on “Add Device” and now ignore everything the Software and the Manual tells you.

DON’T click the “Scan Device in LAN” button – as it will NEVER EVER EVER find your battery powered Reolink Argus devices even though they are on your LAN. This button is NOT meant for you to use you Argus camera buyer you. The manual doesn’t say this, the software doesn’t say it – SO I AM TELLING YOU THIS RIGHT NOW. Don’t press the button. It will be extremely disappointing.

Also DON’T enter the IP Address of your camera ( available on your iPhone App ) and attempt to enter Media Port 9000, Name, Password etc as that won’t work either for the Argus devices.  Both of these methods must for for other Reolink products ( POE wired cameras, etc ).

What is EXTREMELY obscure that I finally located searching and searching for help is that you need to select Register Mode = UID ( instead of “IP Address” ).  Now finding the UID code to enter is also EXTREMELY frustrating.  On the back of the Argus there is a tiny sticker about the size of a pencil erasure.  Not the big sticker behind the battery, but on the outside of the camera. This tiny sticker has a QR code and beneath it there is a 16 alphanumeric UID in an incredibly small font.  I had to use a magnifying glass to read it – and even then there were problems.  One of my three cameras contained a “I” in the UID, but it looked just like a “1” in the super small font. It took multiple tries to get it right.  For some reason, the iPhone App doesn’t report the UID for the cameras in the information page after setup.  This whole UID thing was a nightmare.  Once I got through it things are going much smoother.


Step-4 : Camera installation.  This is fairly straightforward but also frustrating – no fault to Reolink – just a limitation of infrared night vision cameras in general.  The camera comes with a standard 1/4 inch 20 UNC thread tripod mount that can either be screwed into a flat wood surface ( molly screws also included ) or a strap is available to attach to a tree limb.  The hard part is getting a location that works well at night. I’m warning you know, to see a person’s face clearly the camera needs to be about 3 feet directly facing them.  Car license plate numbers or even make and model? Forget about it.


Night results.  The “Mailbox” upper-left is the Argus-2 which has the Sony “Starlight” CMOS sensor that is capable of color at night ( if there is enough light ).  I have PIR LED lights all along the fence by the mailbox and have been unable to see the “Startlight” sensor work any better than the regular infrared Argus-Pro units ( Driveway, Sidewalk ). So, no magic night vision bullet.


Step-5 : Using the PC Client Software.  This is a bit frustrating as it appears like the Argus battery powered cameras were poorly bolted onto the existing Reolink PC Client app that was designed for POE ( line powered ) cameras. Let me explain.   The software has two tab modes “Live View” and “Playback”.  Intuitively if one wants to review and recorded footage from the night before, they would click “Playback” and get nothing. The cameras just indicate “State: Not Connected”.  There is nothing on the “Playback” screen to connect to the cameras. Instead, you have to click on the “Live View” tab and by each camera under device list there is this funny small black circle with a box and a triangle in it.  No popup text indicating what it does. Trust me and click on it. After a few seconds the camera will wakeup and live video will be displayed.  Do this for all the cameras ( there is no single button to wake up everybody ).  Once they are all green and “State: login success” you should see live video feeds. NOW and ONLY NOW can you switch to the “Playback” tab.


After each black circle with square and triangle is pressed the cameras go green. There is a battery symbol, but it doesn’t actually show the battery’s charge state.


The playback tab shows a calendar and a video timeline at the bottom for all the active cameras.  The blue indicates some video was recorded.  Unfortunately if you click your mouse on the the blue timeline, it won’t show you a still image for that moment in time. The views will still be blank.  You have to press “Play” ( Lower Right ). The “Stop” button won’t load a single frame – even the “Advance a single Frame” button won’t load a single frame.  You MUST press Play and then Pause to get a still image.  Annoying.

The software isn’t horrible. It nicely displays and sinks up all the cameras in time ( the ones that were active ).  A super nice feature would be a feature to have multiple cameras go active when a single camera’s PIR sensor detects something. I really wish this feature existed.  The most annoying thing is having to use the “Live View” page to individually turn each and every camera on and off when you want to review previously recorded events.  The download feature is really nice with the exception that it downloads the MP4 files to C:\DownloadFile  which is not standard for Windows – I went looking in the standard “This PC\Downloads” directory and got very frustrated and had to go searching.  The Windows 10 viewer is actually better and closely examining video clips. I recommend that over using the Reolink app.

The by far BIGGEST BLACK EYE for the Reolink Argus is that the PC Client ONLY WORKS if the internet is up. Apparently it phones home to the mother ship for some reason.  With my WiFi router up, but the cable modem disconnect – Reolink’s PC Client will not find the cameras.  That is just whacked. Both my PC Client and the cameras are on the same LAN – they should be able to communicate directly with each other. This is a tremendously stupid architecture decision in my opinion.  Why are they doing this? It sells more camera if you tell people they can access via the internet from their phones – so this is the way the clients work. Why is this such an issue? The way it is architected ( AFAICT ) is Reolink has a server somewhere on the internet that the cameras ping periodically ( every couple of seconds ) to see if a client wants to stream some video. If a client on the internet does, then the cameras send the video to the server and the client grabs the video from the server.  What this means is that not only must you have internet connection, but you are also 100% dependent on Reolink keeping their server operational.  History shows things like this tend to End-Of-Life and go off-line after 3-5 years. ( Example – Sony PS3 gaming server ).  Why they don’t also support a local internet free connection escapes me. That’s just plain stupid and inconsiderate.

Wish List for Reolink Argus 3:

  • Working uSD card ejector.
  • UID in bigger font and clear instructions on setting up PC Client.
  • PC Client access to cameras without having to phone home to Reolink server.
  • Plastic loops in the external case to support zip-tying camera without tripod mount.
  • Stronger IR LEDs.
  • Faster and longer distance PIR sensor.
  • Global PIR trigger. Allow the PIR on one camera to trigger ALL the cameras.

In Closing:  I like the physical cameras themselves, the solar panel charging is a wonderful feature.  The micro SD card not ejecting is a bummer. The mounting hardware is a nice little kit.  The PC Client software needs work. A lot of work to make it more friendly to the Argus battery powered line of cameras.  It is clear to me that they were poorly bolted on to existing software designed for always on camera – all the way from the UID setup nightmare to the powering the cameras on and off from live view to get the “Playback” to work.  Am I pissed I dropped $500 on these 3 cameras? A little upset, but I’m not returning them. I might even buy a 4th just to make the display complete.  Hopefully in time Reolink will make their PC Client software more functional for the Argus line of cameras.  At this point, I would only recommend others buy these cameras if they read this blog review first and fully understand what they are getting into and the limitations.  The iPhone application for them is excellent, and clearly the focus for this product.  The PC application needs work.

Closing picture, my cul de sac was recent hit with vandals painting swastikas and other racially offense words on people’s cars and garage doors.  Although I didn’t catch anyone tagging the neighborhood, I did catch a rabbit at 3:10am and a local Police cruiser at 3:20 AM – possibly in hot pursuit of the rabbit which is something.




Final location I went with after 1st night experiment is to place 2 cameras in a tree by the sidewalk and one between the garage doors.  This provides a good view of the cul de sac and provides the opportunity of making out someones face at night given the 3-5 feet limitation IR night vision. Having cameras near face level and also 3-5 feet away is crucial for the IR night vision to pick up facial figures.  Otherwise, all you see are shapes.


FCC tear down photos of what is inside.


2019.03.03 Update:  The uSD card failed in one of three cameras this morning.  It has been really cold ( below freezing ) – wondering if it is related. At first the camera found the card but said it needed formatting. Now it doesn’t even see the card. Went out and inspected camera to discover the uSD card actually ejected itself. Strange.




Reolink Argus Pro and Argus 2 Security Camera Installation and Review

BML GPIO-14 USB Board for PCs


2018.03.18 : BML project for using a $2 FTDI FT260Q for adding 14 bits of GPIO to any PC via USB with no device drivers required.


Ever miss the simple days of using a PC’s LPT1 parallel port to bit-bang GPIO over 8 output pins and 4 input pins of the DB-25 connector? I sure do.  My first design project as a BSEE graduate in 1993 was to design a LPT1 controlled test fixture for the Motorola MDT-9100-T data terminal (shown below).  Those were the days. By multiplexing 12 parallel port pins into 74HC dip CMOS latches and transceivers my test jig tested all the IO signals of the MDT-9100s 386sx motherboard. All of the diagnostic software could be written in C on my Windows 3.1 desktop thanx to this versatile interface. Those were the glorious simple days of computing.  Sigh…. Then USB came along and killed the wonderfully easy parallel port interface.

But wait, FTDI has recently introduced a low cost and very versatile USB chip called the FT260Q. It is unique in that it requires no device drivers. It provides up to 14 IO pins that can be used for driving LEDs, reading switches, interfacing to LVCMOS circuits all while requiring very little support circuitry.  This open source Black Mesa Labs’ project  describes the DIP-18 breakout board for the FT260Q which may be built for under $5.




The 24 x 19 mm 2-layer PCB may be ordered here from OSH-Park for just about $3 for 3 PCBs.




[ Bill of Materials ]

Qty-1 : 768-1268-ND : FT260Q-T IC USB TO UART/I2C 28WQFN : $1.83
Qty-1 : 240-2390-1-ND : FERRITE BEAD 600 OHM 0805 : $0.11
Qty-1 : 609-4613-1-ND : CONN USB MICRO B RECPT SMT R/A : $0.42
Qty-2 : F4239CT-ND : TVS DIODE 24VWM 150VC 0603 : $0.65
Qty-3 : 445-4112-1-ND : CAP CER 10UF 6.3V X5R 0603 : $0.06
Qty-2 : 399-7918-1-ND : CAP CER 47PF 50V C0G/NP0 0603 : $0.10
Qty-3 : 445-5111-6-ND : CAP CER 0.1UF 25V X7R 0603 : $0.10
Qty-4 : Resistor 4.7K 5% 0603
Qty-2 : Resistor 33 ohms  5% 0603
Qty-1 : Resistor 1 Mohm  5% 0603



The FT260 is a USB device which supports I²C and UART communication
through the standard USB HID interface. This is very cool as it means it should work with any USB host platform without requiring any special device drivers. See the FTDI Application Note AN_394 User Guide for FT260 for details on programming the FT260Q, also the datasheet.

To send and receive HID reports from Windows ( or Linux ) in the Python environment, the module hidapi is needed. Download the appropriate hidapi Python WHL for your platform from this link .  For example, at BML, currently running Python35 on 64bit Windows10, so downloaded both hidapi-0.7.99.post21-cp35-cp35m-win_amd64.whl and hidapi-0.7.99.post21-cp35-cp35m-win32.whl .

  1. Upgrade pip via “python -m pip install –upgrade pip”
  2. Install WHL via “pip.exe install hidapi-0.7.99.post21-cp35-cp35m-win32.whl”

With hidapi installed, you should now be able to run this example script from BML that will configure all the FT260Q pins as GPIO outputs and toggle them as fast as possible.  Note the USB HIDAPI interface to HID-Class devices isn’t “bare metal” blazing fast. This sample Python toggles all the GPIO pins every 300-400uS, or about 1kHz. For Windows, the HID API interface requires all reports be 64 bytes in length, so the example Python here always pads reports with trailing 0x00’s to be exactly 64 bytes long. Untested, but padding the reports under Linux should not be required and may be considerably faster than Windows.

[ ]

import hid;

h = hid.device();# See, 0x6030) # FTDI FT260Q device ID

print("System Status");
rts = h.get_feature_report( report_num = 0xA1, max_length = 255 );
print( [ "%02x" % (each) for each in rts ]);# list comprehension
h.send_feature_report([0xA1,0x02]+[0x00] +[0x00]*61 );# GPIO ON, I2C OFF
h.send_feature_report([0xA1,0x03]+[0x00] +[0x00]*61 );# GPIO ON, UART OFF
h.send_feature_report([0xA1,0x05]+[0x00] +[0x00]*61 );# GPIO3 ON, Int OFF
h.send_feature_report([0xA1,0x06]+[0x00] +[0x00]*61 );# GPIO2 ON
h.send_feature_report([0xA1,0x07]+[0x00] +[0x00]*61 );# GPIO4,5 ON 
h.send_feature_report([0xA1,0x08]+[0x00] +[0x00]*61 );# GPIOA ON 
h.send_feature_report([0xA1,0x09]+[0x00] +[0x00]*61 );# GPIOG ON 
h.send_feature_report([0xA1,0x41]+[0x00]*8+[0x00]*54 );# GPIOE,H

# 0xB0 : GPIO Write/Read Request 
# Byte-0 : 0xB0
# Byte-1 : GPIO[5:0] Value
# Byte-2 : GPIO[5:0] Direction 0=Input 1=Output
# Byte-3 : GPIO[H:A] Value
# Byte-4 : GPIO[H:A] Direction 0=Input 1=Output

# Output Loop : Configure all 14 GPIOs as Outputs and toggle them
while ( True ):
    h.send_feature_report( [0xB0, 0xFF, 0xFF, 0xFF, 0xFF ]+[0x00]*59);# Toggle
    h.send_feature_report( [0xB0, 0x00, 0xFF, 0x00, 0xFF ]+[0x00]*59);# All GPIO pins

# Input Loop : Configure all 14 GPIOs as Inputs
h.send_feature_report( [0xB0, 0x00, 0x00, 0x00, 0x00 ]+[0x00]*59);
while ( False ):
    rts = h.get_feature_report( report_num = 0xB0, max_length = 255 );
    print( [ "%02x" % (each) for each in rts[0:6] ]);# list comprehension

[ GPIO Pin Power Up Defaults ]

Not all pins powerup in GPIO tri-state mode. If powerup condition is important, BML recommends using the non-tristate pins as inputs with series resistors between your circuit and the FT260Q.  The tristate pins you should be able to pull high or low on powerup with appropriate (1K) resistor.

0 - Hard Low
1 - Tristate
2 - Tristate 
3 - Tristate - pulled up
4 - Hard High
5 - Tristate
6 - Tristate

7 - Hard Low
8 - Tristate
9 - Tristate
10 - Tristate
11 - Tristate
12 - Hard Low
13 - Tristate

[ Future Plans ]

Black Mesa Labs has plans to use this IC as both a SPI PROM programmer and UART interface to future FPGA boards. The low cost, small size and minimal external components ( no crystal, PROM, etc ) make this an ideal IC for low cost educational FPGA development boards from Black Mesa Labs. Next tutorial on using the FT260Q will make use of the internal UART capable of 12Mbaud. Look for future Xilinx Spartan7 boards from BML with a FT260Q embedded for both PROM programming of a bootloader and UART interface for Mesa Bus transfers at 12Mbaud.

[ EOT ]

BML GPIO-14 USB Board for PCs

BML DC/DC Switcher for 5V to 3V at 750mA in a TO-220 7805 Footprint

2018.03.14 : WARNING : The 100pF cap was originally placed incorrectly on the PCB layout. It was connected to GND when it should be connected to Vout. Gerbers have now been corrected and a new Shared Project uploaded to OSH-Park.   Also, at the end of this post is an alternative design using a different controller and inductor.  It has a 3A capacity and a much wider input and output voltage range.  It is untested as of this writing.

2018.03.03 :  This post is an open source hardware design from Black Mesa Labs for a simple DC/DC converter for dropping 5V to 3.3V ( or adjustable to lower voltages via resistor selections ). The design is based on the PAM2305 from Diodes Incorporated, a great little 1 Amp step-down DC-DC converter in a small TSOT25 package. The PAM2305 supports a range of input voltages from 2.5V to 5.5V, allowing the use of a single Li+/Li-polymer cell, multiple Alkaline/NiMH cell, USB, and other standard power sources. The output voltage is adjustable from 0.6V to the input voltage.


Black Mesa Labs has designed this simple 2-layer 9x9mm PCB of the above circuit in a 7805 TO-220 compatible pinout ( 3 pin 0.100″ Vin, Ground, Vout ) which is breadboard friendly.



The bare PCBs may be ordered from OSH-Park for only $0.60 for Qty-3 from this link.


The Bill of Materials is very small. All parts available from Digikey for less than $2. Note, if you don’t already have a resistor kit, I highly recommend this one, $23 for 170 1% values in 0603. Note: The inductors chosen were not ideal, The PAM2305 datasheet recommends an inductor current rating of 400mA above maximum output current.  This 2.2uH at 1.8 Amp rating looks promising for next iteration for 1.0V builds. This 3.3 uH at 1.2Amp rating might be better for 3.3V builds.


For resistor selection, an on-line calculator like this one for the LM317 can be helpful. The PAM2305 has a 600mV reference voltage however ( vs 1.25V for the LM317 ) so the desired voltage out needs to be scaled up 2.08x – also R1 and R2 are reversed.  For example, for 1.00V desired output voltage, plug in 2.08V into the online calculator. Going through some standard 1% resistor values results in R1=150K, R2=100K. These then need to be swapped around for the PAM2305 so that R1=100K, R2=150K.   Vout = 0.6*(1+(100K/150K)) = 1.00 Volts.   Alternatively, BML created a Google Doc spreadsheet here for PAM2305 voltage out calculation given R1 and R2 inputs.


Circuit fully assembled.


With a test load using a 3V inductive lamp. Vout is 3.29 volts at 100mA.


Power resistors were used for testing at maximum current. Test showed that running at 1A with a 3 ohm load (3W) the circuit was operational for about 5 seconds before overheating and dropping the output voltage to around 2.5V. Reducing the load to 4 ohms ( 2.7W ) the circuit did not overheat and sustained 3.20 volts at the load. In the future Black Mesa Labs may do a different version of this board design utilizing the 6-WDFN Exposed Pad package as it can dissipate 1W versus the 400mW of the TSOT-25 package. Here is a handy on-line V=IR ohms law calculator where you can dial in a voltage and current to solve for load resistor to test with ( or just use a calculator ).


The 1.0V version of this project ( R1 = 100K, R2 = 150K ) was tested with 3ohm, 2ohm and 1ohm loads with the following results:

3ohm Load:  Input 5V@80mA, 400mW. Output 983mV@328mA, 322mW.  80% Efficient


2ohm Load:  Input 5V@120mA, 600mW. Output 971mV@486mA, 471mW.  79% Efficient


1ohm Load:  Input 5V@280mA, 1,400mW. Output 929mV@929mA, 860mW.  61% Efficient. This experimented should be repeated using soldered connections – suspect the voltage drop may just be due to resistance in the breadboard.


Twitter video of this project:

[ Alternate Design ]

Available here from oshpark is an experimental alternate design using the 3A BD9C301FJ buck converter along with the SPM6530T4R7M inductor.  All the components are bigger, cost more, but you get 5V-18V input range and 3Amps output. BML has not built this design yet, but is included here as an experiment.



The PCB has components on both sides. Top.





The capacitors are 0805s, all other passives are 0603s.  Note that there are two Rup resistors in series. This is to allow precise Rup/Rdn voltage divider using a limited set of 1% resistors.



BML DC/DC Switcher for 5V to 3V at 750mA in a TO-220 7805 Footprint as a VCD waveform viewer for Xilinx Vivado RTL Simulator


2018.02.28 : The latest version of ( available here ) GUI running under PyGame on any platform may now be used as a light weight rudimentary VCD waveform viewer for RTL simulations. This posting is a short tutorial on using the Xilinx Vivado Simulator ( available in WebPack ) as a command line simulation tool for Verilog and VHDL RTL designs. With the following setup, the command line Xilinx simulator will output a VCD file which may then be imported into ( or GTKwave.exe ) for viewing.

The example design in this tutorial is a simple Verilog hierarchical design composed of top.v and counter.v.

[ top.v ]

module top
 input wire rst_l,
 input wire clk, 
 input wire load_en,
 input wire [7:0] load_d,
 output wire [7:0] test_out
);// module top

wire reset_loc;
assign reset_loc = ~rst_l;

// Example 8bit counter
counter u_counter
 .clk ( clk ),
 .reset ( reset_loc ),
 .load_en ( load_en ),
 .load_d ( load_d[7:0] ),
 .count_out ( test_out[7:0] )
);// module counter

endmodule // top.v


[ counter.v ]

module counter
 input wire reset,
 input wire clk, 
 input wire load_en,
 input wire [7:0] load_d,
 output reg [7:0] count_out
);// module counter
reg [7:0] test_cnt;

always @ ( posedge clk ) begin : proc_cnt
 count_out <= test_cnt[7:0];
 test_cnt <= test_cnt[7:0] + 1;

if ( load_en == 1 ) begin
 test_cnt <= load_d[7:0];
 if ( reset == 1 ) begin
 test_cnt <= 8'd0;

endmodule // counter.v


To import these files into the Xilinx Vivado Simulator, we will create a “project” file which lists all of the RTL files to be compiled. Both VHDL and Verilog are supported.

[ top.prj ]

verilog xil_defaultlib "./top.v"
verilog xil_defaultlib "./counter.v"

Two shell scripts ( either Linux or DOS for your platform ) are used for compiling and simulating the design files.

[ / *.bat]

xvlog -prj top.prj
xelab -prj top.prj -s snapshot top -debug typical

[ / *.bat ]

xsim snapshot -tclbatch do.tcl


A collection of TCL files are used during simulation for both specifying which signals to capture to VCD file and also stimulus to force upon the design.  The addition to the Xilinx  simulator to accept “add_force” commands is significant as it means writing Verilog test bench files at the top level is no longer a requirement. This allows the Xilinx simulator to be rapidly used during module development and behaves as a low cost RTL simulator.

[ do.tcl ]

source wave.tcl
source force.tcl

[ wave.tcl ]

log_vcd {/top/clk}
log_vcd {/top/rst_l}
log_vcd {/top/reset_loc}
log_vcd {/top/u_counter/*}
# Or recursively capture everything
#log_vcd [get_objects -r * ]

[ force.tcl ]

add_force /top/rst_l 0
add_force /top/load_d 00 -radix hex
add_force /top/load_en 0 
add_force /top/clk {0 0ns} {1 5ns} -repeat_every 10ns
run 10ns
add_force /top/rst_l 1
run 10ns
add_force /top/load_d 11 -radix hex
add_force /top/load_en 1; run 10 ns;
add_force /top/load_d 00 -radix hex
add_force /top/load_en 0; run 10 ns;
run 200ns

With these files all created, running the compile and simulate scripts should generate a dump.vcd file. The VCD file may then either be imported into via this command:  %python dump.vcd  or loaded into GTKwave.

Note: The latest version of binds the F8 key as a macro to the “Reload_VCD” command. This is extremely handy as from a shell window, you can change your stimulus force file or Verilog, and re-run the compile+simulate scripts and then just press F8 with in focus to reload the new VCD file. This removes the need to exit and relaunch every time a new VCD file is generated. GTKwave accomplishes the same with the Reload button ( two circular arrows ).

Note: VCD import is really just intended for offline importing VCD files that exported from a Logic Analyzer capture. As VCDs can vary from source to source, is very likely to choke on all but the simplest VCD files.  For these more complicated use cases, GTKwave.exe is an EXCELLENT and robust VCD viewer.  This blog post is primarily aimed at LA users who are familiar with the waveform viewer and would like to use it for viewing simple RTL simulations as well.

GTKwave is usually available here, but apparently SourceForge may be no longer? It is an awesome VCD viewer, so I would expect for it to pop up again ( maybe this is it on  GitHub? ).


[ EOF ]

 as a VCD waveform viewer for Xilinx Vivado RTL Simulator

BML USB 3.0 FPGA interface over PMOD

2017.12.19 :  Black Mesa Labs is presenting an open-source-hardware USB 3.0 to FPGA PMOD interface design.  First off, please lower your expectations. USB 3.0 physical layer is capable of 5 Gbps, or 640 MBytes/Sec. This project can’t provide that to your FPGA over 2 PMOD connectors – not even close. It does substantially improve PC to FPGA bandwidth however, 30x for Writes and 100x for Reads compared to a standard FTDI cable based on the FT232 ( ala RS232 like UART interface at 921,600 baud ). A standard FTDI cable is $20 and the FT600 chip is less than $10, so BML deemed it a project worth pursuing.


Measured Data Transfers comparing FT600 to FT232:

USB 3.0 to FT600 at 100 MHz: Writes=1,384 KBytes/Sec, Reads=567 KBytes/Sec

USB 3.0 to HUB to FT600 at 100 MHz: Writes=416 KBytes/Sec, Reads=187 KBytes/Sec

USB 2.0 to FT600 at 100 MHz: Writes=279 KBytes/Sec, Reads=131 KBytes/Sec

USB 2.0 to FT232 1×6 0.100″ at 1 Mbps: Writes=43 KBytes/Sec, Reads=5 KBytes/Sec

Wait, what?  Measured in KBytes not MBytes per second? Is BML to blame? Only partly. This BML project utilizes 1/4 of the LVCMOS bandwidth possible of the FT600 to both make the IO fit across PMODs and also work with existing Mesa Bus Protocol IP.  The FT600 has 16 data pins capable of 200 MBytes/Sec but 1/2 the data pins are deliberately tossed to fit within 2 PMODs ( 3 PMODs wouldn’t be practical ).  Existing Mesa Bus Protocol IP is used – which transfers ASCII nibbles (0-9,A-F) instead of binary, so the maximum logical throughput is reduced another 2x to 50 MBytes/Sec.  Observed transfers are just over 1 MByte/Sec.  This means if all 16 pins were used and a binary protocol transfer instead of ASCII, rate would be about 5MBytes/Sec – still away off from 200 MB/s . So what is going on? This is a perfect application for the SUMP2 Logic Analyzer from BML.  Instead of wiring up the iceStick, SUMP2 was instantiated directly in the FPGA along with the FT600 interface ( this is really what SUMP2 is designed for, a free open-source replacement for Xilinx ChipScope and Altera SignalTap. SUMP2 supports capturing 32 compressed events and up to 16 non-compressed DWORDs into on-chip FPGA block RAM ). Below is a PNG screen dump of SUMP2 capturing the FT600 FIFO status flags (RXF,TXE) and the FPGAs control signals ( RD,WR ). What is immediately apparent is that the majority of the time ( ~154uS out of ~160uS ) the FT600 doesn’t have any data for the FPGA. RXF is sitting low even though Python is trying to send data as fast as possible.


Within a 10 ns clock cycle of RXF asserting, the FPGA asserts RD and converts the Mesa Bus Packet into a local bus burst ( with about 350ns of pipeline latency ). The observed distance between the 32bit lb_wr pulses is precisely 8 clocks, the fastest possible ( DWORD = 4 Bytes x 2 ASCII Bytes per Binary Byte = 8 clocks ).  Clearly both the FT600 and the FPGA design are working as fast as possible with what is coming down the USB 3 pipe.sump2_0010.png

So, the truth is that the majority of the time ( 154/160us = 96% ) the PMOD interface is sitting idle even though Python is trying to write and read from the FT600 as fast as it can. Clearly the USB 3.0 pipe is not full. Who is to blame? Is it Python? Windows? Intel Chipset? Don’t know. Would it be faster on Linux? Hopefully. Would compiled C be faster than Python? Probably. Would we ever achieve 50 MBytes/Sec? Probably not. FTDI Application Note AN_386 goes into some detail, there is a lot of software between the user software and when the electrons finally hit the USB 3.0 cable.

Is just over 1MBytes/Sec a disappointment? Yes.  A show stopper? No. Using the FT600 is still the fastest way (BML is aware) of inexpensively getting data from a PC into any FPGA without instantiating a PCI Express IP core and building a PCI Expresss plug in card. 30x and 100x improvements on Writes and Reads is substantial.

2017.12.20 – Update, an acquaintance on Twitter has reported using an FT600 with a proper C client over an FMC connector (all 16 pins, 100 MHz,  binary transfers ) of 185 MB/s ( out of 200 MB/s total ). That is excellent news and proof that Python is most likely the bottleneck. Based on his results, the BML dual-PMOD board should be capable of 1/4 that ( 8bit, ASCII ) or 46 MB/s. Github link to C source is here.

2017.12.21 – Update – another acquaintance on Twitter has reported achieving 240 MB/s using FT601 ( 32bit ) and C on Linux. His USB interface software is on Github here.

Now that performance explained – About the design, let’s begin:

[ Software Setup ]

Step-1) Download and install FTD3XX Device Driver from .  For example, for Windows, download and run FTD3XXDriver_WHQLCertified_v1.2.0.6_Installer.exe

Step-2) Download and install Python module for D3XX from  For example, unzip, “%cd D3XXPython_Release1.0” and then “%python install”

Step-3) Create a directory for your script and copy FTD3XX.dll and FTD3XX.lib from unzipped D3XXPython_Release1.0 folder.

[ Hardware Setup ]

Board design.  The board is a 2-layer PCB that is available either via Gerber download or direct purchase from OSH-Park here ($10 for Qty-3). The board consists of the FT600 chip from FTDI, 3 LDO regulators, a 30 MHz crystal and a bunch of 0603 and 0805 passives ( 10uF, 0.1uF, 18pF, 10K, 1.6K, 33 ohm, Ferrite Bead ).


FPGA Hardware setup is a bunch of Verilog IP.  I/O timing over the PMODs was tight, so a PLL is used to remove clock tree insertion delay on the 66/100 MHz clock provided by the FT600. Xilinx Spartan3 LVCMOS 3.3V 8mA Fast IO buffers were required to run at 100 MHz. Since actual throughput doesn’t really get impacted, it is recommended to run at 66 MHz unless a 100 MHz clock is needed for other reasons. The clock from the FT600 is software selectable to be either 66 MHz or 100 MHz and the clock automatically shuts off when USB sleeps during inactivity. Thankfully, it turns on 100’s of ms prior to data transfers, allowing for PLLs to lock if needed.  WARNING: An annoying feature of the FT600 is that using the FTDI configuration program you can select to keep the FT600 clock on always – but what isn’t mentioned is that if you select this option, the device will no longer work with USB 2.0 – at all.

File_000 (12)_cropped.jpeg

Design files are here on my public dropbox. They include example Python for testing Write/Read performance, Bill of Materials, Gerbers, Layout files, Layout Screen Shots and example Verilog test design working on a Xilinx Spartan3. A future blog post will go into details on using Mesa Bus Protocol for virtual 32bit PCI like register reads and writes both from user Python and with bd_shell.exe – a Windows .NET app written in Powershell that provides a useful command line interface for writing, reading and scripting register access over a Mesa Bus Protocol link ( either FT600 dual-PMOD or simple FT232 2-wire. A new version of here supports both FT232 and FT600 interfaces for applications like and bd_shell.exe to share access to FPGA memory space using Mesa Bus Protocol over Berkeley Sockets for ICP. SUMP2 works great over the FT600, especially for captures with 16 DWORDs of data at 8K samples – the 100x faster reads makes a huge difference.

Stay tuned for more BML open-source hardware and software projects that utilize this FT600 USB 3.0 interface.  Follow me on twitter @bml_khubbard



BML USB 3.0 FPGA interface over PMOD

BML 50mil (0.050″ , 1.27mm) Proto Boards for Rapid Surface Mount Prototyping



0.100″ proto boards are readily available and great for prototyping with 1980’s DIP thru-hole technology.  Trying to use them with 1990s and newer surface mount devices is like picking your teeth with a log however.  0.050″ pitch vias line up perfectly with SOIC ICs, SOT-23s and 0603s passives but for whatever reason proto boards with 0.050″ pitch don’t really exist.  Black Mesa Labs aims to change that. BML is proud to introduce a family of 0.050″ pitch proto boards for interfacing with Arduino, RaspPi and FPGA boards. All boards designs are available for free and may be purchased from OSH-Park directly or optionally downloaded as Gerbers and CopperConnection layout files from my public Dropbox here.  If you don’t want the convenience ( and free shipping ) of ordering directly from OSH-Park, the Gerbers may be uploaded to most PCB fabs ( for example, ITEAD in China ).

P.S. – While you air wire your circuit together, don’t forget to use some Copper tape to add extra ground returns and signal shields.


These FPGA single PMOD boards come in 1″, 2″ and 3″ lengths ( 2.5cm, 5cm, 7.5cm ). They provide both a GND and 3.3V perimeter. They have a FPGA PMOD connector footprint on the left, but may be used standalone of course without an FPGA board.

Click here to purchase Qty-3 of these 3″ PCBs for $10 from OSH-Park.


Click here to purchase Qty-3 of these 2″ PCBs for $7 from OSH-Park.


Click here to purchase Qty-3 of these 1″ PCBs for $4 from OSH-Park.



These FPGA dual-PMOD boards also come in 1″, 2″ and 3″ lengths ( 2.5cm, 5cm, 7.5cm ). They provide both a GND and 3.3V perimeter.


Click here to purchase Qty-3 of these 3″ PCBs for $24 from OSH-Park.


Click here to purchase Qty-3 of these 2″ PCBs for $16 from OSH-Park.


Click here to purchase Qty-3 of these 1″ PCBs for $8 from OSH-Park.


The Arduino UNO board should mate with any board with a UNO footprint. It has a GND, 3V and 5V perimeter ring around the 0.050″ grid. There is also a 2×15 0.100″ grid on the left for external interfacing ( or large components ).  A FTDI 1×6 0.100″ connector is available for (optionally) connecting to the Arduino RX and TX serial lines.


Click here to purchase Qty-3 of these for $22 from OSH-Park.


The Arduino ProMini shield is extremely multipurpose as it can be used to interface small SMT devices on a 0.050″ grid to a standard DIP 0.600″ grid ( breadboards ). PCB design uses castellated 0.100″ vias on the perimeter allowing this board to be soldered directly to the back of a Pro-Mini or any 0.100″ proto board without requiring any tall headers. Kapton tape should be placed between PCBs to prevent shorting. If you have just a few surface mount components you want to add to a bigger 0.100″ proto board design – this is the board for you. Cheap too.

Click here to purchase Qty-3 of these for $4 from OSH-Park.

If you don’t already know about the Arduino Pro-Mini – it’s an awesome deal for $10.


The Pi Zero shield may be used with any Pi with a 2×20 0.100″ header. It has a GND, 5V and 3V perimeter ring around the 0.050″ grid.  2×7 0.100″ grids are available on both the left and right sides of the board.

Click here to purchase Qty-3 of these for $15 from OSH-Park.


Latest is this 1″ x 1.5″ generic 50mil + 100mil that can optionally be snapped in half. Only $7 for Qty-3 from OSH-Park here.


And finally, BML is working on a family of SMT to 0.050″ “sleds”. Castellated PCBs for breaking out really small SMT stuff to the larger 0.050″ grid.



Misc SOIC-16 to 0.050″ castellated for like $1.

Misc SOIC-8 / SOT-23-8 to 0.050″ castellated for like $1.

Misc TSSOP-28 to 0.050″ castellated for like $1.

Misc QFN32 to 0.050″ castellated for like $1. ( Example ADV7280 package )

Looking for something else? Let me know – we can most likely work something out.




BML 50mil (0.050″ , 1.27mm) Proto Boards for Rapid Surface Mount Prototyping