
J-core Open Processor - CarolineW
http://j-core.org/?HN_20160716
======
raverbashing
Interesting that's still and nommu system. Maybe as soon as the patents expire
we can get the mmu system.

"Numato provides a GPL-licensed python3 tool to flash bitstreams onto their
board. [TODO: port to python 2]"

No, please. Don't even bother

~~~
nickpsecurity
What patents? All kinds of CPU's have MMU's. Implementations go back decades.
Cant imagine a patent risk for MMU's.

~~~
raverbashing
Patents for SH4 as described in the article (this is an SH2)

------
nxzero
>> " Open source hardware can be manufactured cheaply (about 3 cents per
processor) audited for NSA backdoors or vendor backdoors or decade-old
exploitable firmware bugs, and built without hidden extra processors in things
like storage devices and USB controllers easily repurposed into spyware."

Anyone familiar with J-Core able to expand on the how an audit would be done
end-to-end?

Seems like it would be much harder to do in practice than in theory.

~~~
stephen_g
You can audit the code, compile, synthesise, place and route the design, tape
out masks, send it to a fab, decap a few of the chips you get back and look at
it under a microscope. You should be able to compare that to the masks to
verify the design hasn't been tampered with.

It's harder to audit ASICs that other people have had fabricated without
having the exact same standard cell libraries, tooling versions (optimisations
change over time), knowing what optimisation settings they used, etc. to be
able to prove the masks came from the same code.

~~~
brianwawok
Is spot checking good enough? Wouldnt you need to follow every trace?

~~~
olympus
In hardware, implementing a backdoor that provides a reasonable level of
functionality is _probably_ going to cause a visible change to the
layout/routing, kind of like a software backdoor is going to change the hash.

I say probably because it's possible that advanced actors like the USA and
China have developed tools that add features (backdoors) while making the
visual layout look very similar. Then you would probably only find the
backdoors by "fuzzing" the chip like you would a piece of software.

~~~
ashitlerferad
There are hardware backdoors that require only dopant-level changes, see the
second comment here:

[https://lwn.net/Articles/688751/](https://lwn.net/Articles/688751/)

~~~
digi_owl
It feels like trying to fend of anything but automated drive-by attacks online
will be a fools errand.

------
npx
Tremendous work as always from Rich Felker, Rob Landley, & co.

------
analognoise
I'm interested, but mostly in the part where we get to silicon - implementing
yet another CPU in VHDL isn't all that uncommon.

What about the "to silicon" part of this equation is out there now?

~~~
tlrobinson
In this talk
[https://news.ycombinator.com/item?id=12101908](https://news.ycombinator.com/item?id=12101908)
they said their toolchain can output layouts for the CPU on silicon, and it
would cost about $25,000 to have photomasks made, and I think about $0.50 per
chip.

~~~
analognoise
I haven't seen that part of their toolchain; that's where I'm interested.
Also, seeing a successful test of this toolchain in working silicon, with a
known vendor and a good process, would be extremely helpful for the community
(if other people are going to get aboard, which I hope they are).

~~~
nickpsecurity
Look up Qflow open-source flow. It's the likely toolchain OSS projects will
use. Combines Yosys front-end, ABC backend, and custom tool (Qrouter) for
routing. Worth evaluating.

~~~
analognoise
Yosys is a Verilog front-end; this is being designed in VHDL.

It looks like there is a translator, but I'm unsure about its license, source
availability, and capability.

------
CarolineW
In the interests of full disclosure, this was submitted earlier here:

[https://news.ycombinator.com/item?id=12103471](https://news.ycombinator.com/item?id=12103471)

However, that submission was incorrectly marked as a duplicate of this
submission:

[https://news.ycombinator.com/item?id=12101908](https://news.ycombinator.com/item?id=12101908)
(video)

But it's not a duplicate - they have different information. This submission is
the web site of the project and has links to files and "how to" documentation.
The second submission is to an hour-long about the project, and while it
contains information, it's fundamentally different.

I don't know why the original submission of this link got marked as a
duplicate - I believe it to have been a mistake.

~~~
sctb
We've unmarked the previous thread as a dupe.

~~~
CarolineW
While I appreciate the action, it's too late. That item has sunk now without
trace, and while karma isn't actually worth anything, it would have been nice
for that original submitter to get the associated karma for finding this, and
not me.

------
lisper
This is really getting annoying. I submitted this same link 14 hours earlier
([https://news.ycombinator.com/item?id=12103471](https://news.ycombinator.com/item?id=12103471)).
It was flagged as a dupe (even thought it wasn't at the time) and killed. (It
has since been unflagged, but of course it's too late to save it now.)

~~~
CarolineW
I agree with you entirely, which is why I resubmitted it and made the
extensive comment[0] about why it is not a duplicate, and deserves to be here
in its own right. If I could gift you the karma I would, not that it's really
worth much, to be honest.

The current method of handling duplicates is quite simply not working.
Consider the multiple large discussions about Google deleting a blog without
warning[1][2][3].

HN needs a way to merge items, not simply mark some as duplicates, which kills
the item, and any discussion on it then sinks without trace. There must be a
better way.

[0]
[https://news.ycombinator.com/item?id=12105922](https://news.ycombinator.com/item?id=12105922)

[1]
[https://news.ycombinator.com/item?id=12097063](https://news.ycombinator.com/item?id=12097063)

[2]
[https://news.ycombinator.com/item?id=12099757](https://news.ycombinator.com/item?id=12099757)

[3]
[https://news.ycombinator.com/item?id=12100843](https://news.ycombinator.com/item?id=12100843)

~~~
lisper
Ah, I missed that. Thanks for the shout out!

I've given some thought to how a more fair submission system would work, and I
came up with the following idea:

1\. Dup submissions are treated as upvotes

2\. If an article has N upvotes, the original submitter gets N points (as it
is now), the second submitter (or upvoter -- same thing) gets N/2 points, the
third gets N/3 points, etc. until either the article makes it onto the front
page or some arbitrary point threshold (like 10) is reached.

3\. Every upvote or submission costs one karma point. So you have to have at
least one karma point to submit or upvote. You have to get your bootstrap
points by submitting a comment that gets an upvote. This is to prevent
spamming.

