I got a favorite new tool at Black Mesa. A saw blade for an Xacto knife I rarely used previously. For a $5 blade pack I can now make custom connectors any dimension I need. Saves me a ton of $ as I can purchase a single 1×40 0.100 from Jameco for $1 and cut it up into multiple smaller connectors ( example below 1×6 ) that would cost be about $1 each from Digikey. Trick is to pull the pin adjacent to the last pin desired and then saw away under a microscope and cleanup with a metal file at the end. Works fantastic.
Sometimes the simplest projects are the best. This is my “Backdoor to Scope Out” project. I use my “Backdoor” connection to interface a computer to FPGAs when a regular bus ( PCI ) isn’t available. What I call the “Backdoor” is just a FTDI 1×6 asynch serial connection at 921,600 baud – pretty much standard in Arduino land – I just use it as a really slow bus bridge into FPGAs. As soon as a regular connection ( PCI for example ) is working, the backdoor connection goes unused. This project repurposes the otherwise dormant Backdoor header for debug to drive state signals out to an oscilloscope using low cost cables. The cable solution I chose was 1/8″ TRRS ( headphone jack ) to RCA Audio-Left,Audio-Right, Composite-Video that was standardized by the Camcorder industry. The cables are cheap ( $10 ) and fairly high quality that go 3′ to 6′ from a compact 1/8″ headphone plug to 3 RCAs that are easily converted to BNC.
The first board converts a 0.100″ Header to a thru-hole TRRS jack. I was shocked and disgusted to discover that “shield” isn’t used for signal return ( Ground ) on the TRRS connector – but instead used for Audio.
The second board converts the 1×6 FTDI header to the “new” 1×6 reversible scope-out header. I wanted to make the connection reversible so that the ~bulky~ 1/8″ plug and socket could go in 1of4 orientations when plugged in to guarantee clearance from other components that may be on a PCB.
The final test for the project was to drive a 50 MHz and 40 MHz square wave onto 2 of the 3 RCA cables over 6 feet and observe final signal integrity and any potential cross talk. End result was great – perfect for FPGA state debugging. Total cost for complete 3 channel solution was under $20. Now I have a robust 3 channel 0.100″ connection to an oscilloscope using readily available cables.
Sometimes convenience has a price. I designed this PCB tonight to use with my new idea of connecting a 3.5mm TRRS jack ( 3.5mm headphone ) to 3 FPGA outputs then adapt that to a readily available camcorder cable with 3 RCAs ( Red,White,Yellow ) to BNC then to oscilloscope. This board takes up to 8 of those RCAs and adapts them to a Saleae 1×9 0.100″ logic analyzer pinout instead. Simple to design, but the board was 1″x2″ due to the RCA connector size, I even shared vias between RCA connectors to save area – still $9 for a stupid interconnect adapter. Hope its useful in the long run. Idea for this board is that RCA cables are normally plugged into a analog scope for quick live measurements and can be easily switched to a Saleae for digital capture at 10 MSPS for seconds worth of sampling.
Assembled my first NanoPi FPGA board today! The NanoPi is a variation of my existing Nano6 Xilinx Spartan6 2 layer FPGA breakout board but designed specifically to connect mechanically and electrically with a RaspberryPi A+ or B+ Linux single board computer. Purpose of the project is to greatly enhance the low cost Linux SBC infrastructure provided by the Pi with fully flexible and custom real time hardware control and high speed IO of a low cost FPGA.
Connected together they make up a 32bit ARM Linux workstation with USB,Ethernet, HDMI video and a software reconfigurable FPGA providing 250K gates of logic, 512Kbits of RAM and 32 configurable LVCMOS or LVDS high speed IO. Very small package for only $50 BOM cost with tremendous amount of capabilities.
What I found most intriguing about this project is that I can configure Linux on the Pi ( Raspian , derived from Debian ) to boot and automatically login in and execute a predetermined Python script of my choosing. Python on the Pi has full access to video and GPIO ports. The Pi provides a 125 MHz SPI serial port that I have connected directly to my Nano FPGA. Now all I need to do is write the Verilog for the SPI interface to LocalBus bridge inside the FPGA and a simple Backdoor library of calls in Python for doing low level bus writes and reads to the FPGA. At 125 MHz and sending binary this FPGA Backdoor interface will be 200x faster than my Windows FTDI 921,600 baud UART interface I currently use sending ASCII. In the past, if I wanted a hardware project with any kind of low power and small form factor, I would have to turn to an ARM7 chip or Arduino and write and compile C code – a time consuming process. With this platform, I can script everything in Python ( much faster to develop in ) and initially store all the files on my Synology NAS network drive as the Pi easily mounts my filesystem thanks to Samba. Tremendous improvement in productivity over writing embedded C. The Pi can also run completely headless and the serial port can be used for remote shell login for using Vi to edit and test software.
Now for technical details of the project: The FPGA is a 45nm Xilinx Spartan6 XC6SLX9 that I buy onesie-twosie from Digikey for $15 ( probably $5-$7 in volume ). The FPGA is powered from 5V supplied either by the RaspberryPi or the FTDI header. Two diodes prevent the Pi from trying to power a computer plugged into the FTDI cable or vice versa. Two SOIC8 LDOs regulate the 5V down to 3.3V IO and 1.2V core voltages the FPGA requires. A 40 MHz reference oscillator provides a clock that the FPGA can PLL any internal core clock frequency it needs. Finally, an 8Mbit SPI PROM provides 2x the capacity needed for a single FPGA bitstream. The total BOM for the design is about $30 including misc Caps, Resistors, LEDs , Diodes and connectors. FYI – for them same price I also purchased the RaspberryPi SBC – manufactured in millions, quite the bargain. The FPGA has 2 x16 Nano Bus Connectors, a 1×6 FTDI serial port connector and dedicated traces going to the Pi’s GPIO connector for UART Serial, SPI Serial and a hand full of GPIOs. A x8 expansion connector ( currently not populated ) is shared between the Pi and the FPGA and could potentially be used for an add on board for switches, knobs, LEDs, etc.
[ Board Design ]
Board design was very straight forward. I took my 2 layer ExpressPCB design files from my original Nano6 skinny and widened the design to match the Pi’s width and allow for 2 x16 Nano bus connectors instead of the single x16 of the Nano6 skinny and routed all the signals I could from the Pi’s 2×20 GPIO connector to the FPGA’s unused pins. Board cost was $15, about 2x my normal FPGA breakout board cost for a 2 layer PCB from OSH-Park.
[ Board Bringup ]
Step-1 : Initial bringup of the FPGA board post assembly always starts out with applying 5V from my linear bench supply and making sure excess current isn’t flowing due to any solder shorts or just plain wrong design errors. Around 10mA is typical. I always visually inspect the FPGA under a microscope at 30x, so shorts usually don’t exist by the time I apply power.
Step-2 : Loading Bootloader bitstream via JTAG. The FPGA wants to configure itself on powerup from the SPI PROM, but the SPI PROM is empty initially so I use the Xilinx JTAG programmer along with Impact application on Windows to load my bootloader bitstream into the FPGA. Normally I include the Digilent HS2 JTAG footprint ( 1×6 0.100″ ) for quick JTAG access on a board. For this design I didn’t have the PCB area available around the FPGA so I instead did a 2×2 0.100″ grid with only TMS,TCK,TDI,TDO signals. GND and 3V VREF are available on the Nano x16 bus headers. I never actually solder headers into my JTAG vias as I use JTAG usually just once on bringup. Instead of solder header, I insert the header pins on the flying lead wires and apply pressure against the vias to establish a good contact during the download process. It takes two hands, but installing headers would be extra effort, extra cost and also ruin the overall appearance of the finished design. With the bitstream loaded over JTAG – if the FPGA is functioning, my 1Hz heartbeat LED will flash and I can continue to the next step of loading the PROM.
Step-3 : Loading the PROM can be done using Xilinx SW – but it doesn’t work always using an HS2 JTAG adapter, so instead I rely on my own bootloader design and BD_SHELL.exe application. My bootloader design is a simple “BSP” FPGA design that provides Backdoor LocalBus access via FTDI to a SPI PROM interface and some control registers. BD_SHELL.exe has built in command for loading SPI proms from bitfiles into multiple “slots” of a SPI PROM. The 1st Slot-0 is where my bootloader design is placed. For the XC6SLX9 FPGA, the 8Mbit PROM has room for 2 slots. My bootloader design on startup checks the logic level of an external jumper pin, if the jumper is open, the design initiates an ICAP reconfigure to Slot-1. If the jumper is closed, the bootloader design in Slot-0 stays resident, allowing the PCB to always be reconfigured over USB even if a bad user design is loaded into Slot-1. Loading the PROM takes three steps from BD_SHELL.
1) prom_root : this unlocks slot-0 which is normally locked and unable to be written to.
2) prom_load slot0.bit 0 : this loads slot0.bit into slot-0 ( the bootloader )
3) prom_load slot1.bit 1 : this loads final user design into slot-1
Once the PROM is correctly programmed, I should never have to use JTAG again ( Yes! ) as a simple jumper will guarantee the bootloader design stays resident, allowing BD_SHELL.exe to program Slot-1 of the PROM via USB FTDI interface. The Pi will also have access to the PROM interface, allowing for network FPGA firmware updates over Wifi or Ethernet. Last I checked – trying to do this from Arduino was more than just an afternoon project.
Step-4 : Board Level Test : The bootloader design has 2 purposes, 1) a guaranteed way of reconfiguring the FPGA PROM even if a bad user design is loaded and 2) provide a built in self test feature for testing that a board has been assembled correctly. Typing “prom_bist” from BD_SHELL will enable the BIST feature of the bootloader design. When BIST is enabled, the IOs of the x16 Nano bus connectors that are normally tristated will be actively driven by an 8bit counter. Board level test is performed by taking a scope probe ( or a Saleae 8bit lead ) to all the IO pins and confirming they are toggling as expected.
Whats Next? As I mentioned, I need to write a bunch of Verilog for the SPI interface to LocalBus bridge and then some Python. I have plans to have the FTDI connector to the FPGA wait for 30 seconds ( how long Linux takes to boot ) and if the FPGA’s backdoor hasn’t been opened by an external PC ( Windows running BD_SHELL ) then the FTDI connector will get redirected from the 921,600 Backdoor FPGA interface to the 115,200 RaspberryPi terminal login interface instead. This will allow a user to run the Pi headless and use a standard FTDI cable for remote login from an external PC. I supposed I could have included 2 FTDI headers, but this seems cleaner. Regarding applications – the NanoPi can be used for all sorts of stuff potentially. It provides the power and flexibility of the Python scripting language with the high speed IO capabilities and real time logic functions of an FPGA. By designing PIT timers into FPGA logic, Python scripts may be interrupted to perform time sensitive actions that usually wouldn’t be possible in a scripting environment. Potentially the NanoPi could be used for things like chip testing and board testing, running tests written in Python that interface to external hardware via the FPGA and then generating reports that are either sent off over ethernet, serial or stored locally on a USB flash drive. Its a platform with huge potential in the size of a pack of cigarettes ( do people still say that ? ).
Looking forward to the next stage of this project – writing Python and Verilog to make the combination come alive. Stay tuned!
One of my favorite tools ( that I forgot to mention when talking bout my Microscope and Oscilloscope ) is my 8bit Saleae Logic Analyzer. It is a $150 8bit LVCMOS, 24 MSPS logic analyzer that works by sampling signals using a Cypress CY7C68013A, a single chip that contains a synchronous input FIFO, 8051 uC and a USB 2.0 interface. The hardware is not all that impressive, but the software is mind blowing fantastic. It is a full waveform GUI that is easy to configure and has built in decoding for UART, SPI, I2C, etc. The most impressive feature is that the samples aren’t stored locally, but in Windows RAM and the UI makes it trivial to acquire over a billion samples over a 10 second period and rapidly navigate those billion samples visually for things like spurious interrupts, etc. It is really a great tool for capturing a tremendous amount of data and sorting through it.
Sadly, Saleae has stopped making the original low cost 8bit logic. As far as I can piece together, they had them manufactured overseas and clones of the $150 Saleae started showing up on eBay for $15. One company even brazenly uses a picture from the Saleae website showing that the Saleae software will run on their PCB. It turns out that the Saleae crown jewel ( the software ) is available for downloading and the hardware they charge $150 for has a $10 BOM and is trivial to copy. Hard lesson to learn. IBM learned it the hard way and made Microsoft very rich. Now Saleae is planning to manufacture their new products themselves – which I can’t fathom their volume being high enough to justify. Its too bad they don’t open-source their old hardware design and sell their software ( with keys ) for the clone market. As of today,you can’t buy their old products anymore and their new products have a long lead time for delivery. The Amazon and Sparkfun distribution channels are completely dry of anything from Saleae. I fear for their long term survival.
Anyways – great products, great software technology – highly recommended.
[ 01.14.2015 ] Fully evaluated my new USB 2.0 FT232H board tonight. Modified my Xilinx Spartan6 Nano FPGA design to PLL the 40 MHz reference XO to 120 MHz instead of 80 MHz so I could get a perfect UART divisor to 24 MHz for 12Mbaud communication. Then I modified my SUMP.exe application to configure the FTDI DLL for communications at 6 Mbaud and 12 Mbaud instead of normal 921,600 baud. Learning how to communicate to the FTDI DLL from Powershell ( I had to reverse engineer C# example code ) in December 2014 was what started this project to begin with as it allows configuring baud rates faster than Windows COM limits (921,600). With everything modified I had SUMP measure the event dumps of 8KB FPGA RAMs using the different physical interfaces ( USB 1.0 FT232R vs USB 2.0 FT232H ) and different software interfaces ( Windows COM driver versus FTDI DLL ). My new board is definitely faster ( 3.5x ) but not the 12x faster that I had hoped for. Would it be faster with a C or C# application instead of Powershell? Probably, I’m not about to go down that path though.
USB 1.0 FT232RL COM4 @ 921,600 baud : SUMP Dump took 248ms or 262Kbps. 1.00
USB 1.0 FT232RL DLL @ 921,600 baud : SUMP Dump took 240ms or 273Kbps. x1.04
USB 2.0 FT232H COM4 @ 921,600 baud : SUMP Dump took 257ms or 255Kbps. x0.97
USB 2.0 FT232H DLL @ 921,600 baud : SUMP Dump took 237ms or 277Kbps. x1.06
USB 2.0 FT232H DLL @ 6,000,00 baud : SUMP Dump took 83ms or 790Kbps. x3.02
USB 2.0 FT232H DLL @ 12,000,00 baud : SUMP Dump took 71ms or 923Kbps. x3.53
So, I suspect I may have hit a Windows / Powershell limit at around 900Kbps payload at 12Mbaud using the default asynchronous 2-wire interface. This probably puts a kabosh on my next board with the FT232H that has the 40MByte/sec 8bit FIFO interface ( 320Mbps theoretical ). I am skeptical I will get any faster than the 12Mbaud asynch serial and its a lot of Verilog writing and debugging to implement the FIFO interface inside the Spartan6 FPGA, not to mention consuming a full Nano x16 bus connector. I like to follow the Ethernet evolution model of not changing until you can achieve a 10x improvement. 3.5x improvement is good – but not 10x. I think I may have to make the trade off of rapid SW development in a scripting language ( Powershell ) versus fastest possible HW interface requiring low level compiled code ( C, C++ ), since SUMP transfers RLE compressed data anyways – really, I guess I’m not in THAT much of a hurry as it is transferring the entire event dataset in 250ms at 921,600 baud – which isn’t too bad really, that’s not even enough time to get a cup of coffee.
Question : FTDI just announced the new chip FT600Q that does USB 3.0 Superspeed ( 5 Gbps ) in a MLF56 package. Do I design a Nano x16 peripheral board for one when they ship end of this month? Maybe – it would be a great technical achievement to get 5Gbps SERDES chip – “Black Mesa Labs – Delivering 5Gbps SERDES on 2-layer PCBs”. Will it be faster than my new FT232H USB 2.0 ? probably not constrained by Powershell and Windows. Great challenge regardless. Wait and see I suppose…
[01.14.2015] I designed a very simple $2 circuit board to breakout a “TRRS” (Tip-Ring-Ring-Shield ) 3.5mm headphone jack that you see all over the place these days. I’m wanting to drive multiple channels of an oscilloscope and the 3 RCA to 3.5mm TRRS cables seem to be in use everywhere and would be useful for low bandwidth ( ~50MHz ) applications for capturing digital state transitions ( not so much signal integrity ). The TRRS jacks exist in smart phones to support earbud head sets with microphones and also in video devices ( video iPod, camcorder, etc ) to deliver Left and Right audio plus a Composite video on 3 conductors plus a return instead of the normal “TRS” Tip-Rings-Shield 2 conductor stereo connector. Digging into to their pinout I was astonished to find out that mechanically all the TRRS plugs and receptacles seem compatible, but electrically EVERYBODY wires them up differently. The return signal actually isn’t the “S” ( shield ) for most manufacturers ( although it is for some ). The “S” is return for 3.5mm mono, 3.5mm stereo, but not necessarily 3.5mm TRRS 3 conductor. Some devices go in the TRRS order of “Audio-Audio-Ground-Video”, some “Audio-Video-Ground-Audio”, some “Audio-Audio-Video-Ground”. I looked up various TRRS to RCA cables on Amazon and about 1/2 the reviews said things like “piece of junk – didn’t work” or “audio on only one channel, no video” or “didn’t work until I plugged the red into video and yellow into audio jack”. What a disaster. How much does this cost Amazon in returns? Bad design decisions like these are made by electrical engineers and it really makes the industry look bad. I ended up going with the “Camcorder” ~standard~ as at least multiple manufactures agreed to it for video cameras ( but of course I won’t be able to use an Apple video cable ). I found a good writeup up on this whole TRRS mess here . To think electrical engineers helped get men on the moon in 1969.