The Blog

In, 2018, we saw the rapid proliferation of the RISC-V architecture, with commercial deployments of SiFive Core IP in a broad range of applications ranging from wearables and edge devices to the enterprise core. Modern compute workloads are evolving rapidly and require the ability to scale performance on demand and very often have real-time, deterministic requirements. This diversity of workloads poses computational challenges that can be resolved only by domain-specific architectures. With the advent of 5G, core networks are transforming from hierarchical models in which intelligence was concentrated at the core to a decentralized structure where intelligence is getting distributed to the edge.

Published by SemiWiki.

We are really excited to see Wave Computing announce the open MIPS ISA and R6 processor core. SiFive would like to congratulate and welcome MIPS to the open-source community with its MIPS Open Initiative. The addition of the MIPS 32 and 64-bit open ISA will provide more options freely available to SoC designers. The open-source processor community, based on the RISC-V ISA, is thriving, and the addition of MIPS underscores the fact that the world is indeed becoming more open. Open ISA enables chip designers, innovators and academics to explore and expand their designs. The ability to add extensions to the base ISA makes it an attractive option for applications requiring special configurations. Chip designers no longer have to settle for an off-the-shelf processor. SiFive RISC-V cores have enabled a high degree of customization, which our customers have loved and used to create designs at 1/3 the power and area versus other solutions.

Hi everyone! I'm Nathaniel Graff, a software engineer here at SiFive, and I'm excited to tell you about the most recent release of Zephyr RTOS, version 1.13.0! Zephyr RTOS is a real-time operating system hosted by The Linux Foundation, featuring support for a myriad of different platforms, architectures, and targets including SiFive's E-series CoreIP, and the HiFive 1 development board.

It's been another week, which means it's time to find another host for "Last Week in RISC-V". This week we're going to attempt a blog at riscv.org, which will hopefully be a good long-term home for this series of articles.

This week's entry is fairly short, but it does come with one major improvement: we now have a mailing list! I've decided to create a Google Group at SiFive, and while I understand that's not ideal it's the best I can figure out for now. The Google Groups interface is quick clunky, so if you're looking for archives it's probably still best to use GitHub. Hopefully this makes it easier for people to find the mailing list.

I spent too much time writing my single entry this week so it's all I have. The issue itself is somewhat complex, so I thought it warranted a deep dive.

Relaxing R_RISCV_PCREL_* in the Presence of Addends

Jim recently found an issue with our ELF relocation scheme. While technically it's a somewhat wide-ranging ABI bug, the actual set of cases in which the issue will manifest is somewhat restricted -- in other words: while I'm sure the proper long-term fix for this will be quite involved, it probably isn't biting too many people in practice right now. If you're unsure about how ELF relocations and linker relaxation work on RISC-V systems, some of the early entries in my "All Aboard" series go into greater detail. For this week's summary, I'll restrict myself to the specific issues at hand.

The vast majority of RISC-V relocations follow the pattern of having one relocation to fill out the high 20 bits of a 32-bit address (relocations that follow the naming pattern R_RISCV_*HI20), and a second relocation to fill out the low 12 bits of a 32-bit address (relocations that follow the naming pattern R_RISCV_*LO12*). This R_RISCV*_HI20/R_RISCV*_LO12_* pattern is baked into RISC-V's instruction encodings, with the U format providing the high 20 bits and the I or S formats proving the low 12 bits (hence the names *_LO12_S and *_LO12_I). While the issue at hand applies to all relocations that follow this pattern, the toolchain can handle this extra complexity for the vast majority of these relocations -- that's why it took us so long to notice! It turns out that there is one specific case where the ABI we've chosen where this is difficult to do: the case where multiple LO12 relocations share the same HI20 relocation but have different addends.

Unfortunately this toolchain bug manifests as incorrect code generation from the linker, which is pretty much the worst sort of bug -- nobody understands the linker, so it's a long exercise for users to track down the bug and then a lot of work to fix it. In practice this bug it is somewhat unlikely to actually manifest in real code, but since it's a linker bug it's probably best to understand what is going on with an example before we dig into exactly why this bug is unlikely to manifest.

A Concrete Manifestation of this Bug

Like most of the examples I write it's somewhat contrived, I'll discuss how this applies to more likely user code later. The following assembly program is nonsensical but legal:

.text
.global _start
_start:
.balign 4096
.fill 2048, 1, 0
        1: auipc t0, %pcrel_hi(global)
        addi  t1, t0, %pcrel_lo(1b)+0
        addi  t0, t0, %pcrel_lo(1b)+8

.data
.balign 4096
global:
.fill 2, 8, 0

it's a fairly simple program: it takes the address of a global symbol and an offset into that global symbol. When assembled it generates a single R_RISCV_PCREL_HI20 relocation to fill out the top 20 bits of the auipc, and then a pair of R_RISCV_PCREL_LO12_I relocations to fill out each addi. This program assembles and links correctly, resulting in the pre-linked object file you'd expect

    17fe:	00000297          	auipc	t0,0x0
			17fe: R_RISCV_PCREL_HI20	global
			17fe: R_RISCV_RELAX	*ABS*
    1802:	00028313          	mv	t1,t0
			1802: R_RISCV_PCREL_LO12_I	.L11
			1802: R_RISCV_RELAX	*ABS*
    1806:	00028293          	mv	t0,t0
			1806: R_RISCV_PCREL_LO12_I	.L11+0x8
			1806: R_RISCV_RELAX	*ABS*+0x8

and a sensible executable

   11800:	00003297          	auipc	t0,0x3
   11804:	80028313          	addi	t1,t0,-2048 # 14000 <global>
   11808:	80828293          	addi	t0,t0,-2040

Things start to get interesting when we slightly perturb this program. In this case, let's look at what happens when we change the alignment of the auipc. At the assembly source level this is a straight-forward change (because I carefully constructed the example that way):

.global _start
_start:
.balign 4096
.fill 2050, 1, 0
        1: auipc t0, %pcrel_hi(global)
        addi  t1, t0, %pcrel_lo(1b)+0
        addi  t0, t0, %pcrel_lo(1b)+8

.data
.balign 4096
global:
.fill 2, 8, 0

In this case we generate a pre-linked object file that looks like you'd expect, essentially the same as what's above but with different alignment

     1800:	00000297          	auipc	t0,0x0
 			1800: R_RISCV_PCREL_HI20	global
 			1800: R_RISCV_RELAX	*ABS*
     1804:	00028313          	mv	t1,t0
 			1804: R_RISCV_PCREL_LO12_I	.L11
 			1804: R_RISCV_RELAX	*ABS*
     1808:	00028293          	mv	t0,t0
 			1808: R_RISCV_PCREL_LO12_I	.L11+0x8
 			1808: R_RISCV_RELAX	*ABS*+0x8

The interesting thing here is that this slight input perturbation results in an incorrect binary after linking

   11802:	00002297          	auipc	t0,0x2
   11806:	7fe28313          	addi	t1,t0,2046 # 14000 <global>
   1180a:	80628293          	addi	t0,t0,-2042

Essentially what's going on here is that our relocations are capable of providing 2^32 distinct bit patterns, but in the presence of pair relocations with distinct addends we need to be capable of generating 2^32+1 bit patterns. Like many bugs of this sort, it's quite obvious once it's been described but fairly difficult to find in practice.

Why this Probably isn't Manifesting in Your Program

If you've managed to make it this far you're probably getting pretty worried: a linker bug that manifests as silent incorrect code generation is a pretty hairy thing to deal with. While I agree, it turns out this bug has lurked for so long because it's somewhat unlikely to manifest in real application code under the set of compiler options that are actually sensible to use. We are of course working on fixing the bug (and there's already patches to at least cause it to manifest as an explicit failure to link), but a fully performant fix is somewhat tricky.

This bug can only manifest under a very specific set of conditions:

• There must be multiple LO12 relocations that share a HI20 relocation but have different addends.
• The result of the HI20 relocation must be misaligned WRT to final target of the LO12 relocations.

As long as you're writing C code and haven't written your own GCC optimization passes, these conditions are mutually exclusive:

• GCC doesn't know how to share a single auipc between multiple accesses, so the only way to end up with a shared relocation for the top 20 bits of an address is via lui.
• GCC always aligns the intermediate results of the lui-based relocations. This alignment is implicit: GCC aligns the target symbol, which for lui-based addressing results in an intermediate result that is always aligned.

Importantly, the second case is not true for our auipc-based relocations. Since auipc includes the current PC as part of the intermediate result, aligning the target symbol is not sufficient to align the intermediate result.

What's the Takeaway for a User of the Toolchain?

This article has been somewhat involved. I wrote it because I think it's an interesting dive into a toolchain bug, but most people reading this probably aren't interested in that level of detail and just want to know what to do. My official recommendation is simple: don't use -mcmodel=medany on an RV32I target. That's actually exactly the same recommendation as I would have provided before we found this bug. The key point here is that -mcmodel=medany doesn't actually provide any benefit on RV32I targets: -mcmodel=medlow can already generate every possible 32-bit address, so all -mcmodel=medany does is add a bit of complexity to the address generation. I used to think that all that did was generate slightly worse code, but now that we've found a correctness bug my recommendation is simply a bit stronger.

The only users who are likely to need -mcmodel=medany are those on 64-bit systems. While you're unlikely to find a bug in -mcmodel=medany -mexplicit-relocs because GCC can't perform constant subexpression elimination on auipc, I'd still recommend avoiding -mcmodel=medany -mexplicit-relocs. While -mcmodel=medany -mexplicit-relocs is necessary to squeeze the last fer percent out of Dhrystone, we've found it actually generates worse code for real programs which is why it's not the toolchain default. If you're really that worried about a few percent performance in Dhrystone then I'd recommend finding a better benchmark.

I also explicitly recommend that users do not try to backport the various patches to fix this bug themselves and instead wait for us to completely verify these bug fixes and add them to our backport branches. The workarounds above are really the right thing to do even without the bug, and due to the subtly of what's going on here you're more likely to end up introducing a bug than fixing one.

Events

• October 18: RISC-V Day Tokyo hosted by Keio University in Tokyo, Japan.
• October 22: RISC-V BoF at Embedded Linux Conference + IoT Summit Europe hosted by The Linux Foundation in Edinburgh, UK.
• November 13: RISC-V Microconference at Linux Plumbers Conference in Vancouver, Canada.
• December 3: RISC-V Summit in Santa Clara, CA.

Introduction to Linux Kernel Development

GNU Tools Cauldron Trip Report, Part 2

This is the last version of "Last Week in RISC-V" that I plan on sending to the various mailing lists, as we'll be posting the rest of them on SiFive's Blog. I didn't get any contributions, but I also haven't gotten through my email yet -- sorry if I missed anything that's been sent it, but I'm not too far behind so I should have everything read from this week by the end of next week.

The FU540-C000, which is available on the HiFive Unleashed development board, is a Linux capable board based on the open source Freedom platform. We built this chip to drive RISC-V Linux development, and it's been incredibly successful. In the three months since we started shipping the board the RISC-V Linux distribution porting effort, with Debian and Fedora leading the charge, has come farther that it had come in the previous 5 years. It's been incredible watching the open source community get behind the RISC-V ISA, and the level of progress has exceeded anything we could have predicted at the beginning of this year.

Welcome to the first issue of "Last Week in RISC-V", a weekly newsletter tracking the RISC-V community. This newsletter was born out of a discussion in SiFive's internal RISC-V software team and I'm compiling it so it'll have a somewhat heavy focus on the open source software community for now as that's where I spend most of my time. The general idea behind "Last Week in RISC-V" is that the RISC-V ecosystem is getting big enough that it's impossible for any single person to track everything going on. For a while we had the patches mailing list, but we've outgrown a single mailing list for all development -- plus, this mailing list is just for patches to core RISC-V software components so it isn't wide enough in scope to cover everything going on it the RISC-V ecosystem.

On Wednesday, July 25th, SiFive had the pleasure of hosting Girl Geek X at our offices in San Mateo. Girl Geek X is a brilliant organization with the aim of connecting women across companies large and small for the purposes of networking and sharing career advice in the fast-paced tech industry. Over the past 10 years, Girl Geek X has grown from a 400-person dinner hosted by Google to a well-known Bay Area group with a membership base of more than 15,000.

Last week SiFive launched the new E2 Series RISC-V Core IP. The E2 Series represents SiFive’s smallest, most efficient Core IP Series and is targeted specifically for embedded microcontroller designs. One of the reasons it is great for microcontroller applications is because of its extremely small area footprint, just 0.023mm² in 28nm for the entire E20 Standard Core! Another reason it's great for the embedded market is its configurability. The E2 Series can be configured even smaller than the E20 Standard Core by removing things like the Interrupt Controller and support for the M extension. Another major reason the E2 Series is great for microcontroller applications is its support for the new RISC-V Core Local Interrupt Controller (CLIC) which allows for extremely low latency interrupt operation, hardware preemption, and hardware prioritization of all interrupts. The CLIC specification is a result of collaboration between RISC-V members in the RISC-V Foundation’s Fast Interrupts Technical Group and the draft specification can be found here.

Good news, HiFive fans! A limited supply of HiFive Unleashed Development Kits are now available on CrowdSupply for purchase.

We recently announced that Intel Capital participated in our Series C funding round! Our CEO, Naveed Sherwani, revealed the investment earlier this month at the Intel Capital Global Summit.

We’re very happy to announce that Intel Capital participated in our recent Series C funding round. The investment was revealed at the Intel Capital Global Summit earlier today.

QEMU 2.12.0 was released on April 24th 2018 and this version is the first official QEMU version to contain the RISC-V port. This is yet another milestone towards the development of the Open Source RISC-V tools on top of the recent acceptance of RISC-V in Linux kernel 4.15 in December last year and GLIBC 2.27 this past February.

Boy have we been busy. Over the last few months, our DesignShare ecosystem has continued to expand, and, this week, we were excited to welcome Dover Microsystems into the program.

First, we are thrilled to have recently announced that we raised $50.6 million in our Series C funding round! We wanted to thank our existing and new investors - including Chengwei Capital, Huami, SK Telecom and Western Digital - for the continued support and new engagement, so we held a party to celebrate!

We’re heading to the Embedded Linux Conference next week, March 12-14, to hold our first hackathon. Developers will be among the first to run code on the HiFive Unleashed board with a chance to take home a board of their own and win a $1,000 cash prize.

Date: Monday, March 12 – Wednesday, March 14
Time: 10:30am Monday – 1:00pm Wednesday
Location: Embedded Linux Conference, Hilton Portland Downtown, Skyline II, Floor 23

As our business continues to grow, the people we hire continue to impact and shape our business more and more.

We recently announced the HiFive Unleashed, a development board for Freedom U540-C000, the world's first Linux-capable RISC-V ASIC. The announcement of this board roughly lined up with the first upstream releases of Linux and glibc that contain RISC-V support. As a result, our news has driven a lot of interest from the open source software community -- that was really the whole point of announcing the board in the first place, so in that sense it's working out very well.

Before we dive into our newsletter, we want to take a moment to talk about the vulnerabilities around Meltdown and Spectre. First off -- and most fortunately -- SiFive’s RISC-V Core IP offerings are not affected by Meltdown and Spectre. Secondly, as the RISC-V Foundation’s statement on these vulnerabilities notes, now is the time for open architecture and open hardware designs to shine.

The recently disclosed speculation-based timing attacks Meltdown and Spectre have received much attention this week—and rightly so. The vulnerabilities these attacks exploit are not limited to a particular instruction-set architecture, nor are they restricted to a single vendor’s implementations. Many processors that rely upon speculation to improve performance are affected, even some that do not use out-of-order execution.

A new year brings new opportunities. Before we dive into 2018, we wanted to take some time to reflect on some of the excitement we experienced over the last couple of months.

This post covers recent development in RISC-V QEMU, the open source machine emulator and virtualizer. We’ve been playing a game of catch-up with the hardware folks so that we can match the capabilities of the Freedom U500 SDK. We’re not quite there yet, but we’ve made some important improvements that will allow for a more usable emulator.

This entry will cover the RISC-V port of Linux's memory management subsystem. Since the vast majority of the memory management code in Linux is architecture-independent, the vast majority of our memory management code handles interfacing with our MMU, defining our page table format, and interfacing with drivers that have memory allocation constraints.

As some of you may have heard, the RISC-V Linux port has been accepted into Linus' tree and is slated to release as part of 4.15. While this is a major milestone, we're far from done in Linux kernel land and there's a whole lot of work left to be done in userspace.

These last few months have been equal parts busy, exciting, and promising. We are eager to catch you up on the latest happenings at SiFive and within the RISC-V ecosystem as a whole.

It’s that time of year again--awards season, the time when companies submit their best-of-year products and initiatives for consideration by industry watchers and judging panels. It’s a familiar, fairly predictable cycle, but sometimes it can take one by surprise.

Our DesignShare family is growing, and we’re thrilled to announce that Analog Bits, the industry’s leading provider of low-power mixed-signal IP solutions, is now a part of the ecosystem.

It’s been a fantastic few months for us with new initiatives and industry recognitions, and we’re excited to share more great news. Earlier this month, we welcomed eMemory, the IP provider of logic-based, non-volatile memory (Logic NVM), as the latest company to join the DesignShare movement!

Continuing our journey into the RISC-V Linux kernel port, this week we'll discuss context switching. Context switching is one of the more important parts of an architecture port: it is all but impossible to completely abstract away the details of entering and exiting the kernel, Since this is on many critical paths (system calls and scheduling) it must go fast, but since it's the one line of protection the kernel has from userspace it must also be secure.

With all apologies to Shakespeare, would a core by any other name still hit the sweet spot in the market for those looking for cost-effective custom silicon?

Earlier this month, we took a huge step in democratizing access to custom silicon when we unveiled our newest core, the U54-MC Coreplex - the industry’s first RISC-V based, 64-bit, quadcore application processor with support for full featured operating systems including Linux, Unix and FreeBSD.

This post begins a short detour into Linux land, during which we'll be discussing the RISC-V Linux kernel port. SiFive has recently announced the Linux-capable U54-MC RISC-V Core IP, and our Linux port was recently submitted to linux-next, Linux's staging branch, so assuming that everything goes smoothly we should be merged at the end of the next merge window. Along with Linux we should soon have the full suite of core system components upstream, both for embedded systems (via binutils, GCC, and newlib) and larger (via binutils, GCC, glibc, and Linux).

Since we launched the industry’s first open-source RISC-V SoC back in July of last year, we’ve had the pleasure of pushing the boundaries of the RISC-V ecosystem and have been delighted by the support that SiFive – and RISC-V – has gained from system designers and Makers alike.

A previous blog described how the -march and -mabi command-line arguments to GCC can be used to control code generation for the sources you compile as a user, but most programs require linking against system libraries in order to function correctly. Since users generally don't want to compile every library along with their program, either because they're too complicated or because they're meant to be shared, a mechanism is needed for linking against the correct set of system libraries to match the ISA of the user's target system and the ABI of the user's generated code.

It’s been a busy summer for us. Our days have been filled with many prospect, customer and partner meetings with teams looking to leverage RISC-V in their roadmap. Last week, we announced the outcome of one of those meetings: UltraSoC, a provider of on-chip monitoring and analytics IP, is the latest company to join the DesignShare movement.

This one-hour webinar is for Embedded Developers who are interested in learning more about the RISC-V architecture. It covers areas such as the Register File, Instruction Types, Modes, Interrupts, and Control and Status Registers. Prior knowledge of RISC-V is not necessary, but having a basic understanding of Computer Architecture is beneficial.

The RISC-V ISA was designed to be both simple and modular. In order to achieve these design goals, RISC-V minimizes one of the largest costs in implementing complex ISAs: addressing modes. Addressing modes are expensive both in small designs (due to decode cost) and large designs (due to implicit dependencies). RISC-V only has three addressing modes:

On August 15, we announced that regarded industry veteran Naveed Sherwani has joined SiFive as CEO. We invited him to share his vision for the company and his optimism for fomenting a revolution in the semiconductor industry.

Last week's blog entry discussed relocations and how they apply to the RISC-V toolchain. This week we'll be delving a bit deeper into the RISC-V linker to discuss linker relaxation, a concept so important it has greatly shaped the design of the RISC-V ISA. Linker relaxation is a mechanism for optimizing programs at link-time, as opposed to traditional program optimization which happens at compile-time. This blog will follow an example linker relaxation through the toolchain, demonstrate an example of how linker relaxations meaningfully improve the performance of a real program and introduce a new RISC-V relocation. We'll shy away from discussing the impact of linker relaxations on the RISC-V ISA, until another blog entry.

As we continue to expand our product offerings to better serve the rapidly growing RISC-V and SiFive community, we are always looking to work with companies (big and small) who share our vision.

Our first stop on our exploration of the RISC-V toolchain will be an overview of ELF relocations and how they are used by the RISC-V toolchain. We'll shy away from discussing linker relaxations and their impact on performance for a follow-up blog post so this doesn't get too long. The example has been carefully constructed to be unrelaxable as to avoid confusion. Additionally we're only going to discuss the relocations used by statically linked executables, avoid discussing position independent executables and forget about thread local storage -- like linker relaxation, all of those warrant a whole post on their own. There will be a lot more to come about relocations in later blog posts.

Before we can board the RISC-V train, we'll have to take a stop at the metaphorical ticket office: our machine-specific GCC command-line arguments. These arguments all begin with -m, and are all specific to the RISC-V architecture port. In general, we've tried to match existing conventions for these arguments, but like pretty much everything else there are enough quirks to warrant a blog post. This blog discusses the arguments most fundamental to the RISC-V ISA: the -march, -mabi, and -mtune arguments.

I'm Palmer Dabbelt, a software engineer at SiFive and a maintainer of various RISC-V ports. I've been working with the RISC-V ISA for a few years, and it's finally starting to get ready for prime-time. We're not yet upstream in Linux or glibc, but hopefully by the end of the year we'll have the core set of system software in the relevant upstream repositories -- at which point distributions can begin porting to RISC-V and users can begin using our software. I started working with RISC-V before the user ISA had been finalized (at least v2 of the user ISA, the real one :)) and it's almost a bit scary how real things have gotten over the last few years.

Welcome to the first iteration of our bi-monthly newsletter, The SiFive Download! On a regular cadence, we will plan to give you a download on all things SiFive – from the events we will be attending to the articles we’ve been featured in. This newsletter is intended to give you a glimpse under the SiFive hood.

It’s been quite busy the past month and change for SiFive and the RISC-V community. On May 4, we unveiled our RISC-V Core IP, radically redefining the process by which you can license and buy custom IP. The RISC-V Core IP launch was followed by a panel at Maker Faire Bay Area, where we got to chat with American computer engineering pioneer Dave Patterson and other panelists about RISC-V and the future of open-source hardware (pictured below).

Last week, SiFive announced the immediate availability of its RISC-V Core IP, the fastest and easiest way to license RISC-V cores. It sounds like another announcement from another tech company. However, it isn't if you read the press release that was sent out to the world. I think Yunsup Lee, CTO and co-founder of SiFive explains it well in there:

I'm thrilled to announce a milestone in RISC-V's adoption within the open-source software community: GCC, the popular compiler for GNU/Linux systems, has accepted the RISC-V backend for inclusion in its next release. We expect GCC 7.1 will ship with RISC-V support in late April. A robust compiler underpins nearly all other software development, and so I expect the availability of the GCC port will accelerate the development of applications, runtime libraries, and operating systems for RISC-V.

Hi. I’m Megan. And I’m a woman working on RISC-V hardware.

Here at SiFive, we believe that open-source and mass customization are going to change the semiconductor industry. While working with open-source software is well understood by (most) companies and individuals, open-source hardware is still a new concept.

SiFive was founded on one simple belief: that open source and mass customization are the answer to the end of conventional transistor scaling and escalating chip design costs. The free and open RISC-V ISA has been central to our vision of enabling a whole new range of applications for everyone — even the smallest company, inventor or maker. We wanted to free silicon — and we firmly believed that RISC-V was the critical first step.

It was exciting to see how much activity has developed around RISC-V and SiFive at the recent 5th Workshop here in Silicon Valley. No doubt there’s still work to be done, but the ecosystem has come such a long way in the past 12 months. Once again, the workshop was sold out! More than 350 attendees, 107 companies and 20 universities were represented, and those people were all in awe when they saw SiFive’s real silicon come out with the message that SiFive is open for MORE business. The community also was impressed that we made open-source RTL code available online for our Freedom SoCs. All this news marked a milestone for a still nascent open-source hardware movement.

A couple weeks ago, Jack and I traveled to Taiwan. Not that unusual for those of us in the semiconductor industry used to making a pilgrimage to visit customers and partners. This trip, however, was big for us, and we brought back the best “souvenirs” ever – the first ever commercially available RISC-V SoCs!

In a recent post, Yunsup shared some of the successes and challenges we’ve faced in our first year as SiFive. Little did we know when that post went live, we’d be able to follow it up with yet another measure of success: Late last week, we learned that SiFive has been shortlisted as a finalist for UBM’s ACE Award for Startup of the Year!

San Francisco, Brannan Street. While Giants fans pour out of AT&T Park, SiFive employees walk out of the office after another long day of coding. Building a startup isn’t glamorous, and it’s understood that only those who put in the hard work and extra effort will make it through.

Having worked in the semiconductor industry for over 12 years, I've learned one universal truth: IP companies can be notoriously difficult to work with. Unless you are one of the larger chipmakers, you'll likely find that IP firms simply won't make time for your design.

The open source software movement has been credited as a key driver of the birth of the Internet Age. Without developments such as Linux; the free Apache Web-server platform; and tools such as Java, Perl and Ruby, the Web as we know it would likely not have been possible.

It’s no secret the semiconductor industry is in a state of flux and consolidation. As a New York Times’ headline recently screamed, “Semiconductor Industry Shrinks Some More With Latest Deal.” In the month of July alone: Analog Devices snapped up Linear Technology; Cypress closed its acquisition of Broadcom’s IoT assets; Infineon bought Wolfspeed. And then there was the deal of all deals – SoftBank acquired ARM.