
Open Source CPU Core Advances - programmernews3
http://www.eetimes.com/author.asp?section_id=36&doc_id=1327129&
======
nickpsecurity
The RISC-V activity is very interesting. I particularly love that they did a
1.4GHz core on 48nm SOI and are working on 28nm level. This knocks out some of
the early, hard work of getting competitive hardware at an advanced process
node. I'd like to see two things in this work: microprogrammed variant with an
assembly or HLL to microcode compiler; tagged variant like SAFE/CHERI
processors with IO/MMU that seemlessly adds & removes tags during DMA. That
would be way better for security-critical applications than most of what's out
there. Multi-core would help, too.

Meanwhile, Gaisler's SPARC cores are commercial, open-source, customizable,
support up to 4 cores in Leon4, integrated with most necessary I.P., and can
leverage the SPARC ecosystem. Anyone trying to do an open processor can get
quite the head-start with that. A few academic and commercial works are
already using it. Plus, the SPARC architecture is open as such that you only
pay around $100 for the right to use its name.

So, Gaisler's SPARC cores with eASIC's Nextreme seems to be the best way to
rapidly get something going. The long-term bet is RISC-V and they could do
well copying Gaisler's easy customization strategy. Might be doing that
already with their CPU generator, etc: I just read the Rocket paper so far.
The solutions built with one can include a way to transition to the other over
time.

~~~
asb
You might be interested in our (lowRISC's) tagged memory implementation. We
describe our planned approach in
[http://www.lowrisc.org/docs/memo-2014-001-tagged-memory-
and-...](http://www.lowrisc.org/docs/memo-2014-001-tagged-memory-and-minion-
cores/) My colleague Wei gave an update at the workshop a couple of weeks ago
[http://riscv.org/workshop-jun2015/riscv-tagged-mem-
workshop-...](http://riscv.org/workshop-jun2015/riscv-tagged-mem-workshop-
june2015.pdf)

~~~
ChuckMcM
It would be great if you also implement ECC. Memory tagging is only as good as
you can trust the memory you are tagging.

~~~
microcolonel
See: rowhammer. ;-)

------
hga
There's good coverage of the June workshop at
[http://www.lowrisc.org/](http://www.lowrisc.org/)

------
brachi
The concept of 'open source hardware' is very interesting to me, however, it
looks so different to software in many ways (e.g.: much harder to understand,
many external dependencies to build it yourself), but maybe is just my
perception due to zero knowledge of so many things.

~~~
ChuckMcM
I think it is just as "simple" as software, except that it is very different.
Also hardware has typically been the realm of patents and software the realm
of copyright when it came to protecting IP. So you can always re-implement
your take on a software idea if it is only copyrighted but you can't make work
alike hardware if it is patented.

Fortunately a lot of hardware patents are expiring which makes the amount of
useful hardware you can implement that much more useful. Over the next 5 years
a huge number of microprocessor patents are due to expire into the public
domain so I am looking forward to a lot of inexpensive hardware coming out of
places like TSMC and China.

~~~
nickpsecurity
Not as simple at all. I can teach people how to write software pretty quick.
Those same people might take years to learn to make working hardware. Without
extensive tool support, it can take them a lot longer as process nodes they
work on get smaller. And you don't know if it works until you shell out big
money for an ASIC prototype and probably do several iterations of that.

The fact that you have to spend more money to test the design is the biggest
difference. Eliminate all the rest with brilliant, well studied people and you
still have that huge cost on a decent process node. Services such as MOSIS
help but only so much. Open-source, gate-level testing and general
verification tools would be a great investment in that they reduce this
significantly. Well, a full suite of open source (or cheap) EDA tools in
general would be nice but that's a whole different, pessimistic discussion. :(

~~~
ChuckMcM
Perhaps it's context? I certainly agree that teaching someone chip design is a
long process, so is teaching them to design a compiler. For me, it is a level
of complexity which cannot be abstracted against. So, for example, it is easy
to teach middle school kids to make working digital circuits out of TTL gates,
but much harder to teach them how to bias a transistor amplifier to operate in
its linear region. Similarly its easy to teach them basic game mechanics with
PyGame or something similar but harder to teach them out to develop inverse
kinematics and shader based rendering in the Unity engine. All about scale.

For me the big difference is that you see a program that does something, and
if you're skilled enough write your own version that does the same thing, even
if it was protected by copyright you "own" that new code you wrote. But if you
saw some hardware that did something, and were skilled enough to implement
that same thing yourself, if it was protected by patent, you couldn't share
your version. Sad really.

Even an open source RISC cpu couldn't be built with out of order execution
until those patents[1] expired. But now a lot of those patents _are_ expiring
and so its a great time to be in the bespoke hardware business.

[1]
[https://www.google.com/patents/US5666506](https://www.google.com/patents/US5666506)

~~~
sliverstorm
Are you sure about that last part? I thought whitebox engineering was
completely acceptable in hardware. Additionally the patent says:

 _A method of issuing and executing instructions out-of-order in a pipelined
microprocessor in a single processor cycle..._

In other words, it's hardly a patent on OoO.

~~~
nickpsecurity
Most of the OoO patents are lapsed. This one is recent:

[http://www.freepatentsonline.com/y2015/0026442.html](http://www.freepatentsonline.com/y2015/0026442.html)

Who knows what it's patent status is. One can always do an in-order design.
Has the advantage of determinism and ease of covert channel analysis.

------
rwmj
Everything to play for - 64 bit ARM is not yet established, and is a complete
change from 32 bit ARM.

------
saosebastiao
So if these comparative benefits are objectively measurable and designs are
freely available, why haven't they been commercialized yet?

~~~
hga
Echoing the other sub-thread, see this lowRISC summary from the introduction
of the workshop:

 _State of the RISC-V Nation: many companies ‘kicking the tires’. If you were
thinking of designing your own RISC ISA for project, then use RISC-V. If you
need a complete working support core today then pay $M for an industry core.

If you need it in 6 months, then consider spending that $M on RISC-V
development._

~~~
microcolonel
Given the estimates for time spent closing a deal with ARM, You could probably
be actively engaged for those 6 months, and get your core in the same time
frame.

~~~
hga
Is this one of the reasons MIPS is still getting design wins? How many years
does it take to negotiate with ARM???

~~~
wtallis
_Is_ MIPS still getting new design wins? I know that existing MIPS SoCs are
still being used all over the place (eg. wireless routers) but is anyone
actually working to put a MIPS core on a 20nm or smaller chip?

