AMA with Jeff Garzik and Jeff Dionne

Topic of Discussion: An open-source hardware platform for Direct Satellite-to-Devices Communication

On May 28, 2020, Jeff Garzik and Jeff Dionne held an AMA on Reddit.

Jeff Garzik is the CTO of SpaceChain Foundation. He is known for being the key Bitcoin core developer who worked under Satoshi Nakamoto for two years. His work can be found in every bitcoin and miner.

Jeff Dionne is the CEO of Core Semiconductor. He is known for uClinux, from which most embedded Linux systems are derived, and developing many other game-changing embedded systems hardware and software technologies.

Garzik and Dionne have always been passionate about pushing the boundaries of space and blockchain applications; a few of the past projects they have worked on are Linux kernel and Bitcoin Core.

They love to share more about their experiences being in their respective industries, such as the formation of the open-source industry, open hardware, fabless semiconductor development, nano-satellites, cryptocurrency, and more.

In this AMA, they discuss their development for their latest project — an open-source hardware platform that is capable of providing a downlink to mobile phones and small devices directly from satellites in orbit — all without the use of a satellite dish on Earth or a third-party network.

Here are some of the highlights:

1. What is in your opinion the best node or process to target when optimising price to performance ratio and having a low digital chip volume? What processes can we expect from the first Silicon running J-Core?

Dionne: It’s just my opinion… it depends on the application (maybe you can elaborate). At the moment with that caveat and in general terms, I’d probably say 55nm. It’s a commodity process and every fab offers it. But take that with a grain of salt, to properly answer the question I’d want to know the application but also the gate count, budget and what performance means to you. I’m assuming you’re talking about a general purpose embedded application with a CPU.

We’re working on a customer project that has a chance to be the first tapeout for CoreSemi in late 2020. Depending on their volume, we’ll probably target 55nm, but we already have some (not portable) IP blocks in 152nm from a previous design we could leverage.

There is also the idea that we might try and do a fully open (right down to the standard cells and IO pads) design that the community could reproduce. That would be 350nm, because shuttle runs are on the order of $10k.

The first application processor for J-Core will likely be quad core on 28nm, but that is a ways out yet.

2. That large process size sounds a lot like what https://libresilicon.com/ is targeting. Have you looked into them?

Dionne: Yes, and also relevant is http://opencircuitdesign.com. Part of the problem with using smaller process nodes in a completely open design is the NDAs that are needed. There are actual fab design rule documents that can be had for older processes… Once the business model of completely open designs has been proven to the fabs, we are hoping the situation improves.

Still doesn’t solve the issue that 180nm might be within reach of an open hardware Crowd Supply, but 28nm isn’t really.

3. What is the current performance of your GNSS implementation in terms of sample per min, latency and accuracy? Is there room for some more light computation on the current JCore you are using like drone flight control or robot control?

Dionne: The released GNSS RTL https://github.com/CoreSemi/gnss-baseband is designed to produce one output from the hardware engine to the host CPU every 1 ms. It’s the task of the software part to turn those raw samples into fix updates (for location). So the answer is updates can be as often as you take outputs from the software tracking loops and run the solution solver. We’ve not yet released the software side, probably that will take a few weeks or a month. We previously used this engine for precise timing, in overdetermined clock mode, and that isn’t in general what the community will want.

In a drone application, a dual J-Core SoC on an FPGA is definitely sufficient, a configuration that is basically a sweet spot for size and cost of the chip. If we were to put that on an ASIC, you could use a fairly cheap process and have plenty of DSP capability for flight control etc.

Would such a chip, or an FPGA board with a form factor useful for drone/robot control be something you think would be interesting?

4. Today’s setup for precision GPS requires RTK, so you end up with additional hardware. People are flying drones or driving robots on RPi, and so the size wouldn’t be a problem for a Turtle board. There is hat for RPi for this kind of application, but they aren’t really open hardware ( https://emlid.com/navio/ ). Just finding which pins emlid use is not obvious… I would think there would be some interest in a high precision drone setup that fit in a RPi format.

Dionne: Ok, thanks for the feedback. The receiver board that CoreSemi and SpaceChain put together fits on the Turtle Platform… We intend both of those to go up on Crowd Supply. We’re working on it, and we intend to do it in the next few months, but that has been slow going so no promises just yet.

Hearing there is interest definitely helps.

5. Did I miss the J32 release? If not when will it be out? Also how can the community help Core Semi?

Dionne: Coming up this summer. Software generally takes longer than hardware, J2 is well tested and supported by everything from the compilers to OS and application side, J32 CPU hardware needs that complete package before it can see wide use.

If we engage with the community to test and port software to the J32 platform (when released), that will be a great help in getting there. In the meantime, clone our repos, support our Crowd Supply, and support our partner SpaceChain whose support made these releases possible.

6. I am interested in knowing why SpaceChain decided to invest in Core Semiconductor when it is less than 6 months old?

Garzik: CoreSemi’s team and technology are much older than 6 months. The team has been involved in Linux and open source for 15+ years, and at the time had already developed a clean room implementation of the Hitachi SuperH processor (dubbed “J-core”), with themselves and some of the original Hitachi chip engineers.

SpaceChain wanted to help that team revive and market this open source hardware, as a fresh base for a new line of chips that can be used in space as well as on the ground.

SpaceChain has an interest in having open source hardware widely used — “with many eyes, all bugs are shallow” — investing in CoreSemi acts as a force multiplier for Spacechain and the whole open source ecosystem, which largely runs on closed processors today. The security value of open source means we can change that.

7. How can CoreSemi justify going with J-Core (SuperH) when RISC-V is all the rage? What relationship do you see J-Core having with RISC-V?

Dionne: We see J-Core and RISC-V existing in slightly different application spaces. J-Core arguably has better instruction set characteristics for deeply embedded applications (such as this GNSS / Downlink) and RISC-V is designed more as a competitor to ARM.

Both cores have the goal of democratizing the space, the differences in design philosophy with J-Core (SHCompact ISA) being more like an x86 with highly encoded, compiler friendly instructions. No one can argue that approach doesn’t have application. IMHO RISC-V is emphasizing clean and simple, directly implemented pipelines. Having both gives us all choice. In fact some of SpaceChain’s engineers are core developers of a well known RISC-V implementation called Hummingbird E203.

8. Because of COVID-19 there will be no in-person conferences where you could present J-Core and recent developments.

Do you plan to do long form presentations/podcasts where you tell us about what’s next, why things always take longer, what sessions you learned etc?

Dionne: Community engagement is important to us. We think given the constraints on in person presentations, the best plan seems to be a series of videos (YouTube and probably lbry.tv). Things do take longer than one imagines or would like, but the reason for that is never problems with the technology.

One thing I’d say we’ve learned is that there is no substitute for clean, buildable and well documented releases of the technology that have a hardware platform people can get their hands on. That is different from the pure open source software only model, and it’s a limiting factor for growth of open hardware. So we set out to change that. Our plan to do that is this:

1. Build a production version of the Jx FPGA platform (turtle board) (done)
2. With our partner SpaceChain, develop an application people can use (GNSS, and Downlink for things like IoT command and control, cryptographic hashes for light wallets, etc). Make the ‘hat’ board for that open also (this announcement)
3. Release the RTL (done), and then the software (in progress)
4. Get these kits into the hands of developers so they can build on top of our work
5. Begin publishing videos to show how to do that.

Numbers 4 and 5 are obviously one response to the global situation, but also have the benefit of producing artifacts people can work from in the future.

9. Garzik, I recall multi-tenant computing on satellites being mentioned. What do you see as use cases where tenants want to run code on satellites?

Colour me naive but the only thing that strikes me is access to the sensor data of the satellite but I guess it would be cheaper to just send the complete data down and process it on some normal computer?

Garzik: The existing satellite industry model is: one sat owner, one operator (often same as owner), and closed software, usually for a single purpose.

With modern software sandboxing, we can open that model up, making a — arguably risky — move to permit customers to upload their software. That’s brand new to the satellite industry, even though it is familiar and boring to the mobile phone and blockchain industries, where multi-app is normal.

Opening up the closed satellite industry model is key to making access to space less expensive and more egalitarian.

10. Do you have any use case examples where it would make sense to run my code above the clouds and instead of in the cloud?

Garzik: It was a point of economics: the more people that access a satellite, the lower the cost, which creates new business models that are not possible today due to higher costs, as well as making existing space business models much lower cost.

With regards to use cases, there are a few categories:

1. The software is associated with a specific type of satellite payload (usually a type of camera or other sensor), authenticating and encrypting the data directly at the physical source. Multiple tenants can securely share physical satellite resources. This can only be done at the physical device, which is located in space.
2. Increasing the number of spacecraft throughout inner space, LEO/GEO, produces the need to avoid going space-to-ground-to-space for a number of different applications. In-space processing is faster due to the laws of physics.
3. Elements of space settlement. Businesses that want to explore space jurisdictions have already existed, but never before had a meaningful way to truly operate off-planet in a way that matches the org’s decentralised / resilient goals.
4. Those business models that were created by entrepreneurs, just as the Internet itself spawned many new businesses and business models not thought of when the pre-Web engineers were sending text-based email to each other.

11. When can we see actual use cases for SpaceChain? Does it have any real use case since it is a utility token?

Garzik: Space business occurs on frustratingly slow timescales! I wish the world would go faster.

Ultimately, it takes a long time to build a space network.

The space network will use tokens for (1) network registration, (2) network access, and (3) one of several payment methods for space-based activities such as remote sensing, remote imaging, transmission, data storage and more.

We are working on that specific whitepaper right now. We call it “DSI”, the Decentralized Satellite Infrastructure. Keep an eye on https://github.com/dsi-org

12. Will people be able to contribute to the whitepaper? I am very interested in contributing to the whitepaper

Garzik: Yes, the whitepaper will be one of the repositories on the Github. It will be open to contributions for a couple months, then frozen.

13. I’m curious how you are going to bring some kind of economic value to investors of SPC?

Will it be for the usage of the network? Or are you planning to maybe move to some kind of DAO situation?

Garzik: There are at least three targets for the SPC token: network access, network usage, and payment. The general thesis is that everyday SPC holders benefit from there being demand for the token, generated by people acquiring the token in order to use it for space services, both terrestrial services as well as in-space services being paid for with SPC.

14. You keep claiming SpaceChain is open source and decentralized. So far there has never been any repository open to developers. Leave alone, not much peer review possible because there are no github updates. When Web 3.0 is evolving so fast how will you handle competition?

What if SpaceChain takes too long and never takes off like how Dunvegan Systems never took off?

Garzik: There are several repositories available at https://github.com/spacechain.

More recently, thanks in part to SpaceChain, there are also repositories at https://github.com/coresemi and https://github.com/j-core.

Lots of working code has been made available to the open source community. SpaceChain has also tested a lot of this code in space conditions, on the International Space Station and in the satellites SpaceChain has launched.

Space is slow but progress is clear… and open.

Check out the full AMA here.

Keep up-to-date with all of SpaceChain’s developments via Twitter and subscribe to our newsletter on our website for our latest news.