They’re back! The San Francisco autonomous vehicle hijinks, that is, as Waymo’s fleet of driverless cars recently took up the fun new hobby of honking their horns in the wee hours of the morning. Meat-based neighbors of a Waymo parking lot in the South Market neighborhood took offense at the fleet of autonomous vehicles sounding off at 4:00 AM as they shuffled themselves around in the parking lot in a slow-motion ballet of undetermined purpose. The horn-honking is apparently by design, as the cars are programmed to tootle their horn trumpets melodiously if they detect another vehicle backing up into them. That’s understandable; we’ve tootled ourselves under these conditions, with vigor, even. But when the parking lot is full of cars that (presumably) can’t hear the honking and (also presumably) know where the other driverless vehicles are as well as their intent, what’s the point? Luckily, Waymo is on the case, as they issued a fix to keep the peace. Unfortunately, it sounds like the fix is just to geofence the lot and inhibit honking there, which seems like just a band-aid to us.
fpga546 Articles
A Really Low Level Guide To Doing Ethernet On An FPGA
With so much of our day-to-day networking done wirelessly these days, it can be easy to forget about Ethernet. But it’s a useful standard and can be a great way to add a reliable high-throughput network link to your projects. To that end, [Robert Feranec] and [Stacy Rieck] whipped up a tutorial on how to work with Ethernet on FPGAs.
As [Robert] explains, “many people would like to transfer data from FPGA boards to somewhere else.” That basically sums up why you might be interested in doing this. The duo spend over an hour stepping through doing Ethernet at a very low level, without using pre-existing IP blocks to make it easier. The video explains the basic architecture right down to the physical pins on the device and what they do, all the way up to the logic blocks inside the device that do all the protocol work.
If you just want to get data off an embedded project, you can always pull in some existing libraries to do the job. But if you want to really understand Ethernet, this is a great place to start. There’s no better way to learn than doing it yourself. Files are on GitHub for the curious. Continue reading “A Really Low Level Guide To Doing Ethernet On An FPGA”
What Is SystemVerilog, Really?
[Mark] starts a post from a bit ago with: “… maybe you have also heard that SystemVerilog is simply an extension of Verilog, focused on testing and verification.” This is both true and false, depending on how you look at it. [Mark] then explains what the differences are. It’s a good read if you are Verilog fluent, but just dip your toe into SystemVerilog.
Part of the confusion is that until 2009, there were two different things: Verilog and SystemVerilog. However, the SystemVerilog 2009 specification incorporates both languages, so modern Verilog is SystemVerilog and vice versa.
Making USB Blaster Clones Work For Linux
The last time we checked in with [Downtown Doug Brown], he had some cheap Altera USB Blaster clones that didn’t want to work under Linux. The trick at that time was to change the device’s 24 MHz clock to 12 MHz. This month, he’s found some different ones that don’t work, but now the clock change doesn’t work. What’s the problem?
He also picked up a Terasic clone, which does work on Linux and is considered, according to [Doug], the best of the clones. The units were superficially similar. So what follows is a lot of USB tracing and dumping of the CPLD chip’s configuration.
Tiny Tapeout 4: A PWM Clone Of Covox Speech Thing
Tiny Tapout is an interesting project, leveraging the power of cloud computing and collaborative purchasing to make the mysterious art of IC design more accessible for hardware hackers. [Yeo Kheng Meng] is one such hacker, and they have produced their very first custom IC for use with their retrocomputing efforts. As they lament, they left it a little late for the shuttle run submission deadline, so they came up with a very simple project with the equivalent behaviour of the Covox Speech Thing, which is just a basic R-2R ladder DAC hanging from a PC parallel port.

The plan was to capture an 8-bit input bus and compare it against a free-running counter. If the input value is larger than the counter, the output goes high; otherwise, it goes low. This produces a PWM waveform representing the input value. Following the digital output with an RC low-pass filter will generate an analogue representation. It’s all very simple stuff. A few details to contend with are specific to Tiny Tapout, such as taking note of the enable and global resets. These are passed down from the chip-level wrapper to indicate when your design has control of the physical IOs and is selected for operation. [Yeo] noticed that the GitHub post-synthesis simulation failed due to not taking note of the reset condition and initialising those pesky flip-flops.
After throwing the design down onto a Mimas A7 Artix 7 FPGA board for a quick test, data sent from a parallel port-connected PC popped out as a PWM waveform as expected, and some test audio could be played. Whilst it may be true that you don’t have to prototype on an FPGA, and some would argue that it’s a lot of extra effort for many cases, without a good quality graphical simulation and robust testbench, you’re practically working blind. And that’s not how working chips get made.
If you want to read into Tiny Tapeout some more, then we’ve a quick guide for that. Or, perhaps hear it direct from the team instead?
Continue reading “Tiny Tapeout 4: A PWM Clone Of Covox Speech Thing”
Is That A Large Smartwatch? Or A Tiny Cray?
While we aren’t typically put off by a large wristwatch, we were taken a bit aback by [Chris Fenton]’s latest timepiece — if you can call it that. It’s actually a 1/25th-scale Cray C90 worn as a wristwatch. The whole thing started with [Chris] trying to build a Cray in Verilog. He started with a Cray-1 but then moved to a Cray X-MP, which is essentially a Cray-1 with two extra address bits. Then he expanded it to 32 bits, which makes it a Cray Y-MP/C90/J90 core. As he puts it, “If you wanted something practical, go read someone else’s blog.”
The watch emulates a Cray C916 and uses a round OLED display on the top. While the move from 22 to 32 address bits sounds outdated, keep in mind the Cray addresses 64-bit words exclusively, so we’re talking access to 32 gigabytes of memory. The hardware consists of an off-the-shelf FPGA board and a Teensy microcontroller to handle mundane tasks like driving the OLED display and booting the main CPU. Interestingly, the actual Cray 1A used Data General computers for a similar task.
Of course, any supercomputer needs a super program, so [Chris] uses the screen to display a full simulation of Jupiter and 63 of its moons. The Cray excels at programs like this because of its vector processing abilities. The whole program is 127 words long and sustains 40 MFLOPs. Of course, that means to read the current time, you need to know where Jupiter’s moons are at all times so you can match it with the display. He did warn us this would not be practical.
While the Cray wouldn’t qualify as a supercomputer today, we love learning about what was state-of-the-art not that long ago. Cray was named, of course, after [Seymour Cray] who had earlier designed the Univac 1103, several iconic CDC computers, and the Cray computers, of course.
Comparing X86 And 68000 In An FPGA
[Michael Kohn] started programming on the Motorola 68000 architecture and then, for work reasons, moved over to the Intel x86 and was not exactly pleased by the latter chip’s perceived shortcomings. In the ’80s, the 68000 was a very popular chip, powering everything from personal computers to arcade machines, and looking at its architecture and ease of programming, you can see why this was.
Fast-forward a few years, and [Michael] decided to implement both cores in an FPGA to compare real applications, you know, for science. As an extra bonus, he also compares the performance of a minimal RISC-V implementation on the same hardware, taken from an earlier RISC-V project (which you should also check out !)
Utilizing their ‘Java Grinder’ application (also pretty awesome, especially the retro console support), a simple Mandelbrot fractal generator was used as a non-trivial workload to produce binaries for each architecture, and the result was timed. Unsurprisingly, for CISC architectures, the 68000 and x86 code sizes were practically identical and significantly smaller than the equivalent RISC-V. Still, looking at the execution times, the 68000 beat the x86 hands down, with the newer RISC-V speeding along to take pole position. [Michael] admits that these implementations are minimal, with no pipelining, so they could be sped up a little.
Also, it’s not a totally fair race. As you’ll note from the RISC-V implementation, there was a custom RISC-V instruction implemented to perform the Mandelbrot generator’s iterator. This computes the complex operation Z = Z2 + C, which, as fellow fractal nerds will know, is where a Mandelbrot generator spends nearly all the compute time. We suspect that’s the real reason RISC-V came out on top.
If actual hardware is more your cup of tea, you could build a minimal 68k system pretty easily, provided you can find the chips. The current ubiquitous x86 architecture, as odd as it started out, is here to stay for the foreseeable future, so you’d just better get comfortable with it!