Firstly, please take this in the manner it’s given: as some questions concerning real issues that I strive to solve, not as a complaint or a casting of shade on the project.
When I heard about the SiFive unmatched, I immediately became excited. I have wanted for some time to put together a workstation that is seriously and completely under my control. Obviously, the issue of a video card is still an issue (SiFive just doesn’t address that … which is fine). I actually have a VT320 around here somewhere. :).
Anyways, someone I trust at the FreeBSD project (because I haven’t had time to do more of my own research) has identified the following as not free and open in the SiFive Unmatched:
The Firmware the trains the DDR memory
The Firmware that trains/configures the PCI bus
The PHY (might be talking about the hardware) and HMAC for the included NIC
(quoting more directly here) plus all the other ancilliary chips that aren’t the CPU or it’s secure enclave (intel ME equivalent).
I’d certainly be disappointed if there was something similar to IME (Intel Management Engine) that we don’t control on these chips. But as for this … and the others, I suppose I’m asking if this is true and if this can be addressed. I don’t necessarily need to build my own computer, but I want a computer for which I know and control all of it’s components… and I’d like it to be more modern than things I can build in my basement (like my multiprocessor 68040 project).
The Unmatched is not intended to be free/open hardware, unlike the Unleashed. The u74 core in the unmatched is SiFive proprietary, and source for it will not be released.
Yes, the DDR controller, along with other analogy bits are licensed. We can’t release programming info for the DDR controller. But we can release obfuscated sources for the code used to initialize it. I don’t know anything about PCIe firmware.
There is no secure enclave. There is a S7 management core, similar to the unleashed, but that is fully under the control of user code. I believe the bootloader puts it in a wait-for-interrupt loop that never exits as we never send interrupts to it.
I’d appreciate someone looking into the PCIe allegation, but…
That information does sincerely help. Obfuscated sources are better than no sources, but it also misses the mark by a fair margin.
So… drawing a conclusion from what you say, at the very least, there exist no modern performance memory controllers… or is it no modern memory compatible controllers? Is this a patent or a secret issue?
A certain joy, of late, has been playing with retrocomputing. From my Commodore 64 days, I understood every byte of the computer. From my Amiga days, there was a lilttle more mystery — and I didn’t exactly like it. I now have access to understanding of all of my Amiga.
I don’t care about the very latest bells and whistles — but I dearly want to be in control of my whole computer.
I’m not a hardware guy. I think the DDR issue is one of cost. DDR controllers are so complicated, and so expensive to design, that no one can afford to create an open one. Plus there is the issue that every couple of years there is a new DDR standard, which means the DDR controller has to be redesigned every few years which adds to the cost. And there is the issue that a DDR design that works for one process node at one fab doesn’t necessarily work for another process node at another fab, which means more redesigns and more cost.
For PCIe, there is an asmedia pcie switch chip on the board. Maybe there is firmware inside that chip. Otherwise, as far as I know, there is no pcie firmware. But again, I’m not a hardware guy.
We have released a complete source tree that can be used to build a linux distro that runs on the unmatched. If you care about this issue, you are welcome to look at it yourself.
If you want a fully open design, I would suggest looking at lowrisc.org, but they haven’t managed to produce any ASICs yet as far as I know.
Again, your reply is helpful. In terms of the DDR controller, recall that a credible open source CPU wasn’t possible until it was. DDR3 lasted for somewhere around 5 years. I also don’t get the feeling that each increasing DDR generation is giving us the boons that the initial change from static RAM to DDR did — and that as we reach the point of diminishing returns, the plausibility of these things grows closer to reality.
Are you part of the project, or just replying? Is there someone better I can talk to? Are there any other people talking about the same ideas I have been?
(and really, really, just-to-emphasize … I’m not trying to throw shade here. I’m on board with the premis and am vary likely to order a board once a few more people pay me — but that doesn’t stop me from wanting more)…
If you want a completely open RISC-V computing device then you might want to look at the “Precursor” project. Naturally, it is lower performance than the Unmatched.
I’m a software guy that thinks customer questions should be answered as best as possible, and isn’t afraid to make mistakes in public. I am not directly part of the Unmatched project.
SiFive doesn’t sell directly to consumers. If you are a corporate customer, then you can talk to sales and get better answers. Otherwise, answering questions here is mostly a volunteer activity for SiFive employees that are willing to do it.
Note that SiFive is an IP Core company, not a computer company. It isn’t part of our business plan to make chips. And it isn’t part of our business plan to solve the open hardware problem. Our subsidiary OpenFive does make chips, but they aren’t trying to solve the open hardware problem either. You would be better off looking at various university or non-profit companies for that. I mentioned lowrisc. chipsalliance.org is another one, and openhwgroup.org is yet another one. But I don’t think that anyone can make fully free SOCs today and it may be a while before this problem is solved.
Besides the obvious issue that there is non-open IP required to build a SOC, and other non-open parts required on the board, there is also the problem that we need non-open tools to convert RTL to the actual chip layout. theopenroadproject.org is working on that problem. We also need non-open fabs to build the chip. This part will be even harder to solve.
If it is just the non-open software blobs that you are worried about, I would suggest opening an issue in sifive/freedom-u-sdk and asking about the blobs.
Bruce mentioned an FPGA solution. There are multiple open RISC-V cores that can be compiled to run on FPGAs, some of which can be compiled by open source tools. Though you still need to trust the company that designed the FPGA, and the fab that built the FPGA.
At least the people who design and fab the FPGA have absolutely no idea what bitstream you will load onto it, or what will be connected to what pins, or even with a growing number (including iCE40 and just about Xilinx 7-series I think) what software was used to create the bitstream. So it’s got to be awfully hard for someone to compromise it.
Thanks jimw. I do appreciate the candor. But if the SiFive unmatched isn’t for people looking for open hardware control, then what is it? Simply allowing you to have a RISC-V workstation itself is pretty weak. I suppose machine code diversity is a thing — but it’s a pretty small thing. It’s not like we’re looking at superiority in any other realm yet — not power, power efficiency (by whatever measure), speed or throughput. AFAICT, the one really big reason to be looking in RISC-V’s direction is the open nature.
I mean … all the evidence that winning on technical points doesn’t deliver success is in — we use the bastard extended extension to the power silly of 8086 processors as our by-far most popular instruction set. And our runner up is ARM — which is eeking out it’s space by some quirky longevity and by being hands-down better.
If everything started being ARM tomorrow, would RISC-V still have a place … if not for openness?
And bruce… heh. Yeah… it’d be hard, but I assume the smart attacker would hit the easy points — wait for the PHY to get a link and try to phone home or whatever. The point is that there are a very large number of very smart people in the world and the scourge of not (truely) owning your own computer is only going to get worse.
The Unmatched board is proof that our U74 cores work as advertised. And it helps solve the chicken and egg problem that we can’t sell cores if there is no software for them, and people can’t write software if there are no cores to run on. Plus it gives us some nice publicity of being the first to ship a RISC-V Linux capable board that has all of the peripherals and connectors you need to build a PC. Assuming that we do ship it soon of course, before our competitors can catch up. Having a physical board also helps solve some practical issues. If you want to be an official Debian architecture port for instance, then they must have a certain number of physical boards on hand that they can use for building releases. QEMU doesn’t count. The Unmatched board will solve this problem. Other distros have similar rules.
RISC-V only guarantees that the ISA is open. It never guaranteed that the hardware is open. There is of course a market for open hardware, it just isn’t clear how to make money from that. There is a very large capital expense required to design open hardware. Who pays for that? The Venture Capitalists funding SiFive would like to earn their money back, and that is hard to do if we are giving all of our IP away. Meanwhile, there are universities and non-profits working on the open hardware problem. And I expect SiFive will help as much as we can.
There is still an advantage of an open ISA even if the hardware isn’t open, which is that you aren’t tied to one company. ARM ISA is controlled by one company. x86 ISA is controlled by 2 companies. RISC-V is controlled by a foundation that any company can join and contribute to.
I think you unfortunately might have missed the mark on what SiFive is offering here.
Because the Unmatched uses a RISC-V CPU based on the open ISA, does not necessitate an open platform, let alone a CPU.
Jim summed it up perfectly, there’s a chicken and an egg problem with getting the ecosystem going (no software/no hardware).
If you’re not looking at the Unleashed as a dev or hobbyist platform, perhaps the options Bruce offered would be better candidates for your requirements.
I appreciate the good discussion. I had rather wondered if I got a bit too passionate there, but the responses are good… so I suppose I’m on target.
As the great bard said: “You can’t always get what you want…” so maybe I’ll get what I need right now. Heh. Shipping would be nice :).
In all seriousness, I’ll probably get one. I’m not looking for my daily driver, but I will probably run the big monitor in my shop from it — and use it down there. It will probably run FreeBSD, TBH. I’m not really “on” the linux bandwagon. I suppose it shows I don’t march to other drums.
But again… (as a last shot across the bow) your last argument was again economic — as if open doesn’t pay. Except it does. I accept the encouragement. It would be nice if we could get at least as much documentation as is possible to let us hack on these pieces … like the DDR interface. Open doesn’t make sense … that is, until it does.