Our Ideas, Thoughts, and News
SiFive — Jan 4, 2019
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.
SiFive — Dec 18, 2018
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.
SiFive — Oct 30, 2018
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.
SiFive — Oct 12, 2018
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.
SiFive — Sep 28, 2018
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.
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_* 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_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
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
R_RISCV_PCREL_HI20 relocation to fill out the top 20 bits of
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
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
LO12relocations that share a
HI20relocation but have different addends.
- The result of the
HI20relocation must be misaligned WRT to final target of the
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
auipcbetween multiple accesses, so the only way to end up with a shared relocation for the top 20 bits of an address is via
- 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 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
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
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.
- 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.
SiFive — Sep 7, 2018
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.
SiFive — Sep 6, 2018
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.
SiFive — Aug 31, 2018
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.
SiFive — Jul 31, 2018
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.
SiFive — Jul 12, 2018
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.023mm2 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.
SiFive — May 8, 2018
SiFive — Apr 25, 2018
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.
SiFive — Apr 17, 2018
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.
SiFive — Apr 16, 2018
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!
SiFive — Mar 6, 2018
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.
SiFive — Mar 3, 2018
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
SiFive — Feb 20, 2018
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.
SiFive — Jan 23, 2018
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.
SiFive — Jan 5, 2018
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.
SiFive — Dec 20, 2017
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.
SiFive — Dec 11, 2017
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.
SiFive — Dec 5, 2017
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.
SiFive — Nov 30, 2017
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.
SiFive — Nov 16, 2017
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.
SiFive — Nov 9, 2017
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!
SiFive — Oct 23, 2017
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.
SiFive — Oct 10, 2017
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.
SiFive — Oct 9, 2017
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).
SiFive — Oct 6, 2017
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.
SiFive — Sep 18, 2017
A previous blog
described how the
-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.
SiFive — Sep 12, 2017
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.
SiFive — Sep 12, 2017
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.
SiFive — Sep 11, 2017
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:
SiFive — Aug 28, 2017
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.
SiFive — Aug 24, 2017
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.
SiFive — Aug 21, 2017
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.
SiFive — Aug 14, 2017
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
SiFive — Aug 7, 2017
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.
SiFive — Jul 11, 2017
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.
SiFive — Jun 14, 2017
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).
SiFive — May 7, 2017
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:
SiFive — Mar 3, 2017
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.
SiFive — Jan 26, 2017
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 — Jan 19, 2017
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.
SiFive — Dec 20, 2016
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.
SiFive — Nov 29, 2016
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!
SiFive — Nov 9, 2016
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!
SiFive — Nov 3, 2016
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.
SiFive — Oct 25, 2016
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.
SiFive — Sep 20, 2016
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.
SiFive — Aug 10, 2016
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.