When Difference Matters: Differential Signaling

March 29, 2016 by Bil Herd 21 Comments

We have talked about a whole slew of logic and interconnect technologies including TTL, CMOS and assorted low voltage versions. All of these technologies have in common the fact that they are single-ended, i.e. the signal is measured as a “high” or “low” level above ground.

This is great for simple uses. But when you start talking about speed, distance, or both, the single ended solutions don’t look so good. To step in and carry the torch we have Differential Signalling. This is the “DS” in LVDS, just one of the common standards throughout industry. Let’s take a look at how differential signaling is different from single ended, and what that means for engineers and for users.

Single Ended

Single Ended: TTL, CMOS, LVTTL, Etc.

Single Ended and Sources of Noise

Collectively, standards like TTL, CMOS, and LVTTL are known as Single Ended technologies and they have in common some undesirable attributes, namely that ground noise directly affects the noise margin (the budget for how much noise is tolerable) as well as any induced noise measured to ground directly adds to the overall noise as well.

By making the voltage swing to greater voltages we can make the noise look smaller in proportion but at the expense of speed as it takes more time to make larger voltage swings, especially with the kind of capacitance and inductance we sometimes see.

Differential

Enter Differential Signaling where we use two conductor instead of one. A differential transmitter produces an inverted version of the signal and a non-inverted version and we measure the desired signal strictly between the two instead of to ground. Now ground noise doesn’t count (mostly) and noise induced onto both signal lines gets canceled as we only amplify the difference between the two, we do not amplify anything that is in common such as the noise.

Continue reading “When Difference Matters: Differential Signaling” →

Kestrel Computer Project

March 25, 2016 by Brandon Dunson 29 Comments

Many successful large-scale projects don’t start out large: they start with a small working core and grow out from there. Building a completely open-source personal computer is not a weekend project. This is as much a retelling of events as it is background information leading up to a request for help. You’ll discover that quite a lot of hard work has already been put forth towards the creation of a completely open personal computer.

When I noticed the Kestrel Computer Project had been submitted via the Hackaday tips line I quickly tracked down and contacted [Samuel] and asked a swarm of questions with the excitement of a giddy schoolgirl. Throughout our email conversation I discovered that [Samuel] had largely kept the project under the radar because he enjoyed working on it in his down time as a hobby. Now that the project is approaching the need for hardware design, I posed a question to [Samuel]: “Do you want me to write a short article summarizing years of your work on Kestrel Project?” But before he could reply to that question I followed it up with another: “Better yet [Samuel], how about we tell a more thorough history of the Kestrel Project and ask the Hackaday community for some help bringing the project home!?”
Continue reading “Kestrel Computer Project” →

Crawl, Walk, Run: Planning Your First CPU Design

March 16, 2016 by Al Williams 42 Comments

I’ve worked with a lot of students who want to program computers. In particular, a lot of them want to program games. However, when they find out that after a few weeks of work they won’t be able to create the next version of Skyrim or Halo, they often get disillusioned and move on to other things. When I was a kid, if you could get a text-based Hi-Lo game running, you were a wizard, but clearly the bar is a lot higher than it used to be. Think of the “Karate Kid”–he had to do “wax on, wax off” before he could get to the cool stuff. Same goes for a lot of technical projects, programming or otherwise.

I talk to a lot of people who are interested in CPU design, and I think there’s quite a bit of the same problem here, as well. Today’s commercial CPUs are huge beasts, with sophisticated memory subsystems, instruction interpreters, and superscalar execution. That’s the Skyrim of CPU design. Maybe you should start with something simpler. Sure, you probably want to start learning Verilog or VHDL with even simpler projects. But the gulf between an FPGA PWM generator and a full-blown CPU is pretty daunting.

Continue reading “Crawl, Walk, Run: Planning Your First CPU Design” →

Coleco Chameleon Is A Kickstarter Scam

March 10, 2016 by Will Sweatman 67 Comments

Retro gaming consoles exploded with the introduction of the Raspberry Pi and other similar single-board Linux computers. They all work the same way in that they emulate the original game console hardware with software. The game ROM is then dumped to a file and will play like the original. While this works just fine for the vast majority of us who want to get a dose of nostalgia as we chase the magic 1-up mushroom, gaming purists are not satisfied. They can tell the subtle differences between emulation and real hardware. And this is where our story begins.

Meet the Coleco Chameleon. What appears to be just another run-of-the-mill retro gaming console is not what you think. It has an FPGA core that replicates the actual hardware, to the delight of hardcore retro game enthusiasts around the world. To get it to the masses, they started an ambitious 2 million US dollar Indiegogo campaign, which has unfortunately come to a screeching halt.

Take a close look at the header image. That blue circuit board in there is nothing but an old PCI TV tuning card. To make matters worse, it also appears that their prototype system which was displayed at the Toy Fair in New York was just the guts of an SNES Jr stuffed into their shell.

This scam is clearly busted. However, the idea of reconstructing old gaming console hardware in an FPGA is a viable proposition, and there is demand for such a device from gaming enthusiasts. We can only hope that the owners of the Coleco Chameleon Kickstarter campaign meant well and slipped up trying to meet demand. If they can make a real piece of hardware, it would be welcomed.

Does The World Need An FPGA Arduino?

March 9, 2016 by Elliot Williams 83 Comments

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!

Nessie, The Educational Robot

February 27, 2016 by Bryan Cockfield 6 Comments

At the Lifelong Learning Robotics Laboratory at the Erasmo Da Rotterdam in Italy, robots are (not surprisingly) used to teach all of the fundamentals of robotics. [Alessandro Rossetti] and the students at the lab have been at it for years now, and have finally finished their fifth generation of a robot called Nessie. The big idea is to help teach fundamentals of programming and electronics by building something that actually uses these principles.

The robot is largely 3D printed and uses an FPGA to interact with the physical world through a set of motors and sensors. The robot also uses a Raspberry Pi to hold the robot’s framework. The robot manages the sensors in hardware with readers attached to the CPU AXI bus. The CPU reads their values from memory space, though, so the robot is reported to be quite quick.

The lab is hoping to take their robot to a robotics competition in Bari, Italy. We hope that they perform well there, since we are big fans of any robot that’s designed to teach anyone about robotics and programming. After all, there are robots that help teach STEM in Africa, robots that teach teen girls about robots, and robots that teach everyone.

Icestudio: An Open Source Graphical FPGA Tool

February 23, 2016 by Eric Evenchick 38 Comments

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!]

Continue reading “Icestudio: An Open Source Graphical FPGA Tool” →