I recently had the chance to visit Belgrade and take part in the Hackaday | Belgrade conference. Whenever I travel, I like to make some extra field trips to explore the area. This Serbian trip included a tour of electronics manufacturing, some excellent museums, and a startup that is weaving FPGAs into servers and PCIe cards.
What would you get it you mashed up an FPGA and an Arduino? An FPGA development board with far too few output pins? Or a board in the form-factor of Arduino that’s impossible to program?
Fortunately, the ICEZUM Alhambra looks like it’s avoided these pitfalls, at least for the most part. It’s based on the Lattice iCE40 FPGA, which we’ve covered previously a number of times because of its cheap development boards and open-source development flow. Indeed, we were wondering what the BQ folks were up to when they were working on an easy-to-use GUI for the FPGA family. Now we know — it’s the support software for an FPGA “Arduino”.
The Alhambra board itself looks to be Arduino-compatible, with the horrible gap between the rows on the left-hand-side and all, so it will work with your existing shields. But they’ve also doubled them with pinheaders in a more hacker-friendly layout: SVG — signal, voltage, ground. This is great for attaching small, powered sensors using a three-wire cable like the one that you use for servos. (Hackaday.io has two Arduino clones using SVG pinouts: in SMT and DIP formats.)
The iCE40 FPGA has 144 pins, so you’re probably asking yourself where they all end up, and frankly, so are we. There are eight user LEDs on the board, plus the 28 I/O pins that end in pinheaders. That leaves around a hundred potential I/Os unaccounted-for. One of the main attractions of FPGAs in our book is the tremendous availability of fast I/Os. Still, it’s more I/O than you get on a plain-vanilla Arduino, so we’re not complaining too loudly. Sometimes simplicity is a virtue. Everything’s up on GitHub, but not yet ported to KiCad, so you can tweak the hardware if you’ve got a copy of Altium.
We’ve been seeing FPGA projects popping up all over, and with the open-source toolchains making them more accessible, we wonder if they will get mainstreamed; the lure of reconfigurable hardware is just so strong. Putting an FPGA into an Arduino-compatible form-factor and backing it with an open GUI is an interesting idea. This project is clearly in its very early stages, but we can’t wait to see how it shakes out. If anyone gets their hands on these boards, let us know, OK?
Thanks [RS] for the tip!
If you’ve ever worked with FPGAs, you’ve dealt with the massive IDEs provided by the vendors. Xilinx’s ISE takes about 6 gigabytes, and Altera’s Quartus clocks in at over 10 gigs. That’s a lot of downloading proprietary software just to make an LED blink.
[Jesús Arroyo]’s Icestudio is a new, graphical tool that lets you generate Verilog code from block diagrams and run it on the Lattice Semi iCEstick development board. A drag and drop interface lets you connect IOs, logic gates, dividers, and other elements. Once your block diagram is ready, a single button press downloads the code to the iCEstick.
Under the hood, Icestudio uses IceStorm, which we’ve discussed on HaD in the past, including this great talk by [Clifford], Icestorm’s lead. For the GUI, Icestudio uses nw.js, which spits out JSON based on the block diagram. This JSON is converted into a Verilog file and a PCF file. The Verilog is used to create the logic on the FPGA, and the PCF is used to define the pin configuration for the device. Clicking on selected modules reveals the generated Verilog if you want to know what’s actually going on.
It’s experimental, but this looks like a neat way to get started on FPGAs without learning a new language or downloading many gigs of toolchains. We’re hoping Icestudio continues to grow into a useful tool for education and FPGA development. A demo follows after the break.
[Thanks to Nils for the tip!]
Sorting. It’s a classic problem that’s been studied for decades, and it’s a great first step towards “thinking algorithmically.” Over the years, a handful of sorting algorithms have emerged, each characterizable by it’s asymptotic order, a measure of how much longer an algorithm takes as the problem size gets bigger. While all sorting algorithms take longer to complete the more elements that must be sorted, some are slower than others.
For a sorter like bubble sort, the time grows quadradically longer for a linear increase in the number of inputs; it’s of order
O(N²).With a faster sorter like merge-sort, which is
O(N*log(N)), the time required grows far less quickly as the problem size gets bigger. Since sorting is a bit old-hat among many folks here, and since
O(N*log(N)) seems to be the generally-accepted baseline for top speed with a single core, I thought I’d pop the question: can we go faster?
In short — yes, we can! In fact, I’ll claim that we can sort in linear time, i.e a running time of
O(N). There’s a catch, though: to achieve linear time, we’ll need to build some custom hardware to help us out. In this post, I’ll unfold the problem of sorting in parallel, and then I”ll take us through a linear-time solution that we can synthesize at home on an FPGA.
Need to cut to the chase? Check out the full solution implemented in SystemVerilog on GitHub. I’ve wrapped it inside an SPI communication layer so that we can play with it using an everyday microcontroller.
To understand how it works, join us as we embark on an adventure in designing algorithms for hardware. If you’re used to thinking of programming in a stepwise fashion for a CPU, it’s time to get out your thinking cap!
One of the big problems in detecting malware is that there are so many different forms of the same malicious code. This problem of polymorphism is what led Rick Wesson to develop icewater, a clustering technique that identifies malware.
Presented at Shmoocon 2016, the icewater project is a new way to process and filter the vast number of samples one finds on the Internet. Processing 300,000 new samples a day to determine if they have polymorphic malware in them is a daunting task. The approach used here is to create a fingerprint from each binary sample by using a space-filling curve. Polymorphism will change a lot of the bits in each sample, but as with human fingerprints, patterns are still present in this binary fingerprints that indicate the sample is a variation on a previously known object.
Continue reading “Shmoocon 2016: GPUs and FPGAs to Better Detect Malware”
The Manchester Baby seems simple today. A 32-bit machine with 32 words of storage. It wasn’t meant to be a computer, though, but a test bed for the new Williams tube storage device. However, in 1948, it executed stored programs at about 1,100 instructions per second. The success of the machine led to a series of computers at Manchester University and finally to the first commercially available computer, the Ferranti Mark I.
[Dave] is lucky enough to volunteer to demonstrate the Baby replica at Machester’s Museum of Science Industry. He wanted his own Baby, so he used a Xilinx FPGA board to build a replica Baby named BabyBaby. Although it runs at the same speed as the original, it is–mercifully–much smaller than the real machine.
When [iliasam] needed an Ethernet connection, he decided to see how much of the network interface he could put in the FPGA logic. Turns out that for 10 Base-T, he managed to get quite a bit inside the FPGA. His original post is in Russian, but automatic translation makes a passable attempt at converting to English.
This is a classic trade off all FPGA designers face: how much external logic do you use for a particular design. For example, do you add memory to the PCB, or use FPGA resources as memory? Each has its advantages and disadvantages (that’s why it is a trade off). However, if you are trying to keep things cheap, slashing external circuitry is often the way to go.