Tag Archives: fpga

APP NOTE: make an analog to digital converter using FPGA pins

via Dangerous Prototypes

A differential pin pair can be used as a comparator to create a basic ADC. This app note shows how to design a low speed (1 KHz) and “high” speed (50 Khz) ADC technique using only FPGA pins, a resistor and a capacitor. Regardless of whether we ever use this technique, it is illuminating to understand how SAR and Delta Sigma ADCs are constructed:

A simple Analog to Digital Converter can be constructed by adding a small RC circuit to an LVDS input on an FPGA or CPLD…. The LVDS input will act as a simple analog comparator and will output a digital ‘1’ if the Analog Input voltage is higher than the voltage from the RC network. By changing the voltage on the input to the RC circuit, the LVDS comparator can be used to analyze the Analog Input voltage to create an accurate digital representation… A low frequency signal can be processed using a simple Successive Approximation Register… A higher frequency implementation…can be implemented using a Delta Sigma Modulator function, which consists of a sampling register and a Cascade Integrated Comb (CIC) Filter.

Lattice Semiconductor

Via ferdinandk in the forum.

BUS PIRATE: pipelined and non-pipelined commands

via Dangerous Prototypes

Bus Pirate prototype Ultra v1b uses an FPGA to process commands sent through a FIFO buffer to a state machine. Pipelined commands can be loaded into the FIFO and executed by the state machine with per-clock repeatability. Non-pipelined commands halt the state machine while the MCU takes over to perform the command, the delay is unpredictable and depends on many factors such as USB operations the MCU may be servicing.

These commands are currently pipelined and handled in the FPGA by the state machine:

  • Delays (ms, us)
  • Bus reads
  • Bus writes
  • Pin read/write/direction

These commands can be pipelined, but are currently handled in registers:

  • PWM
  • Frequency measurement

These commands will be pipelined in v1c and later:

  • ADC reads (on any pin, Vout)

These commands could be pipelined with some hardware updates:

  • Pull-up resistors toggle
  • Power supply enable
  • Power supply margining (by adding an external DAC)

These commands cannot be pipelined because they happen outside the FPGA:

  • Mode change (reloads the FPGA)
  • Reset
  • Jump to bootloader
  • Self-test (involves tests on the MCU and FPGA)

There are also mode macros to consider, which probably need to be a combination of pipelined commands and non-pipelined commands. This week we’ll choose an external DAC and add it to the board.

App note: FPGA power supply considerations

via Dangerous Prototypes

App note from Vishay Siliconix, giving us tips on powering FPGAs. Link here (PDF)

An FPGA is a device that offers many logic elements – up to 1 million gates in a single device at this writing – as well as other functionality such as transceivers, PLLs, and MAC units for complex processing. FPGAs are becoming very powerful, and the need to power the devices effectively is a key, if often underestimated, part of the design. A straightforward power supply design process can significantly reduce the number of required design iterations for the OEM designer.

PROTOTYPE: Bus Pirate “Ultra” v1b

via Dangerous Prototypes

Today we finished stuffing the first Bus Pirate “Ultra” v1b board. This includes the updates we posted this week, and a few other improvements from v1a:

The new power supply and voltage measurement concept are both tested and working on the new hardware. The new USB C connector is extremely solid and is a dream to solder, we’ll never look back.

Next we’ll work on getting the display going. So far it powers up and no smoke escapes.

Eagle files for v1b are in the git repo. Follow development of v1c in the forum.

PROTOTYPE: Bus Pirate/Logic Analyzer with Ice40 FPGA

via Dangerous Prototypes

Bus Pirate “Ultra” taps an iCE40 FPGA to power a combined Bus Pirate interface and logic analyzer that is infinity hackable. Previous Bus Pirates relied on the hardware peripherals available in a microcontroller, which vary in features and have the occasional bug. With an FPGA we can implement practically any peripheral with all the fixes and hacks we want! SPI, I2C, UART, CAN? Yes! Master or slave? Both! Complex frequency generator? Yup! Full featured JTAG debugger? Don’t see why not!

A big STM32F103ZE (1) microcontroller connects to an iCE40HX4K FPGA (2) through a 16bit bus that can move a ton of data. The fully buffered interface (3) is capable of high-speed signaling from 1.2volt to 5volts. 128Mbit of RAM (4) powers a logic analyzer with a potential maximum speed over 200MSPS. A 32Mbit flash chip (5) stores up to 30 bitstreams with different features that can be loaded into the FPGA by the microcontroller.

This post covers our most recent hacks to the Bus Pirate, created with these goals in mind:

  • Peripherals that work and can be hacked
  • Direct interfacing at all common voltage levels
  • Real-speed bus activity
  • Built-in logic analyzer
  • Plenty of space for updates

Continue below to read about the design, or jump to the forum to see the bleeding edge.

The Bus Pirate is a tool that talks to microchips in various protocols such as I2C and SPI. Get to know a chip first, then dive into the code. It’s been ten years since Seeed Studio did the original Bus Pirate production, and now we’re hacking new hardware for the next decade.

The Bus Pirate v3.x PCB is extremely simple due to a feature in PIC24FJ microcontrollers called Peripheral Pin Select. PPS allows most major peripherals (UART, SPI, PWM, counters, etc) to be assigned to almost any IO pin. Five PIC pins provide all the functionality for all the supported protocols.

Last year Sjaak did a deep dive on an STM32 ARM-based Bus Pirate. Unlike the PIC24FJ, all the hardware peripherals are fixed to certain pins that have to be tied together. All the interconnections make a rat nest of traces.

Once we got familiar with the STM32 it was obvious that the optimizations for low-power and DMA were going to be a real pain to work around. Take for example the I2C peripheral: you need to tell it when the transfer is ending at least one byte in advance. This is great if you’re setting up repetitive transfers using DMA in low-power modes, but the Bus Pirate is for hacking and “human scale” interactions. We faced two bad options: send a ghost byte when we can’t infer the end of a transfer, or use software I2C libraries. There’s really no point in having this much chip and then resorting to bit-banging!

Bus Pirate Ultra

We shelved the project to lick our wounds and come up with some new design goals:

  1. Peripherals that work and can be hacked
  2. Direct interfacing at all common voltage levels
  3. Real-speed bus activity
  4. Built-in logic analyzer
  5. Plenty of space for updates

Peripherals that work and can be hacked

The bottom line is we need hackable peripherals. From the I2C hardware bug in the B2 revision of the 24FJ64GA002, to the tricky implementation of peripherals in modern ARM chips, fixed silicon peripherals are a huge limitation. An FPGA is one answer.

In this design we use a Lattice ICE40 FPGA to implement bus protocol peripherals. Bugs can be squashed and features can be added with a simple bitstream update.

Source: ST app note AN2784 page 6.

The FPGA is connected to the STM32 static memory controller (FSMC) using a 16bit SRAM-like bus with 6 address bits. That’s a lot of bandwidth to push and pull data, and will eventually drastically speed up binary operations like dumping the contents of flash chips with FLASHROM.

An FPGA has always been the next logical step for the Bus Pirate, but bloated “Webpacks” and vendor tools under restrictive licenses are not hacker friendly. Fortunately, IceStorm gives us a free, open, and fast tool chain for the ICE40 FPGA.

Direct interfacing from 1.2 to 5volts

Previous Bus Pirates could interface with chips directly at 3.3volts, and from ~2volts to 5volts using pull-up resistors and open drain pin outputs. This works well for slow experimentation, but an open drain bus has real speed limitations. We want to interface directly at any common voltage.

Source: Nexperia 74LVC1T45 datasheet page 1.

74LVC1T45 is a bi-directional buffer used in cheap ARM programmer clones sold on Taobao. This buffer is a bulldozer, capable of 420Mbps at 5volts to 60Mbps at 1.5volts. It has a partial power-down feature that disables the outputs when no power supply is present to prevent backflow current into the FPGA or the device under test. TI, Nexperia and Diodes INC all manufacture a version of the 74LVC1T45. The Nexperia version works from 1.2volts to 5.0volts, while the others have a 1.65volt minimum.

74LVC1T45 has two control pins: direction and input/output. In a fixed direction bus like SPI or asynchronous serial this buffer can be put in front of any common microcontroller peripheral. However, it’s a dead end for a bidirectional bus like I2C or 1Wire because the peripheral would need to somehow manage the direction pin on a bit by bit basis. Direction handling is not a feature we’ve ever encountered on a microcontroller peripheral. The key here is to implement our own peripherals in the FPGA, and use the FPGA to manage the direction pin.

Source: Nexperia 74LVC1G07 datasheet page 1.

A 74LVC1G07 open drain output buffer is paired with each 74LVC1T45. It is also 5volt tolerant and has partial power down protection. Open drain output could be done by switching the direction pin of the 74LVC1T45, however it requires attention to timing to avoid bus contention. It’s so much easier to add a dedicated open drain driver chip.

Real-speed bus activity

At our very first New York Maker Fair (RIP) we had the chance to meet one of our maker heroes at an after party. We introduced ourselves and Maker Hero replied “The Bus Pirate is too slow” and walked away. It was crushing, but it is accurate. The Bus Pirate is slow in several ways:

  1. It is slow in terms of maximum bus speeds from the PIC running at 16MIPS
  2. It is slow in terms of time between each bus action. For each read/write/whatever the Bus Pirate sits and spits out text to the serial terminal. On a logic analyzer, as shown above, there is a very obvious delay between each command
  3. USB CDC (virtual serial port) is super easy to use, but it is slow and antiquated

Bus speeds can be increased substantially with a fast-clocked FPGA. We used the FPGA block RAM to create a bidirectional FIFO command queue. The STM32 MCU fills the command queue, then the FPGA drives the bus signaling without any delays to handle the terminal text. The MCU reads from the FPGA output queue and spits out text from a low priority background process. The fast, continuous bus activity from the FPGA is more in line with what really happens in implemented circuits.

libopencm3, the open source peripheral library we’re using with the STM32, supports multiple USB endpoints. We’ll add a USB bulk transfer endpoint that should drastically speed up binary operations like chip programming, flash read and writes, and display interfacing.

Built-in logic analyzer

A built-in logic analyzer is a top wish list item and has appeared in various prototypes in the past. While the Bus Pirate and a datasheet are enough to get a lot of chips going, there’s a decent chance we haul out the logic analyzer to get a good look at whats happening on the wires. A built-in logic analyzer that captures each command in real time makes debugging a dream.

A simple serial SRAM logic analyzer like the Logic Shrimp and Logic Pirate are quite cheap and easy to implement with PIC18/24/30 timers. Our attempt to do the same with the STM32 was less successful, but now we can drive it from the FPGA.

To ensure that the logic analyzer is reading the actual pin states, it gets a dedicated 74LVC573 input buffer that attaches to the IO header after the signal buffers.

Bus Terminal is a little Qt hack for debugging the logic analyzer and uploading FPGA bitstreams. Eventually we’ll target sigrok with a USB bulk transfer interface and driver.

Plenty of space for updates

The biggest issue we faced with Bus Pirate v3 was the lack of space. Endlessly optimizing strings to eek out a few more bytes is annoying. Eventually we had to split the firmware into multiple parts with different features, a nightmare for users.

We want to hack and hack and hack for years in the future without running into space limitations. The huge STM32 chip has a generous amount of flash that should be sufficient for years of development.

The FPGA is another possible space crunch. Instead of the FPGA loading it’s own bitstream like the Logic Sniffer design, we used a big 32Mbit (or 64Mbit) flash chip to store multiple bitstreams in a simple file system. The STM32 loads the correct bitstream into the FPGA for each bus protocol. Bitstreams for the ICE40 4HK chip are about 135K max, so 32Mbit of flash should hold around 30 bitstreams with different features.

Hardware, firmware, software, HDL

Taking it further

The v1a board shown here was a good proof of concept, and several major potential improvements became obvious after the build. Next week we’ll post about our updates to the on-board power supplies, voltage/ADC probe and the pull-up resistors. We’re also working on a pinout label using a high-resolution IPS LCD.

Check out the forum if you’d like to skip ahead and see our latest revisions.