Makers are the epitome of what big chip vendors used to consider a waste of time for their valuable salesfolk. “Fred in the shed,” as they said. No volume, no ROI. “Stick with Tier 1s.”

But you Makers are now in demand, given that you’re particularly good at things required for Internet of Things (IoT) types of systems, taking readily-available platforms and making them do cool things – things that larger companies are now more interested in; things that could potentially sell in high volumes. I don’t know whether chip guys are now selling to Makers, but Makers have definitely been courted with more platforms (hardware and software) and tools for getting, at the very least, proofs of concept out the door quickly.

The one thing that hasn’t been made available to Makers, however, is easy access to custom silicon. And Makers aren’t the only ones being left out. As silicon moves to ever-more-aggressive nodes, transistor cost is no longer scaling. The cost of implementation, on the other hand, is scaling through the roof. So super-high-end nodes are really reserved for huge companies that can bankroll that scale of development.

So what’s an ambitious Maker to do if he or she wants to do something more efficiently than some garden-variety microcontroller (MCU) will let them do? Custom silicon has been a non-starter.

This is the focus of a newer silicon company called SiFive. They’re touting open-source hardware, with a couple of customizable platforms based on the RISC-V instruction set and architecture. To see better what they’re doing, we should take a dip into RISC-V, then look at how SiFive has adapted it, and then understand what the business model is here.

Less RISCky?

The RISC-V architecture originated out of UC Berkeley, one of many different processor architectures originating in a school. Many such projects are for academic use or for studying different novel variations on processor architectures, or just for teaching processor concepts. RISC-V, however, has, in the manner of right place/right time, garnered a surprising level of industry support. Last year, there were 16 companies as members of the RISC-V foundation; next year, SiFive expects 50.

“Why do we need a different processor?” you might ask. After all, ARM has been dominating, with MIPS (now Imagination Technologies) and others picking up what they can. From SiFive’s standpoint, they believe that ARM does a good job – for the markets they serve. Which doesn’t include Makers. (Whether the recent SoftBank acquisition of ARM will change that remains to be seen…)

So SiFive sees an opportunity to leverage this open-source architecture for this growing sector.

One of the RISC-V notions that potentially extends the life of RISC-V is this: An instruction set architecture (ISA) should really be more of an API than an actual implementation. That’s not the way it’s been, however. When you use ARM, unless you’re one of the very few initiates, you get an implementation, not just the right to use their ISA. Of course, if all you want is an implementation as it is, then that’s perfect – assuming you have the money to license it.

But if you want to make a more efficient implementation (assuming you can – ARM can throw lots of talent at its implementations), you’re not allowed to. The risk of this is that, if ARM goes away, so does their architecture (depending on any last-gasp legal maneuvers to disposition the IP). If Intel goes away, then their architectures go with them, by the same reasoning. I’m not sure that there’s a clear and present danger of either of those ISAs disappearing, but you get the point.

In contrast, by making RISC-V an open-source API-like ISA, then anyone is free to use it, creating their own implementation or buying someone else’s IP. No one company owns all of the implementations, so if any particular provider disappears, RISC-V remains. And the RISC-V ecosystem is rapidly growing, meaning that IP and tools vendors are investing, spinning up a life for RISC-V that’s distributed over many companies, making it more likely to persist in the wake of specific company comings and goings.

I won’t delve into graphic detail on the ISA itself, but a good way to understand some of the variations is to start by understanding the naming scheme. You’ll see these long strings here and there (and Googling them yields surprisingly unhelpful links); SiFive uses two specific variations, which is what forced me to study the scheme.

• First off, they all start with RV.
• Then comes the address space. There are 32-bit and 64-bit versions. Memory addressing can be up to 128 bits. So you’ll see 32, 64, or 128 next in the name.
• Then comes I (for integer) or E for their version with reduced integer registers for use in small MCUs
• Then come the following possible variants:
  • M for integer multiplication and division
  • A for atomic memory instructions
  • F/D/Q for single-/dual-/quad-precision floating point, respectively
  • C for their 16-bit compressed instruction format
  • N for support of user-level interrupts (this isn’t yet documented in the formal naming section of the spec, but it comes as part of a proposed privileged ISA extension, according to SiFive). This could be an important feature for systems with sensors needing to report in to the mothership.
  • X for a non-standard subset
  • S for their supervisor-level ISA
• And you can have version numbers for each of these extensions – major rev number, then “p”, and then minor rev number (“p0” can be omitted).
• Their base combination IMAFD is considered the default configuration and can be abbreviated “G” (for “general), As in, RV64G.

So, for example, one of the SiFive platforms uses the RV64GCSv39; this has IMAFD capabilities plus the compressed format and v39 of the supervisor-level ISA.

SiFive’s Platforms

What SiFive has done is to build two platforms – a smaller, lower-performance E300 and a larger, faster U500, with a complete implementation of a RISC-V subsystem, minus a few items available for customization. In other words, for all that discussion of the ISA as API instead of implementation, in this case you’re getting an implementation (it’s just that you’re not getting the only implementation, as would be the case with other processors). I’m assuming that, as a Maker of systems, you’re not looking to do low-level transistor design to improve the processor, but rather to customize its capabilities, so presumably this is a good thing, since you can still do customizations, as we’ll see.

The E300 has a single core, and the image below illustrates what’s customizable: instructions and co-processors, accelerators, always-on wake-up logic, and I/Os. This is built on TSMC’s 180-nm process.

(Image courtesy SiFive)

Note that this core uses the 32-bit E version of the RISC-V ISA, with reduced register set, compressed instructions, and user interrupt support.

(Image courtesy SiFive)

Meanwhile, the U500 platform uses a beefier version of RISC-V (RV64GCSv39), and it allows up to 8 of them, with cache already in place. There is an additional “monitor” core (RV64IMACN) for use in secure boot and for handling other background tasks without burdening the main application cores. The same elements that are customizable in the E300 are also customizable here. This is built on TSMC’s 28-nm process.

Doing Actual Design

Of course, if this platform were simply a piece of IP, you’d still have to buy all of the EDA tools (yike$!) and then buy a mask set (yike$$$!). But this is where SiFive continues their involvement. You work with them, specifying your customizations. They finish the design, doing all of the EDA checks to make sure that everything is hunky dory. Then you go to masks.

You can have your own masks or go with shuttle wafers, where you’re getting only a portion of the wafer – sharing the costs with other projects. SiFive handles the production, packaging, and testing, so that you receive packaged devices that should be PCB-ready.  SiFive says that NREs are generally within the range of a “modest” Kickstarter campaign.

You also know that, once you have a part in your hand, you’re less than half-way done. You need software, and this is where SiFive touts the growing RISC-V ecosystem. OSes and drivers and stacks are increasingly available for RISC-V, meaning less for you to write yourself. Yeah, if you’ve done some customization, then you might need to modify a driver or two. But you have a starting place, reducing the amount of work.

Does this venture provide the right cost points for Makers? That has yet to be proven. But it’s certainly the closest I’ve seen anyone come to making custom silicon available for non-behemoths. If it works, it gives Makers a whole new angle – Fred may yet come out of the shed and into a shiny new building.

More info:

SiFive