Dear Backers,

Let’s start with this extra-exciting screenshot of the exact same thing you saw in the previous update:

Hurray! We haven’t broken anything in the past month. It’s now time for all the software developers to feel schadenfreude toward me, a hardware developer (this update is being written by bunnie). Although my favorite languages are assembly and solder, I’ve come to recognize over time that any serious project that aims to develop a user base is probably 80% software and 20% hardware by effort.

Likewise, 80% of the effort this past month was spent refactoring Xous to a "0.8" release, which could be thought of as an "Alpha" or "EVT" release, depending upon your versioning practices. Up until now, we were sort of glomming things together, seeing where Xous breaks, and patching over the holes with tape and glue. Thanks to a huge effort by Xobs, I feel that most of the major holes in Xous have been patched over, but in the process of getting there we had accrued some technical debt in the application servers. So, I took a pass at cleaning up all the APIs and defining them in a single document. We then went through every single existing server and refactored them to match the specification in the API document.

The upshot of all this is that we have nothing really new or interesting to show you in terms of features, but the code base is much cleaner, more efficient, and easier to maintain. Messages are defined with a single exhaustive enum type, inter-process communications of rich data structures has been refactored into a single xous-ipc crate, logging messages are more informative, and we’re down to zero API "reach-around" hacks (you know, the kind of hack when you’ve defined an API, but you have to reach around it because the API isn’t right). The system consumes about 15% less power in idle and message-passing performance is about 30% faster for rich structures and 100% faster for scalar types, thanks to profound improvements in the threading and process-scheduling infrastructure.

In fact, as our code base matures, it’s my hope that basically every screenshot looks more or less like the one shown here. Ideally, from this point forward, we are streamlining, reducing, simplifying, and improving the existing system, instead of wantonly adding new features just to create the perception of progress. While this kind of work doesn’t give me the same dopamine rush as the low-hanging fruit of a brand-new feature with high demo value, it does represent the sort of methodical, minimalist development culture we are trying to foster around Precursor—a development culture that starts with us setting expectations and priorities.

To that end, we’re using this update to celebrate the fact that we can show you the exact same screen shot as last month, secure in the knowledge that we have added no new bugs and maintained or improved performance and capacity.

All Your Pre-Boot Questions Answered!

We like to think beyond the reset vector, and consider the chain of custody for trust all the way down to the hardware level. In that vein, we’ve written a document that provides a bird’s-eye view of how Precursor gets to running its very first architecturally valid RISC-V instruction. Below is a simplified diagram, from that document, that shows Precursor from a boot-and-provisioning perspective.

As you may already know, an FPGA is a generic "sea of logic" that is shipped in a blank state. This means out of the box, a Precursor has precisely zero RISC-V CPUs and no capability to run code at all. Yet somehow, once you plug power in, we’re promising that the FPGAs magically conjure a couple of RISC-V CPUs out of whole cloth and start running code that was put there…by the firmware fairy?

If you’ve ever been kept up at night wondering if the firmware fairy is real, check out our Pre-boot document for answers. It turns out, there’s no magic to it, and we can all be firmware fairies!

Test Jigs

Although our start date for production has been delayed due to availability issues with Spartan 7 FPGAs, we’re still pushing ahead with our manufacturing and test infrastructure.

We’re exploring a new twist on test-jig hardware. More specifically, previous test-jig configurations that required an external keyboard and monitor have turned out to be surprisingly difficult to maintain in a factory setting. Although we strive to make user-facing products interoperable with the world of potential customer configurations, it feels a bit inefficient to put the same effort into debugging differences in monitor resolutions, overscan, network configurations, and keyboard layouts between factory and development sites, given that both are captive environments.

So, we’re trying out a system that integrates an OLED display and testing buttons directly into the jig itself, while integrating the controller (a Raspberry Pi) tightly with the jig logic. We’re also taking advantage of the fact that production is happening in a South Korean facility with excellent, unfiltered Internet connectivity by parking all of our factory production scripts on GitHub. This means we will be able to update the production jig by pushing to our production repository on GitHub. As a side benefit, users can also gain some traceability and visibility into the test and provisioning process of their devices by checking the history of our test jig repository commits.

EMC Testing Preparations

Although vaccines are being rolled out, international travel restrictions have not yet loosened significantly. 14-day quarantines are still the norm, and even people in a countries like Singapore—with approximately zero community cases of COVID-19 per day—are finding it difficult to get permission to enter China. As a result, our plans for EMC-compliance testing (which is how we will obtain FCC and CE certificates for active radio transmitters) have been thrown into disarray. According to our original time line, I should have been on my way to to China right about now so that I could be on-site at the testing facility. (In case you’re wondering why I would do that to myself, bear in mind that testing facilities in China are at least $20-$30k cheaper than they are elsewhere…)

To work around these circumstances, we’ve developed a custom Xous application capable of driving the Wi-Fi subsystem in all of its test modes, modulation types, and channels. This will allow an engineer from our contract manufacturing team in China to configure Precursor for tests by typing a few simple commands on the keyboard of the Precursor under test. This much simpler than our original plan, which required me to be on site so that I could modify Python scripts running on a laptop so that the laptop could reconfigure the Precursor under test.

Thanks to the stabilization of Xous 0.8, we were able to crank out that custom Xous app, and now we’re just waiting to receive approval of our proposed testing procedure from the China side, at which point we will mail the prototypes to the testing facility. Cross-border commerce with China has only become more difficult with the pandemic, which has brought stiffer customs enforcement and a sometimes "maximalist" interpretation of tariff and import restrictions. As a result, we’re trying to minimize the number of times we need to mail prototypes between Singapore and China before receiving the certifications we need to ship production units into the regulatory regimes of their respective backers. The good news is that, with production delayed by 3-4 months, we’ve been able to absorb these setbacks without too many additional negative consequences.

Example of a conducted-emissions compliance signal from Precursor: 802.11g OFDM modulation at 54 Mbps on channel 6

Production Delay Update

On the topic of our manufacturing schedule, we’ve been exploring options to pull in production, including the possibility of buying a limited quantity of slightly less capable Xilinx FPGAs at triple the cost. Unfortunately, all such "solutions" we’ve identified so far would either have compromised production quality or arbitrarily disadvantaged some portion of our backers, so we’re holding the line for now. Production is currently set to begin in November, and we’re praying that our original FPGA order does not get delayed further.

That being said, we’re continuing to press on other components that could be available earlier, such as the keyboard and the battery, to ensure that we don’t have a shortage if supply chain woes metastasize beyond semiconductors. We are seeing a worrying lack of capacity in all parts of the supply chain, and our concerns are only exacerbated by our inability to visit vendors in person and by the deep backlog of large orders that is discouraging manufacturers from spending time on smaller ones.

Although top economists routinely assure us that the huge amount of stimulus money injected into the world economy will not result in inflation, I can say first-hand and unequivocally that, as far as electronics production goes, the supply chain cannot ramp production capability at a rate commensurate with the increased demand resulting from the stimulus. Prices of raw material are going up across the board. Maybe economists can’t call this phenomenon inflation because it’s not immediately impacting the shelf price of finished goods, but most electronics aren’t pure commodities like oil (for which prices at the pump will rise within hours of a supply-chain incident). Whatever you call it, it’s definitely causing immediate difficulties for small players like us.

That’s it for our latest backer update! We’re looking forward to mailing prototypes off to our EMC test site and hoping to get results back quickly. Good news will mean that we’ve met the relevant emissions and compliance standards and are well on our way to certification; bad news will mean that we have a bit more work do. In the meantime, we’ll continue burrowing deeply into Xous development to improve core functionality, including key user-experience features like power management and firmware that will help position Precursor as more than just a development platform for power users.