OnChip and SiFive, two groups aiming to develop and release RISC-V platforms, have announced they will collaborate. From OnChip's crowdfunding campaign:
Ever since SiFive's HiFive1 campaign was launched just a week after we launched Open-V back in November, we've both been getting a lot of questions about how we might collaborate. It's taken a while, as these things do, but we finally have a concrete answer we think will benefit everyone, not least the RISC-V community. Here's how we're collaborating:
...
Open-V Will Use the SiFive E31 CPU Coreplex
...
All Open-V Peripherals Will Be Compatible with SiFive Chips
...
SiFive Will Donate Wafer Space in a May 2017 Tapeout
...
OnChip Will Contribute to the Free Chips Project
Sounds like good news for those hoping for RISC-V and open hardware designs to become tangible objects.
Note that the SiFive HiFive1 campaign was successful and has already shipped to some backers while the OnChip OPEN-V campaign looks like it will not reach its goal.
Related Stories
From the lowRISC blog:
We are looking for a talented hardware engineer to join the lowRISC team and help make our vision for an open source, secure, and flexible SoC a reality. Apply now!
lowRISC C.I.C. is a not-for-profit company that aims to demonstrate, promote and support the use of open-source hardware. The lowRISC project was established in 2014 with the aim of bringing the benefits of open-source to the hardware world. It is working to do this by producing a high quality, secure, open, and flexible System-on-Chip (SoC) platform. lowRISC C.I.C. also provides hardware and software services to support the growing RISC-V ecosystem. Our expertise includes the LLVM Compiler, hardware security extensions and RISC-V tools, hardware and processor design.
[...] lowRISC is an ambitious project with a small core team, so you will be heavily involved in the project's development direction. This role will involve frequent work with external contributors and collaborators. While much of the work will be at the hardware level the post will offer experience of the full hardware/software stack, higher-level simulation tools and architectural design issues.
Some practical experience of hardware design with a HDL such as Verilog/SystemVerilog is essential, as is a good knowledge of the HW/SW stack. Ideally, candidates will also have experience or demonstrated interest in some of: SoC design, large-scale open source development, hardware or software security, technical documentation, board support package development and driver development. Industrial experience and higher degree levels are valued, but we would be happy to consider an enthusiastic recent graduate with a strong academic record.
Informal enquires should be made to Alex Bradbury asb@lowrisc.org.
takyon (thanks to an AC): lowRISC is a project to create a "fully open-sourced, Linux-capable, system-on-a-chip"; it is based around RISC-V, the "Free and Open RISC Instruction Set Architecture", which is meant to provide an extensible platform that scales from low-level microcontrollers up to highly parallel, high-bandwidth general-purpose supercomputers.
Reduced instruction set computer (RISC).
Previously: RISC-V Projects to Collaborate
LowRISC Announces its 0.4 Milestone Release
SiFive and UltraSoC Partner to Accelerate RISC-V Development Through DesignShare
Qualcomm Invests in RISC-V Startup SiFive
Investors are zeroing in on the open standard RISC-V instruction set architecture and the processor intellectual property being developed by a batch of high-flying chip startups.
Last fall, Esperanto Technologies announced a $58 million funding round. The chip IP vendor is incorporating more than 1,000 RISC-V cores onto a single 7-nm chip. Data storage specialist Western Digital is an early investor in Esperanto, Mountain View, Calif.
This week, another RISC-V startup, SiFive, announced a $65.4 million funding round that included new investor Qualcomm Ventures. SiFive, San Mateo, Calif., has so far raised more than $125 million, and is seen as a challenger to chip IP leader Arm.
Observers note that wireless modem leader Qualcomm is among Arm's biggest customers, making its investment in SiFive intriguing. Also participating in the Series D round were existing investors Chengwei Capital of Shanghai along with Sutter Hill Ventures and Spark Capital. Intel Capital and Western Digital also were early investors.
Also at EE Times.
See also: SiFive Acquires USB 2.0 and 3.x IP Portfolio to Strengthen RISC-V SoCs
Previously: RISC-V Projects to Collaborate
SiFive and UltraSoC Partner to Accelerate RISC-V Development Through DesignShare
SiFive Introduces RISC-V Linux-Capable Multicore Processor
SiFive HiFive Unleashed Not as Open as Previously Thought
Linux Foundation and RISC-V Proponents Launch CHIPS Alliance
Separately, a handful of RISC-V proponents launched the CHIPS Alliance, a project of the Linux Foundation to develop a broad set of open-source IP blocks and tools for the instruction set architecture. Initial members include Esperanto, Google, SiFive, and Western Digital. CHIPS stands for Common Hardware for Interfaces, Processors, and Systems.
Esperanto Technologies and SiFive look like the names to watch.
Related: First Open Source RISC-V Implementations Become Available
Western Digital Unveils RISC-V Controller Design
Raspberry Pi Foundation Announces RISC-V Foundation Membership
Western Digital Publishes RISC-V "SweRV" Core Design Under Apache 2.0 License
(Score: 3, Interesting) by Anonymous Coward on Monday January 30 2017, @03:08PM
This RISC-V ISA (instruction set architecture) has the potential to facilitate humanity's escape from locked-down, proprietary computing; it has the simplicity of an older model of RISC, but it has also been designed to be modular and extensible, thereby providing a common plan for implementations that span the spectrum from the low-power to the high-performance, and from the well-understood to the not-yet-known (for instance, there is support for 128-bit implementations).
Anybody who is interested in libre computing should be allocating his resources towards these projects; freedom is more than software deep.
However, is the right way to go about furthering this technology to build low-powered microcontrollers, or is it to start at a level of computing that is more general purpose? It is my belief that the real struggle is already in the realm of personal computing, and so I'm hoping that something like the lowRISC [lowrisc.org] project will find as much support and success in the near future.
Please investigate these projects, and lend what resources you can spare towards furthering them.
(Score: 2, Insightful) by Anonymous Coward on Monday January 30 2017, @03:51PM
As a backer of both of the projects (already received a Founder's Edition HiFive), I agree in full. It seems, however, that small projects are successful while large ones fail, the Talos Workstation was a sad testament to that. One can only hope microcontroller hardware bootstraps an ecosystem that can expand upward. Remember that the Linux kernel will probably never run on anything but a 386.
(Score: 2) by VLM on Monday January 30 2017, @04:10PM
You can't say that kind of thing then drop the mic and walk off, AC. Comments on using it, assuming you've started messing with it?
That thing is fast. When I saw the specs I immediately started thinking of interfacing some A/D D/A and writing some SDR code to make a SDR appliance. Don't need that much memory just DSP grade raw processing speed and A/D thruput. But I suppose there are other entertaining uses for a beast like that...
I'm confused by the whole 16 K of ram 16 M of flash. Typo? What the? Who spec'd that?
Also WTF is 3.3V/5V IO? Look you set pin 4 to binary 1 hook up a voltmeter it reads... let me guess, 3.3V and they expect that to work with most 5V parts and the inputs are tolerant of 5V input although they're technically 3.3V pins.
That thing is so fast, I think it would be easy to run old school emulators on it. Which you can do on a pi such as retro-pi. But this has excellent IO making it easy to built a little retro 2600 cabinet or something like that. I'm too lazy to even do back of the envelope but I think its fast enough to output NTSC video signal by bit banging one of the pins. Huh. A complete Atari 2600 retro simulator. Just add joysticks and stuff.
Being brutally fast I bet it could drive a CNC system pretty well. To do what? Well replay from the huge 16M flash I guess.
(Score: 2) by LoRdTAW on Monday January 30 2017, @06:13PM
From the manual:
The system mask ROM is 8 KiB in size and contains simple boot code. The system ROM alsoholds the platform configuration string and debug ROM routines
...
A dedicated quad-SPI (QSPI) flash interface is provided to hold code and data for the system.
Source: https://dev.sifive.com/documentation/freedom-e310-g000-manual/ [sifive.com]
It sounds as if they have not included any flash on die or in package. Probably due to the patent minefield and licensing issues for flash itself. So the 16MB(or Mb?) is off package and connected through a dedicated QSPI flash controller. It's not a bad idea as it allows you pick the flash size but I would be concerned with access times considering QSPI is what, a 4x 50-100 MHz serial bus? That sounds like it could starve the 300MHz CPU pretty fast if you are reading large amounts of data from flash like bit maps or working with look up tables. Though they state that they have a few optimizations to reduce the latency thanks to the 16kb cache and a burst mode for the QSPI controller.
The 16k RAM is a disappointment, would have at least wanted 64k-128k. But for most smaller projects, it's enough. I like the base specs, it does have three QSPI ports which would allow you to interface to external RAM's but not sure how that would map into memory space and again, latency issues.
Shame we also don't have a middle ground SPI like bus with a little more smarts like PCIe and 1394 (memory mapped I/O + INT + DMA + multiple devices) but way more simple and runs in the 1-2.5GBps range. Would make a great interface to other MCU's, FPGA's, Displays, RAM, Flash, Ethernet MAC's, etc. Just need a few differential pairs.
(Score: 0) by Anonymous Coward on Monday January 30 2017, @08:36PM
Is that too much to ask?
I just want a damn RISC-V with provisions for either an SDRAM+ memory bus, or a frontside bus that can be glued to a dedicated memory controller, allowing the bootstrapping of real modern operating systems.
The next step from there is a southbridge/io bus link to provide access to a wide range of peripherals and configurable bus topologies.
Once we have these we can start working on adding support for Option ROM/UEFI Rom compatible devices and figure out our next steps towards opening the whole desktop/notebook industry to power users again and freedom/security concerned normal users again.
(Score: 2) by LoRdTAW on Monday January 30 2017, @11:33PM
The MMU is out of scope for this offering which is more akin to a low power microcontroller. I'd love to see the same but we are a long way off and would need a lot of talent to make such a system practical for day to day computing running Linux. Just imagine the complexity of a modern "desktop" oriented SoC to cover most modern use cases:
Embed 2-4 64 bit cores, 1-3GHz, w/caches (64 bit because you want more than 4GB right? and just say no to PAE)
Virtualization extensions
MMU, IOMMU, DMA, Interrupt, etc.
Dual channel DDR4 memory controller w/ecc (because why not)
PCIe endpoints
hardware gigabit MAC's
QSPI SD interface
SPI, i2c, UARTs
HD Audio interface
USB 2/3/C
SATA or enough PCIe lanes and endpoints for an m.2 interface or two
Such an SoC would cover laptop, desktop, and even small server use. Then you could Boot strap it from an i2c or SPI flash using Libreboot and then it's off to booting Linux, BSD, whatever.
Another issue would be graphics as we don't yet have a libre GPU for 3D. Though, in the meantime, I'm sure it would be simple to build a 2D frame buffer and let the driver handle the 2D acceleration of things like scaling, font rendering, video, overlay, lines, curves, bitmaps, etc. (basically 2D primitives and bitmap manipulation). Would be a CPU hog but would simplify the hardware until we can develop a GPU. Could also benefit server use where a GPU is unnecessary.
That leads me to my next thought: it would be interesting if we could build a Larrabee [wikipedia.org] like GPU using many small and fast RISC V cores optimized for SIMD with a fat crossbar, and memory controller. That would give us a hybrid CPU-GPU system that can be programmed as one sees fit. So things like 3D, 2D, video encoding/decoding, SDR, ray tracing, scientific computing, and other GPGPU stuff can be done in easy to load/modify software modules. Fixing GPU bugs or expanding functionality would be as simple as downloading a new module build or hacking the code yourself. Might not be as blazing fast as today's GPU's but it would be completely programmable. And bonus points if the compiler is the same for CPU/GPU with different optimization paths. Start small with 4-8 cores and work up from there.
You would need a lot of engineering talent and tons of cash to get it working. Something I don't think we will ever see unless some billion dollar company/nation/individual invests in such an endeavor. Though we could get as far as the open cores project and build a much more simple SoC. But it would be a tough sell if it can't do simple things like play a youtube video or smoothly render a webpage. Something you need a 1+ GHz CPU for nowadays.
(Score: 0) by Anonymous Coward on Monday January 30 2017, @09:51PM
The linux kernel runs on just about everything under the sun.
(Score: 0) by Anonymous Coward on Monday January 30 2017, @11:48PM
*WHOOOOOOOooooooooOOOOOOOOSH!*
(Score: 4, Insightful) by VLM on Monday January 30 2017, @03:57PM
However, is the right way to go about furthering this technology to build low-powered microcontrollers, or is it to start at a level of computing that is more general purpose?
silicon is evolving faster than humanities applications for it, sooner or later the marketplace is inevitably going to be nothing but five cent microcontrollers as far as the eye can see.
I sometimes feel weird using a rasp pi to speak I2C to some devices, using a GHz to do a Z80's job or an arduino's job, but they're cheap and everywhere so thats going to be the future of computing. You want to blink an LED in 2030 its gonna take terabytes of IDE and libraries and 50 pages of OS dependent code and bad pushes out good so it'll be the only option in the marketplace, but on the bright side it'll be in a SOT-23 package and draw nanoamps and cost five cents so who cares?
Says the guy writing code in interpreted Lua on his ten or so dollar ESP8266 dev board last night. Today I can look at the clusterF of having to recompile the whole Lua based system just to add a simple driver for a magnetometer (long story) but at least today I can still say "F it" and overwrite it with arduino IDE pure C, which I'm probably gonna end up doing.
The trend of the last half century of making the simple even easier and the complicated more impossible than ever is only going to increase, which is annoying.
(Score: 4, Insightful) by The Mighty Buzzard on Monday January 30 2017, @04:43PM
The hell you say. Run Gentoo and say that again after a large update that includes Firefox, the kernel, mesa, llvm, and wine. I dunno if anyone's coined a law about it yet but code's inefficiency will always outpace silicon's efficiency.
My rights don't end where your fear begins.
(Score: 3, Informative) by Azuma Hazuki on Monday January 30 2017, @07:42PM
Yyyyyup. I lucked out this weekend and got my hands on an Elitebook 8470p...and a spare i7-3632QM CPU :D Chromium took three friggin' hours to compile, Libreoffice an hour and a half...that's scary.
I am "that girl" your mother warned you about...
(Score: 3, Informative) by tonyPick on Tuesday January 31 2017, @07:05AM
Around here (after one very loud rant quite a few years ago) that's known as Mehra's Law - "There is no amount of raw hardware performance that cannot be pissed away by shitty software."
(Score: 3, Interesting) by sgleysti on Monday January 30 2017, @07:00PM
You want to blink an LED in 2030 its gonna take terabytes of IDE and libraries and 50 pages of OS dependent code ... but it'll be in a SOT-23 package and draw nanoamps and cost five cents
It's not exactly what you were thinking, but the PIC10F322 in a SOT23-6 package is $0.39 to $0.54 depending on quantity.
http://www.microchip.com/wwwproducts/en/PIC10F322 [microchip.com]
Not only have I used this chip to PWM an LED and generate various testing waveforms, it's handy for a ton of other things as well. It has an internal oscillator, an ADC, two PWM modules, a configurable logic cell, a complementary waveform generator (great for driving H bridges), a numerically controlled oscillator, and two timers. I taught myself to program microcontrollers from its datasheet and related references. Fun stuff.
Like you're saying, these things will just get more featureful. However, I doubt that there will ever be a time when you cannot program them in assembler. Arduino is already similar to what you were suggesting about using libraries to make microcontroller programming easier.
(Score: 2) by VLM on Monday January 30 2017, @08:32PM
Whoa...
These new PIC10F32X variants are based on the standard mid-range architecture (vs. the baseline for the PIC10F2XX family)
I made a little dev kit to play with the 10F2XX series some years ago and I see time marches on! That's quite a featureful little chip you've found there!
A 555 timer is about the same price now. A couple years back a 10F2XX cost more than a 555 but you could program it and reprogram it and it takes zero passives for a simple timer so arguably it came out ahead. The 10F2XX series being a bit crude and limited its a fair comparison...
I actually invested in a SMD ZIF socket for my 10F2XX project to make a little dev board thingy and I should see if its pin compatible with the 10F3XX series. Otherwise if you don't use a ZIF socket programmer you have to solder in a PICKIT header so you can program the darn thing.
I never did anything terribly useful with the 10F I was going to develop a little I2C talker that could squirt out config to something like a DDS oscillator so it kinda held its programming. You can buy COTS kits to do that. Much more elegantly (although larger) than my design. The qrplabs progrock is basically what I was going to make although much smaller of course, and an older generation DDS oscillator, for obvious reasons.
A lot of the fun of the 10F2XX was simply using the weirdest smallest little microcontroller I had ever used, just because. I could solder together something the size of an altoids tin that contains maybe 50 processors although I have no idea what I'd do with that...
(Score: 2) by sgleysti on Monday January 30 2017, @09:19PM
I used microchip's programmer adapter to program the SOT23 chips:
http://www.microchip.com/Developmenttools/ProductDetails.aspx?PartNO=AC163020 [microchip.com]
I just looked at the datasheets, and as far as ICSP is concerned, the 10F220/222 have the same pinout as the 10F320/322. I too chose this chip because it was so tiny and inexpensive. Amazing to see what something so small can be used for.
I'm also really fond of the 12F1571/1572.
(Score: 0) by Anonymous Coward on Monday January 30 2017, @04:59PM
Does it have SIMD support equal to modern Intel SSE/AVX or ARM Neon? If not it's just a toy.
(Score: 2) by TheRaven on Monday January 30 2017, @05:30PM
sudo mod me up
(Score: 0) by Anonymous Coward on Monday January 30 2017, @05:36PM
I have, but there's a big difference between publishing something and it being in a shipping CPU. Which currently-available-to-buy Risc-V chip has these SIMD extensions?
(Score: 2) by TheRaven on Tuesday January 31 2017, @09:54PM
sudo mod me up