While this looks like a great board, to get more adoption a cheaper board is needed. Like the RaspberryPi line, though it’s not expected it could be that cheap.
Something like:
2 x 64 bit cores
4 x USB, (at least 2 of which are >=5Gbps)
4GB of RAM
SDXC slot
SPI for boot code
eMMC slot, (like what Pine64 uses, little carrier boards for 32GB - 128GB of eMMC)
and perhaps a M.2-2280 M-Key with 4 lanes PCIe
Even leave off the Ethernet. That’s what 1 of the USB 5Gbps could be used for. Leaving the choice of Ethernet or wireless, (WiFi or LTE), to the user. (There are even several models of USB to 2.5Gbps or 5Gbps Ethernet adapters… so including only 1Gbps is actually a downside.)
And in the mater of graphics, their are M.2 graphics cards. Perhaps not many, and may be expensive… But, since the current state of the art for open source graphics is quite limited, pass the buck at present. Either use the M.2 slot for graphics. Or try one of the many DisplayLink USB, (5Gbps port of course), to HDMI, or DisplayPort adapters.
While their might be hundreds of people asking for more cores, more memory, more built in ports like Ethernet. All of those raise the cost. I’d suggest something cheaper to begin with. And if it sells okay, then you can consider more features.
Having working in embedded computer development, (95% software, 5% fixing the hardware mistakes of the chief engineer :-), one thing that helped was the availability of chips in a type of package that you could use with a socket. For example, gull wing packaged chips are NOT suitable for chip sockets. (Not that I know what chip package these RISC-V CPUs or support chips are available in…)
So @bruce, I would add to your suggestion: Either make the chips available in packages that can be used with sockets. Or make available both types of chips.
@bruce, thanks for reminding me, I’d forgotten about that.
What I really meant was easy sockets. Like the P-LCC, (Plastic), Leaded Chip Carrier. But any chip package that does not take up much more space when used with a socket, than without. So initial releases can be socketed as the chip develops. And mass production boards can have chips soldered.
I don’t think there’s any particular need for a QFP socket to be much bigger than a PLCC socket. A couple of mm, obviously, because the QFP leads do stick out. The one I showed is much bigger because it’s breaking it out to standard 0.1" DIP, which is the most friendly for prototyping where you’re developing the functionality of the final product but not the form factor.
QFP seems friendlier than PLCC for hand soldering (and unsoldering). Or I’m wrong on that?
Good ideas here. I second the suggestion for a cheaper alternative like @Arwen describes above.
@bruce can you give us chips with only the processor, none of the peripherals? Almost everything today has gone the way of the SoC. How about making available a SiFive CPU chip, akin to the 6502 from years ago. That would enable some really novel developments.
@pds, That brings up another point I have been thinking about.
Since the RISC-V processing units are in a state of flux, (more cores, additional optimizations, etc…), perhaps breaking out the “stock” I/O would simplify the CPU chip development.
For example, if a single PCIe 3.x lane is reserved for the “stock” I/O, the CPU can be configured to understand those devices. Like the first 3/4 for initial boot / BIOS devices;
SPI flash
SDXC card
maybe an eMMC or Universal Flash Storage, (aka UFS)
USB, (but, just a few ports. May be 1 x USB3 speed and 2 x USB2 speed)
UART
RTC with battery connection
2 x I2C buses,
2 x Fan control
2 x temperature reading ADC
etc…
The stock I/O would be limited to the minimum needed for use.
I put forth this as a RISC-V “South Bridge” chip. Their might be several types. Some for a RaspberryPi like single board computer. Others for a more complete desktop. And some for embedded or controller uses.
Obviously additional I/O would be available. Most desktop users would want SATA, PCIe lanes, (perhaps some for NVMe), networking, video, more USB, etc… But those all could be satisfied from either PCIe -> X chips, or multi-function chips, (also PCIe).
In my opinion, the benefit of separating the CPU from “stock” I/O out weighs the additional board space and additional complexity. One reason I say that, is that if an issue arises with one, (bug or lack of specific feature), you only work on, and replace that one chip. The other stays the same.
fu310 chips are available for purchase, 5 USD each, sold in packs of 5 for 25 USD, if you want something more 6502 like than a hifive unmatched. These can’t run linux though.
Sipeed has just announced a board that can boot linux for 12.50 USD, but definitely a low end board, one core, less than 1GB of RAM. Probably not available for a few months, but then we have to wait for the unmatched too.
Not clear how they can make a profit at such a low price point, unless maybe someone else is fabbing the chip in the millions for some other project.
As SiFive’s IP portfolio matures (you’re not there yet), I suggest that it try to work with the RISC-V community to de-risk and lower the cost of the following customer adoption acceleration strategies:
Strategy #1: Develop standardized RISC-V carrier boards for COM-HPC (both the client and server specs)
With standardized RISC-V COM-HPC carrier boards, IP demonstration products from companies like SiFive (e.g., future versions of HiFive Unmatched) would only have to develop the company’s product-specific but spec-conforming System-on-Modules (SoM). No re-inventing the wheel by RISC-V companies (and academics or others) for the IP in the standardized RISC-V COM-HPC carrier boards. Maybe you could go even further and have standardized RISC-V COM-HPC SoMs where you could drop in new spec-conforming chips. Saves everyone a lot of hassle and expense. Try to standardize the ubiquitous IP if possible and let every company, academic group, etc. showcase their secret (or open-source) sauce in the SoMs.
Strategy #2: Develop and maintain a RISC-V fork of Intel’s open-source Clear Linux distribution.
Seriously, replace the Intel x86_64-optimized bits with RISC-V-optimized equivalents. I think CL’s design is outstanding. Secure, stateless, very performant.
@pds I can’t give you anything – I’m a private individual living at a remote beach in New Zealand.
Or, at least, I could do it by contacting SiFive’s sales department and paying them to build such a chip, and so could you, if you thought you could sell enough of them to cover the costs. SiFive is not in general in the business of building their own chips to sell. That’s the job of SiFive’s customers.
It seems unlikely you would sell enough to break even.
I’ve actually recently bought a couple of 65C02 chips. They’re currently $8 each and run at a maximum 15 MHz.
I’m not sure a RISC-V chip with no internal SRAM or cache and enough pins for a complete non-multiplexed address bus and data bus would go any faster or cost any less – especially if you wanted a 32 bit wide data bus and 24 or 32 bit wide address bus. That’s a lot of pins and a big expensive package – assuming you want something you can breadboard or hand solder easily.
That’s limiting you to 18 MHz before allowing for delays in your wiring and address decoding.
I think the answer is that it could be done if you’re happy with 6502-level performance. Or lets say 1980s Macintosh or Archimedes (ARM) performance.
If you’re happy with that then you’re much better off loading a RISC-V soft core into a cheap off the shelf FPGA. They have lots of I/O pins for external address and data buses, and will run at 50 to 100 MHz, which is much more than you can use due to the limitations of external ROM and RAM.
@dkhayes117, yes I had seen that article. And I wish them good luck.
However, the PicoRio does not seem to have active external group participation. So, whether it is in active development and will be released on the rough schedule they outline, or not, is unknown.
For example, I was unable to find out if the PicoRio design is intended to have USB 3.x ports. In my opinion, at least 2 should be included. This would allow the use of network adapters, (Ethernet, WiFi or LTE), or DisplayLink for video as the user desired. Then at least 2 other USB ports, for keyboard, mouse, etc…
The original RaspberryPi was able to avoid the USB 3 speed issue as it included built in graphics. And back then, network speed of 100Mbps Ethernet was okay. Same with WiFi adapters over USB 2.x.
Plus, I suggested a M.2 2280 with 4 x PCIe lanes. That adds both storage and graphic options, (though perhaps not the best graphic options).
It even has a primitive graphics option. It’s only 1080p @ 30hz on the HDMI port, and uses the DSP for graphic processing. Later they are thinking of using a PowerVR graphics options, (not open sourced). In someways, I’d almost like to see a dual core 64bit RISC-V with vector instructions used as the graphic processor. Later, additional graphic instruction sets could be added. Creating a whole new, open source graphic engine.
The CPU is only a dual core, but is 64bit and does include the MMU for normal Linux usage.
Won’t be available for general orders until September, 2021.