Domain: greenarraychips.com
Stories and comments across the archive that link to greenarraychips.com.
Comments · 15
-
Re:Ultra SoC
We should build a matching MIDI violin for it!
Also, this , if you want something really small and power-efficient.
-
Re:Obsolete computer architecture
WTF? Up to 205W, man that would glow without liquid cooling.
Fully agree they're stuck on a track of blindly making it bigger.
networked processors
http://www.greenarraychips.com...
144 separate processors in a chip, all running, well under 1W
Chuck Moore's been doing it for years, nothing new, and it doesn't glow in the dark. -
GreenArrays
So this is basically like GreenArrays only less powerful CPU's, is clocked, and is unavailable for purchase.
http://www.greenarraychips.com... -
Re:The US tech industry
That's the entire CPU industry minus these guys.
What clock speed, no clock !!
144 processors in one chip for $20Moore's Law (Chuck Moore)
Less is Moore -
Reflections on Trusting Trust; Simplicity & Fo
"not really, until you can 3-d print it yourself and then verify with an xray will security be verified."
What if both your 3D printer and X-Ray data analysis software are compromised? See also:
"Reflections on Trusting Trust" by Ken Thompson
http://cm.bell-labs.com/who/ke...
"The final step is represented in Figure 7. This simply adds a second Trojan horse to the one that already exists. The second pattern is aimed at the C compiler. The replacement code is a Stage I self-reproducing program that inserts both Trojan horses into the compiler. This requires a learning phase as in the Stage II example. First we compile the modified source with the normal C compiler to produce a bugged binary. We install this binary as the official C. We can now remove the bugs from the source of the compiler and the new binary will reinsert the bugs whenever it is compiled. Of course, the login command will remain bugged with no trace in source anywhere ... The moral is obvious. You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code. In demonstrating the possibility of this kind of attack, I picked on the C compiler. I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode. As the level of program gets lower, these bugs will be harder and harder to detect. A well installed microcode bug will be almost impossible to detect."Still, the more angles you look at something from, the more likely you might detect some discrepancy... Like excess power usage, processing delays, slightly different electromagnetic signatures, etc...
In any case, the less you want, perhaps the easier it is to secure. Look into creating or using Forth chips for simplicity... The less gates you need, and the less cycles they need, the easier it would be to make your own hardware from scratch, even from discrete components if it is simple enough.
http://www.colorforth.com/
http://www.greenarraychips.com...For software more complex than Forth that is still fairly understandable from the ground up, see also the FONC project by Alan Kay as well as Squeak on bare metal.
http://www.viewpointsresearch....
https://www.google.com/search?... -
Re:Great, so they reinvented
People are still doing it, or did you not get what this article is about?
Or did you never catch any hint (given in this thread and many others) about http://www.greenarraychips.com... ? -
Re:Moore's Law
-
Re:Moore's Law
36-core is immense!
-
Re:Mind blowing
Not all people are abstract today.
That is easily in the top 10 most useless architectures I've ever seen.
-
Re:Mind blowing
Any nice things I can say about it would go over you yong'ins heads.You're all abstract now - frameworks and whatnot - Java and shit like that
.... do you kids even know what a register is? I think not .. -
Re:Just in time too.
As an addendum to the parent (I, too, have a background in ASM programming): You're working at such low level of detail that any application of non-trivial size becomes extremely difficult to write truly effectively. You just can't keep so many details in mind at once. And when you need to work as a team, not alone, interfacing code becomes a nightmare. So of course you abstract your assembler code. You define interfaces, develop and use libraries of common application tasks, and just generally structure your code at small and large scales. But at that point, you are starting to lose the advantage of ASM.
-
Re:Work smarter, not harder.
Moving to clockless.
Minimal use processors
That doesn't make sense. Or rather, makes multiple possible senses at once. Could you elaborate on what in particular do you have in mind?
-
Green Arrays 144 computers on a chip @ 20 USD
"The GA144-1.20 chip, with 144 self-contained computers and software-defined I/O, is available in a 1cm x 1cm, 88-pin QFN package." $20 / each, minimum order 10 (as far as I know): http://www.greenarraychips.com/home/products/index.html 200 USD buys you 1440 cores...
-
GreenArrays does something similar
http://www.greenarraychips.com/
Their GA144 chip has 144 complete computers on one die, and the power requirements are extremely low. The F18A CPU's are completely asynchronous, requiring no clock. While their target market is mostly embedded systems, there's no reason why they couldn't be used elsewhere. -
green array chips - 144 cores per die
tiny Forth-based computers with up to 144 cores on a chip, and that's in a low tech 180 nanometer process. Each core has a rather fast ALU but just a few hundred(?) bytes of memory. Seems closer to neurons than the thing that guy is making where each core is a 32-bit ARM processor.
link.