The HDMI taper turns out to be a red herring, an alternative approach is needed; An anonymous sponsor donates a ZC706 for developing a libre 64-bit RISC-V SoC.

The Klopfenstein Taper

So, Richard, who has been busy enjoying Christmas Carol Choir Concert Capers, was, as previously mentioned, able to finish off enough of the taper design concept so that I could actually begin implementing it. I got quite a long way, and was having a lot of fun: I’d been meaning to write a parser for the ASCII file-format of the proprietary CAD program I’m using, for some time. You can read all about that, including pretty pictures, here.

That was planned as its own update. There’s a reason why that didn’t go out: after all this time, Richard took a step back, had a bit of a think, and worked out that the taper isn’t actually necessary! Richard worked out that an HDMI 1.4 signal’s quarter wavelength is, at the 3 GHz maximum frequency of 1920x1080p60, 25 mm worth of track. and that’s just about within acceptable bounds, given that the tracks involved here are so short. The high-level overview of the path is as follows:

• the transmission end is 100 ohms
• the tracks are near-as-damnit 100 ohms up until the ESD component

(by a keepout of 15 mil)

• through the ESD component(s) there's not enough space to maintain

100 ohms (to a GND keepout)

• likewise the connector
• the cable is 100 ohms
• the receiving end is supposed to be 100 ohms

So, what he said was, although it would be great to have the taper coming down to 50 ohms onto the ESD components, you can’t taper BACK OUT to 100 ohms on the connector because there’s simply not enough space to do so. Therefore… just "put up with" the signal bounces, given that it’s well under a quarter wavelength there won’t actually be any "harm" done to the signal integrity.

Instead, then, the idea he came up with is to try to increase the impedance of the differential-pairs at the ESD component and on the connector. Ordinarily this would be achieved by increasing the (horizontal) distance away from the GND plane, widening the gap. That simply can’t be done horizontally… but it can be done vertically. So the plan is to make a hole in the immediate layers below those components (layers 2 and 5), as long as there happens to be complete ground planes on layers 3 and 4 (which there are). In this way, despite the tracks being very close together as they go through the ESD component and onto the connector (with the pins only being 0.2 mm wide and 0.2,mm apart), the impedance will be closer to 100 ohms, layers 3 and 4 acting as GND, and everything should be hunky-dory.

… and I was really enjoying making useful pretty lines programmatically…

If you’d like to see what’s going on you can follow the conversation on the mailing list.

The Intriguing Possibility of a RISC-V 64-bit SoC

It was five years ago when I first publicly raised the idea of doing a fully libre, commercial-grade SoC. Commercial-grade being: it’s not just a toy, or a research project, or something that only about 5,000 people who "hold dear to the Free Software One True Way" would love to have. We have to be realistic here: if you’re going to make a processor for goodness sake make sure it’s one that will sell in the tens of millions of units minimum, and right now that means at the very least quad core, at least 1.5 GHz, capable of decent video playback, capable of some 3D graphics acceleration, has good-to-really-good software support to make it easy for ODMs to put it into production, and a mass-volume price that stomps all over the competition.

The original processor that was to be done back in 2012 was a collaborative effort with a company named ICubeCorp. ICubeCorp was founded by an engineer who worked his way through SGI Labs, ATI, AMD and NVidia, so they really knew their stuff and came up with a hybrid processor CPU/GPU that would compile standard Mesa3D and standard ffmpeg source code that performed at a similar level as you’d normally expect from a dedicated GPU or VPU, consuming far less power to do so. Unfortunately… the investor that we found was mis-advised by an ill-informed associate with no experience in the silicon industry, and the whole deal fell through.

Fast-forward to 2017 and we have RISC-V, we have the ORSOC Graphics Accelerator Project, we have MIAOU, and a ton of other critical pieces of the puzzle - all of them entirely libre licensed - that would make up our proposed stonking honking bit of kit.

Here’s the real kicker: whereas eight to ten years ago, if you wanted to make a processor you had to have or seek funding of somewhere well north of \$30 million USD, anyone with \$500 (yes, really: that’s \$0.5k not $0.5 million) can grab themselves a zedboard, download some source code, and design themselves a fully functioning SoC. There’s ZipCPU, a RISC-V compatible design by an interesting Russian fellow, and dozens more if you look on OpenCores and other places.

So, after publishing the pinout design and analysis for a proposed 290-pin SoC I was pleasantly surprised to have been contacted by an anonymous sponsor who asked, "what would I need to get this made?" Short version: the zc706 FPGA developer board arrived a few days ago and I managed to follow these extremely good instructions pretty much to the letter and got a first boot, yesterday:

That may not look terribly exciting, but behind the scenes, my 16 GB 2400 MHz DDR4 "oodles-of-RAM and Raw Power" quad-core, 3.6 GHz, i7 gaming laptop underwent a minor meltdown running the proprietary FPGA synthesis software, locking up the mouse and keyboard solid for a scary few minutes at one point, load average climbing well over 12, in order to generate the 64-bit processor core running that pre-compiled linux kernel shown, boringly, in that screenshot.

It’s all rather odd. Whilst I have a background and training in electronics, and could (and quite happily have, with assistance from a friend guiding me) design an ASIC at the gate level of NAND and NOR gates, I have absolutely no prior experience with Verilog, VHDL, or FPGAs, yet thanks to some encouragement and prompting from the arm-netbook mailing list a few short weeks ago, I seem to have ended up with an extraordinarily powerful and empowering piece of electronics, along with the responsibility and duty to, well… actually do something with it.

Calling All Libre FPGA, Verilog, and VHDL Design Experts

From the design analysis, the specification is actually very clear, making this more of an integration task than a design task. Only three major pieces are missing:

• A DDR3 RAM PHY (believe it or not there actually does exist a

libre DDR3 controller implementation)

• A GPIO "pinmux" which is well within even my generally broad

expertise to track down and piece together from online Verilog tutorials

• An implementation of "FlexBus" (similar to the well-known ATI / MCU

/ 80186 bus) which is known from VME and Motorola 68000 days: this is definitely outside of my expertise to piece together

All the rest - amazingly - has been tracked down. An AXI-to-Wishbone Bridge (to minimise the amount of changes needed to be made), PWM, I2C, SD/MMC, quad SPI, RGB/TTL, and ULPI (for USB2 and USB-OTG). I even happen to have, from working with ICubeCorp five years ago, a full GPLv2 compliant linux kernel driver for the OpenCores RGB/TTL LCD/VGA hard macro which will save a huge amount of time.

What I don’t have is a clue as to how to piece all these things together and link them to a Scala "Tile" properly, so that memory-mapped IO and DMA will all work. Yes there are various examples, such as this one, which shows how to make a memory-mapped PWM peripheral… but how do you link in pre-existing VHD and Verilog? I could look at how Sergey has done it but his work is for a KC405 and I have a ZC706, and he’s added them via (a Berkeley implementation of AXI4) and I don’t yet have the experience to understand quite how he did it.

In short, there are too many unknowns and it’s a heck of a lot of work which, whilst in theory I could do (eventually), really I simply should not be tackling this on my own anyway. All that aside, it’s too exciting not to invite other people to get involved. Therefore, if there is anyone out there who would love to be part of a team, working entirely to software libre principles and practices, to create and bring to a mass-volume market a truly libre RISC-V 64-bit quad-core mobile-class SoC, do get in touch and we’ll work something out.

Priorities

So, to reiterate clearly, as mentioned in the previous update: I remain 100% committed to fulfilling the EOMA68 campaign. That’s the top priority. However, as clearly outlined, again, in the previous update: the remaining funds from this campaign are no longer sufficient to cover living expenses. Logically, plain and simple: that means, in turn, that in order to fulfil the promises that I have made, I must find alternative projects or contracts that bring in extra income (supporting the promises that I have already made, in some way). If you know of anything or anyone that could benefit from my expertise, if you know of a way to fund these projects, in ways that preferably actively support this campaign, do get in touch. Your support appreciated.