But the SPARCs you mention have their drawbacks. LEON is not that competetive in the high end (in order single issue, low clock freq) and T1/T2 are only cores (i.e. without interesting "uncore" stuff) and not that good as general purpose "desktop like" CPU.
I have much higher hopes for RISC-V, the community is really booming and the architecture is better than
SPARC.
I say this as a former Gaisler employee and SPARC proponent :-)
"But the SPARCs you mention have their drawbacks. LEON is not that competetive in the high end (in order single issue, low clock freq) and T1/T2 are only cores (i.e. without interesting "uncore" stuff) and not that good as general purpose "desktop like" CPU."
There's definitely drawbacks. I've just not even seen interest in embedded sector of FOSS for SPARC even with open cores. I wouldn't argue stuff like Leon4 in its current form is suitable for replacing a Core Duo or anything. Yet, that it's suitable for many apps but ignored for all apps by FOSS in favor of proprietary MCU's/CPU's might reveal a problem on their side.
Far as RISC-V, the community is booming and I have high hopes for them. Maybe they'll make something. My recommendation was to create Pi-like board with RISC-V SOC by licensing Leon3 or Leon4, replacing SPARC components with RISC-V, and getting the rest w/out effort. I think we would anyway given it's designed for easy configuration/modification. In parallel, continue developing clean-slate replacements. Gives us a rich, interim product to use with full FOSS down the line. What you think of that idea?
I agree that LEON is overlooked in the MCU market.
Wrapping up one or multiple of the RISC-V cores in GRLIB is something I think would benefit both Gaisler and the RISC-V community and something I have thought of doing myself if I had the time!
That's about half the peer review I need on that given your background. Next I need a SPARC opponent with HW/SOC experience background giving same recommend haha. Might send it to some of the academics.
Another part of my plan was to get academics to build and public domain the source/verilog/whatever so we can benefit from their cheap EDA licensing and shuttle runs. Pick bare minimum I.P. we need, like DDR or PCI, to get SOC's working. Slowly crank them out at many universities to eventually arrive at a platform with ASIC-proven components. Then, startups can just do integrations with whatever little part is custom for them. Much cheaper. Also, I think analog academics doing open, cell libraries would be a good idea at 350, 180, 90, 45, and 28nm. As money comes in, can just shrink from one tech to another using pre-existing I.P. or cells. People could probably use Qflow OSS ASIC flow with 350nm (maybe 180nm) without or w/ little commercial tooling.
Always looking for HW people's review on these things. What you think?
Academics should absolutely open source their stuff to a larger degree and contribute it a common open source community. I don't think LEON/GRLIB will be that community but may be a part of it. OpenCores did not succeed but I have hopes for what's cooking around FOSSi foundation/LibreCores.
Most academic shuttle runs are still at 90nm, or bigger. There are a few reasons for this: cost of runs, cost of tooling (hundreds of k), and the fact that your assumptions about transistor action and modeling are exponentially more complicated at advanced process nodes.
Academics also sign NDAs about the processes they use, and can only make certain things available; the most open is probably MOSIS, but that's absolutely no good for advanced nodes.
I'd say throw low power and advanced anything out the window, demonstrate a working chip, then look for funding to advance it.
I'd agree that most runs are at 90nm or above. Yet, the rest is confusing given I have quite a few papers with competitive stuff done at 45-65nm with some at 28 or 32nm.
So, why you say forget about it or MOSIS below 90nm if academics are getting working chips done that low?
They sign NDAs for the process and get 100-thousand dollar layout packages for academic prices.
If you have a few spare million dollars, you still can't necessarily release a lot of data due to the NDAs - usually they give you models for the processes that are proprietary (and they invested a lot in developing, and so will consider any breach an act of war).
Nick, The larger context of all this issue is defense. So on one side there are the five eyes governments wanting it this way. On the other side(and probably very interested in 100% security), you might have various countries supporting terrorist organizations, terrorist organizations, crime syndicates, russia, china, etc.
Doesn't this context hints to us that 100% security would be much harder than creating some design and manufacturing it using standard fabs?
There won't be 100% security because underlying physics fights you and our field is too new. Best we can hope for is making attacks hard and physical. There's great work in secure HW/SW architectures that should knock out about all SW stuff with effort. Details published in all kinds of CompSci publications. HW, too, far as implementing it correctly with some security properties. The rest, esp tamper-resistence, is still in infancy far as having stuff that actually works.
Now, what we're talking about in this thread is having an ISA, chip implementation, firmware, and SW stack that is not a black box and is under your control. Preferably without built-in, convenient spyware. Mainstream FOSS users are currently so far away from this that it's a reasonable, interim goal. So, I had to bring up SPARC as an addition to the list that has side benefit of reducing legal risks.
Ok. Maybe that may work. But what about legal risks? extra-legal risks(like vanishing in the dead of night) ? soft risks - how would the wife of someone who is just the customer will respond when guys in black suits will come to her home ?
Or if you're method will work so well, are you sure TSMC/Samsung will even accept you as a customer ?
Because it doesn't seem like something that could scale without the legal/political side and that's really much harder than the tech(which is hard, no doubt).
Many big players have vested interest in hardware platforms that are not tampered with out-of-the-box, or open to easy tampering, by their adversaries.
The Chinese have an interest in having a hardware platform that doesn't have NSA code baked into it; the US government and major US corporations likewise want hardware that doesn't phone home to Unit 61398. The Russians don't want either but probably have their own ambitions. Etc.
I think that in the next few decades it will become quite accepted that you choose your platform based on who your perceived "adversary" is. If you're concerned about the NSA, you buy a system that's Chinese from soup to nuts. If you're concerned about the PLA, you buy from a vendor with the US Government seal of approval.
It remains to be seen -- and in truth, I am somewhat pessimistic -- about the availability of a hardware/software ecosystem that doesn't require compromise. Hardware fabrication is a capital intensive industry, and capital intensive industries are pretty vulnerable to coercion by the governments in which all their capital equipment sits. ("That's a real nice chip fab you have there. It'd be a shame if something...happened...to it. Maybe you want to reconsider your offer to help us out?")
An open architecture that you could get from any number of vendors, and perhaps use to keep the vendors honest, would be a huge step in the right direction, though. But the underlying problem is extremely hard.
> Hardware fabrication is a capital intensive industry, and capital intensive industries are pretty vulnerable to coercion by the governments in which all their capital equipment sits.
If the spec is open then it should be possible for a fancy lab to verify that the hardware is manufactured to spec, right? So if you have it manufactured in Taiwan but then have random samples verified by labs in the US, Japan and Europe, defectors could be detected. Then the manufacturer would have to risk destroying their business by getting caught inserting a backdoor.
But the SPARCs you mention have their drawbacks. LEON is not that competetive in the high end (in order single issue, low clock freq) and T1/T2 are only cores (i.e. without interesting "uncore" stuff) and not that good as general purpose "desktop like" CPU.
I have much higher hopes for RISC-V, the community is really booming and the architecture is better than SPARC.
I say this as a former Gaisler employee and SPARC proponent :-)