SoylentNews is people
SoylentNews
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.
(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!*