Slashdot Mirror
Own An Open Source RISC-V Microcontroller (crowdsupply.com)
"Did you ever think it would be great if hardware was open to the transistor level, not just the chip level?" writes hamster_nz, pointing to a new Crowd Supply campaign for the OnChip Open-V microcontroller, "a completely free (as in freedom) and open source 32-bit microcontroller based on the RISC-V architecture." hamster_nz writes:
With a completely open instruction-set architecture and no license fees for the CPU design, the RISC-V architecture is well positioned to take the crown as the 'go to' design for anybody needing a 32-bit in their silicon, and Open-V are crowd-sourcing their funding for an initial manufacturing run of 70,000 chips, offering options from a single chip to a seat in the design review process. This project is shaping up to be a milestone for the coming Open Source Silicon revolution, and they are literally offering a seat at the table. Even if you don't end up backing the project, it makes for very interesting reading.
Their crowdfunding page argues "If you love hacking on embedded controllers, breaking down closed-source barriers, having the freedom to learn how things work even down to the transistor level, or have dreamed of spinning your own silicon, then this campaign is for you."
Their crowdfunding page argues "If you love hacking on embedded controllers, breaking down closed-source barriers, having the freedom to learn how things work even down to the transistor level, or have dreamed of spinning your own silicon, then this campaign is for you."
Thanks, EditorDavid, for the welcomed break in leftist propaganda posts that don't matter to nerds.
Now, if you'll excuse me, I have backups to corrupt.
Still, we need more than what the Open Hardware movement can offer to us in FOSH (Free and Open Source Hardware) products. We also need to be able to DIY them, and therefore we need to have access to the right tools so we can create (or, as an option, order) the chips by ourselves ;) Also, we need a tool to (that is easy to) design the chips too, so we can build them later :D
But, at a start, this action is a very good one...
I think you mean the bitstream. Gate-array designs, including the design of this chip, are generally coded at a higher level than a single transistor. One can then compile them to the transistor level as part of the preparation for using a fab to create a chip rather than a gate-array program.
Actually, we would like an Open Hardware gate array. A big problem currently facing us is that the tool chain can't be entirely Open Source because gate-array manufacturers treat their bitstream format as trade-secret. So, we need an open bitstream.
Bruce Perens.
I love RISC-V, I really do but $50 for a chip in bad package is too much. Who can hand solder QFN chips?! $20 is really my limit for a chip of that caliber and it would need to at least be in a QFP package.
The reason stated for the QFN package was to achieve clock higher frequencies (160MHz) but really, 50MHz is enough.
Anons need not reply. Questions end with a question mark.
My personal view is that most western societies seem to be on a trajectory of ever closed groups, while the hardware we live on seems to be becoming more and more open.
Restore the madness of youth's lechery
This will get really fun the day someone manages to make an CPU on his own garage.
I hope this person documents it on the net with videos etc..
... and a sea story:
A fairy tale starts with, "Once upon a time ... "
A sea story; "Hey, this ain't no shit ... "
So, this ain't no shit:
When I trained on electronics in this man's Navy in 1965, I went to NAS Memphis and we worked on a vacuum tube computer that filled up a whole wall. We'd open the windows in the winter because it was HOT in there.
There were two tubes per flip-flop module. The tubes burned out often and we'd have to troubleshoot that.
Our goal was to use a row of toggle switches to turn lights "on" for a binary one, and "off" for a binary zero.
We would load up one register with four bits and the only other register with four bits and then we'd press a switch that could only execute an add and we'd better get the right binary number on the third row of lights.
We started (I shit you not) all of our algebra, trig, geometry, etc. including square root extraction by pencil and paper and then moved into the slide rule age.
The only goddam transistors we saw were the 9-volt radios playing Elvis.
It little behooves the best of us to comment on the rest of us.
If you want hardware open to the transistor level and not just the microcode level ...
Like most RISC processors, RISC-V doesn't use microcode. Microcode is a CISC thing.
"It used to be the case that the computer you bought came with schematics and"
This is just as wrong. Insofar as the percentage of the population that bought these computers was vanishingly small, instead of ubiquitously large. Apples and Oranges. Different day and age and world. There was never a time that ordinary people purchases such things. It's a nice fantasy though, I'll give you that.
Plenty of ordinary people bought the original IBM PCs and PC/ATs. They didn't come standard with the schematics, but you could buy technical reference manuals from IBM which included both the schematics and the BIOS source code for the systems.
Maybe few end-users made use of the available info, but it did ensure that 3rd parties could create a large ecosystem of compatible software, accessories and even competing computer systems. This greatly benefited the end users, whether they cared to dig into the underlying technology or not.
One thing I'm wondering about RISC-V - I can see the motivation behind a new ISA - making it a FOSH platform, but from a market acceptance POV, who will write code for, or adapt a platform based on a brand new ISA, when there is x86/x64, ARM, SPARC, MIPS and Power. Even Itanium, for anyone who's still into VLIW (even though Itanium 3 is more RISC than VLIW). Maybe the FSF/Libre crowd could build for this - maybe port Libre Linux or Minix to the platform.
Another thing I wonder - in the 90s, Sun contemplated a series of microprocessors that used Java Bytecode as the instruction set. Has there ever been a study on the feasibility of such a microprocessor? If we could indeed have a pure Java system - a JVM on a chip using Bytecode as the ISP. Then everything written in Dalvik can run natively on it. On a different note, the name j-core seems to suggest a Java processor, even though it's based on Hitachi's SuperH processor
why bother with an actual chip? there are plenty of open source microcontrollers you can use today with any number of FPGAs.
Cost and performance usually.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
Well... I'm sure you can buy them today too. It matters a lot what the pricetag is however. And even if you quote me an affordable number from the 80's, I still contend that was for a vanishingly small percentage of the population at large. Compared to probably multiple more powerful devices owned at less than 1/10th the price by just about everyone today.
There is huge momentum behind the RISC-V software ecosystem, and you can see a partial list of all the software that has been written for RISC-V here: https://github.com/arunthomas/... Some highlights: Binutils, GCC, OpenOCD, LLVM, Linux, Fedora, Debian, FreeBSD
. We also need to be able to DIY them, and therefore we need to have access to the right tools so we can create (or, as an option, order) the chips by ourselves ;) Also, we need a tool to (that is easy to) design the chips too, so we can build them later :D
But, at a start, this action is a very good one...
SiFive is working on this exact problem--to let DIYs get access to real, packaged, custom silicon based on either your specification or with your RTL. Stay tuned for some announcements coming up at next weeks (11/29) RISC-V workshop.
Yeah, good luck trying to get schematics of your MacBook or Lenovo POS. You are living in lala land. The OP is right: they used to make schematics available in the past.
So, I was going to make a crack that it's a RISC instruction set, so there's not really that much to open, is there?
How's the compiler support - got a decent gcc optimizer for it yet?
Last time an FPGA design was getting me down, it was due to power consumption issues. We could get 4x the battery life with an ARM design as compared to the on-FPGA NEON processor cores we were using.
FPGA was super flexible, but what we really needed was a couple of ARMs and a tiny bit of programmable silicon for the actual custom bits.
Apples and Ataris - they had schematics, but the really interesting bits, graphics and sound processors, were still closed source, proprietary, and a little buggy in the first couple of generations.
The Apple IIe had some custom silicon, but the II/II+ was made up of entirely off-the-shelf components.
Please stand clear of the doors, por favor mantenganse alejado de las puertas
-1, misinformative
RISC-V is an ISA only. It does not oblige implementations to follow any particular microarchitecture.
The religious wars between CISC and RISC were given up decades ago in favor of data-driven architectural decisions. If using sequenced uops solves the problem, they'll be used. For example, here the Cortex-A57 Software Optimization Guide explicitly refers to uops starting in section 2.1: http://infocenter.arm.com/help...
In the future there won't be any CISC or RISC, just wankers.
I had PC schematics, and BIOS listings. I am fairly sure I had Schematics for the Intel 8080 development system, two different 6502 development systems, and a 16 bit National Semis development system which we used as a word processor.
Bill Gates is personally responsible for ending the distribution of schematics.
Sent from my ASR33 using ASCII
It looks like it's time to clean out my bookshelf since I have published Atari ST schematics on the bottom shelf. I second the above poster, obfiscation started as a Microsoft thing.
I've just pulled off the shelf "Atari ST INTERNALS" published by Abacus Software (second edition 1987). From page 13 it goes into those custom chips and their pinouts plus various info on them. From page 271 it has the BIOS listing in assembly with comments.
The high speed is because they currently don't have any on-chip flash (flash being slower to access than SRAM, and typically being what slows 32-bit microcontrollers down). That means this isn't a single-chip solution like most microcontrollers, though they are working on changing that.
Instead of flash, they store their program in the same SRAM used to store data (which makes that 8 kB of SRAM a lot more limiting than it would be on a Cortex M0 with the same amount of SRAM plus 16-256 kB flash). Most microcontrollers use a Harvard architecture with separate program and data memory, allowing instructions to be fetched from flash while performing reads from and writes to SRAM. If they don't do this, I wonder what sort of performance they'll see when they have to make regular reads from a slow flash memory in between SRAM accesses. Or will they just load the entire program into SRAM? That's not going to be ideal in terms of power consumption, requiring a much bigger memory array than they'd otherwise use, something that's going to get worse as they try to compete with larger microcontrollers.
Also, the Harvard architecture has some advantages in security: things can be set up so a very specific sequence of actions has to be performed to enable writing to program memory. With IoT devices, this sort of thing is becoming more important...not an issue at present, with their 8 kB memory, but something to consider when thinking about this thing's future.
Most FPGAs are nothing like open at the gate level. You provide a proprietary toolchain with HDL and it generates... something. The encoding of that something is proprietary, how it maps to hardware resources is a trade secret (though the tools will tell you what proportion of each type of resources are used).
I am TheRaven on Soylent News
The optimiser is largely irrelevant, as most optimisations are target independent these days. RISC-V support in GCC and LLVM is currently undergoing upstreaming, but it's a bit slow because the ABI has changed a couple of times. For a microcontroller it's probably fine: the privileged mode part of the spec is still not quite final, so I wouldn't recommend it yet for anything that you might want to run an OS on.
I am TheRaven on Soylent News
In particular, in the RISC-V case, the exact way of handling unaligned accesses is likely to vary a lot between implementations. In a microcontroller-class implementation, I'd expect it to handle these in microcode. For something particularly area-constrained, you might also implement multiplication and division in microcode.
I am TheRaven on Soylent News
Contrast with just picking up a license from ARM
One of the reasons RISC-V exists is that this is quite difficult. It can take two years to negotiate a license with ARM. The ARM licenses can also eat up a lot of your profit. Micron is one of the RISC-V backers because the licenses for the ARM cores on their SSDs eat a very noticeable proportion of the per-unit profit.
I am TheRaven on Soylent News
I used Atari ST Internals to code a horizontal smooth scrolling display, it was buggy - flickery on my 800 that I coded it on, but when the GTIA II came out in the 1200 the same code ran perfectly. I don't think there was ever any publication about that, other than, yeah, the GTIA I had some bugs.
What do you need schematics for a MacBook for though? It made sense back in the days when everything was written in ASM and ran on the bare metal, but now? How is a schematic going to make your latest hipster iOS app any better?
Analyzing the RISC-V Instruction Set Architecture â" Andreas Olofsson, August 2014
having an open "gate array" or FPGA with fully diclosed bistream would be really relevant. morover it could have a RISC-V hard core side by side.
actually there's anyway a reverse engineering effort of the bitstream for the iCE40 Lattice smaller FPGA (up to 8K LUT), it's project icStorm
http://www.clifford.at/icestor...
together with arachne-pnr and yosys, you could put in place a fully open source pipeline to program those little rascals, from Verilog to bitstream.
this cold be also the starting path toward a similar open source hardware design, suppose. if that's road is not encumbered by patents about this kind of "gate layout", of course.
OK then, reality wins!
By the time I got my ST I didn't have trouble like that but I bow to your experience with those earlier buggy chips I didn't see.
That's the project's main complication other than the actual hardware design. We know lots of gate-array patents are expired, it's been long enough. But the particular features modern developers are used to - for example a particular flavor of LUT or matrix of gates, or a way of programming the device, might still be under patents. So we'd have to do a patent study to inform the design.
It's still a great project to do and could get significant grants. If there are any EE's out there who are up to the task and want my help to evangelize and help get funding, it's yours.
Bruce Perens.
At the lower end, there are the Cypress PSoC 4 and PSoC 5LP chips. Those combine ARM cores with a small amount of programmable logic - not enough to constitute a full-blown FPGA but enough for many purposes. They are inexpensive, and all the digital I/O pins are not only 5V tolerant but 5V capable. (The processor core runs at 1.8V but the chips include level translation.)