From the lowRISC blog:
We are looking for a talented hardware engineer to join the lowRISC team and help make our vision for an open source, secure, and flexible SoC a reality. Apply now!
lowRISC C.I.C. is a not-for-profit company that aims to demonstrate, promote and support the use of open-source hardware. The lowRISC project was established in 2014 with the aim of bringing the benefits of open-source to the hardware world. It is working to do this by producing a high quality, secure, open, and flexible System-on-Chip (SoC) platform. lowRISC C.I.C. also provides hardware and software services to support the growing RISC-V ecosystem. Our expertise includes the LLVM Compiler, hardware security extensions and RISC-V tools, hardware and processor design.
[...] lowRISC is an ambitious project with a small core team, so you will be heavily involved in the project's development direction. This role will involve frequent work with external contributors and collaborators. While much of the work will be at the hardware level the post will offer experience of the full hardware/software stack, higher-level simulation tools and architectural design issues.
Some practical experience of hardware design with a HDL such as Verilog/SystemVerilog is essential, as is a good knowledge of the HW/SW stack. Ideally, candidates will also have experience or demonstrated interest in some of: SoC design, large-scale open source development, hardware or software security, technical documentation, board support package development and driver development. Industrial experience and higher degree levels are valued, but we would be happy to consider an enthusiastic recent graduate with a strong academic record.
Informal enquires should be made to Alex Bradbury asb@lowrisc.org.
takyon (thanks to an AC): lowRISC is a project to create a "fully open-sourced, Linux-capable, system-on-a-chip"; it is based around RISC-V, the "Free and Open RISC Instruction Set Architecture", which is meant to provide an extensible platform that scales from low-level microcontrollers up to highly parallel, high-bandwidth general-purpose supercomputers.
Reduced instruction set computer (RISC).
Previously: RISC-V Projects to Collaborate
LowRISC Announces its 0.4 Milestone Release
SiFive and UltraSoC Partner to Accelerate RISC-V Development Through DesignShare
Related Stories
OnChip and SiFive, two groups aiming to develop and release RISC-V platforms, have announced they will collaborate. From OnChip's crowdfunding campaign:
Ever since SiFive's HiFive1 campaign was launched just a week after we launched Open-V back in November, we've both been getting a lot of questions about how we might collaborate. It's taken a while, as these things do, but we finally have a concrete answer we think will benefit everyone, not least the RISC-V community. Here's how we're collaborating:
...
Open-V Will Use the SiFive E31 CPU Coreplex
...
All Open-V Peripherals Will Be Compatible with SiFive Chips
...
SiFive Will Donate Wafer Space in a May 2017 Tapeout
...
OnChip Will Contribute to the Free Chips Project
Sounds like good news for those hoping for RISC-V and open hardware designs to become tangible objects.
Note that the SiFive HiFive1 campaign was successful and has already shipped to some backers while the OnChip OPEN-V campaign looks like it will not reach its goal.
lowRISC is a project to create a "fully open-sourced, Linux-capable, system-on-a-chip"; it is based around RISC-V, the "Free and Open RISC Instruction Set Architecture", which is meant to provide an extensible platform that scales from low-level microcontrollers up to highly parallel, high-bandwidth general-purpose supercomputers.
Here is the release announcement:
The lowRISC 0.4 milestone release is now available. The various changes are best described in our accompanying documentation, but in summary this release:
Moves forward our support for tagged memory by re-integrating the tag cache, reducing overhead with a hierarchical scheme. This will significantly reduce caches misses caused by tagged memory accesses where tags are distributed sparsely.
Integrates support for specifying and configuring tag propagation and exception behaviour.
A PULPino based "minion core" has been integrated, and is used to provide peripherals such as the SD card interface, keyboard, and VGA tex display (when using the Nexys4 DDR FPGA development board).
Please report any issues on our GitHub repository, or discuss on our mailing list. As always, thank you to everyone who has contributed in any way - whether it's advice and feedback, bug reports, code, or ideas.
Submitted via IRC for TheMightyBuzzard
SiFive, the first fabless provider of customized, open-source-enabled semiconductors, today announced that UltraSoC will provide debug and trace technology for the SiFive Freedom platform, based on the RISC-V open source processor specification as part of the DesignShare initiative. UltraSoC's embedded analytics IP will be available through the recently announced SiFive DesignShare ecosystem that gives any company, inventor or maker the ability to harness the power of custom silicon. UltraSoC's debug and trace functionality will enable users of the Freedom platform to access a wide variety of tools and interfaces to use in their developments.
The DesignShare concept enables an entirely new range of applications. Companies like SiFive, UltraSoC and other ecosystem partners have developed efficient, pre-integrated solutions to lower the upfront engineering costs required to bring a custom chip design based on the SiFive Freedom platform to realization. The partnership between SiFive, originator of the industry's first open-source chip platform, and UltraSoC, the industry leader in vendor-neutral on-chip debug and analytics tools, significantly strengthens the ecosystem surrounding RISC-V, the open source processor specification which is often dubbed "the Linux of the semiconductor industry."
[...] Rick O'Connor, executive director of the RISC-V Foundation, commented: "The idea behind the open source movement is that one doesn't have to design everything from scratch. The idea behind DesignShare is to help speed the development of new silicon designs by reducing the barriers of cost, process and integration that have traditionally held back innovation in the semiconductor industry. SiFive, UltraSoC and the other companies that are making their IP available through DesignShare are fundamentally enabling this revolution in an otherwise stagnant industry."
(Score: 5, Interesting) by anubi on Saturday September 23 2017, @04:40AM (3 children)
I wish the best for these guys.
This looks like the ticket for industrial embedded processors. Once someone like me designs in something like this, I expect it to last at least 50 years.
Not much different than me designing a bolt into the framework. It should perform its intended function, for all practical purposes, indefinitely.
Its been hard as hell to wean myself from 68000 based processors for that reason. I design around one of those and I expect it to last forever.
Wonder if they are tied somehow to the folks who make Picoscopes? Damn fine piece of work.
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
(Score: 4, Informative) by RamiK on Saturday September 23 2017, @09:56AM (2 children)
lowRISCs will be 64bit, 500-1500Mhz SoCs running linux and targeting network appliances and IoT. So, maybe a uC like the would be more up your alley. [sifive.com]
compiling...
(Score: 2, Interesting) by anubi on Monday September 25 2017, @10:23AM (1 child)
It is! Thanks!
I am always looking for something that should be available "forever". I hate like the dickens designing anything into industrial use knowing in ten years the thing may not be available, or no one with the skills to use such a "fashion-of-the-day" of ten years ago. The only language I much trust at all is C or C++ to know it should be known 50 years from now.
I was brought up on a farm, then onto the oil fields where a lot of stuff 100 years old was still doing what it was designed to do. When you go through all the trouble to build an infrastructure, whether it be an oil pump, railroad, or city water system, you do not go through all that effort to make something that has to be replaced. It has got to be there until it is deliberately removed. Well, that's just the way I see it anyway. When one builds something like this, one builds it to last.
( I doubt I will still be in service 10 years from now, and likely not available at all 20 years from now. But I design with anticipation that when the time comes, there will be people out there who can see what I did, and fix or improve it. )
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
(Score: 4, Informative) by RamiK on Tuesday September 26 2017, @03:10PM
Not sure about forever, but I'm fairly confident RISC-V microprocessors will become quite dominant in the next few years and will stay that way for a few decades at least. The specs are very modern and small so they just don't leave much to improve upon and you really can't argue with the price.
As for the higher-end RISC-Vs like lowRISC... That depends on Mill Computing ;)
compiling...
(Score: 1, Informative) by Anonymous Coward on Saturday September 23 2017, @12:25PM
lowRISC recently also announced the completion of a project to support tagged memory: http://www.lowrisc.org/blog/2017/09/lowrisc-tagged-memory-os-enablement [lowrisc.org]
I considered submitting it as a story, but was not sure I understood it well enough to summarize is succinctly or opine on its implications.
(Score: 5, Interesting) by bzipitidoo on Saturday September 23 2017, @01:38PM (7 children)
Despite its age and issues, x86 is still alive and strong. Intel and AMD have been able to apply many advances to the x86 architecture. Such as, since the Pentium, there's an additional layer of microcode, and the underlying processor of an x86 system actually is RISC. All the inefficient, crufty 1970s era ideas, such as packed decimal arithmetic, stack manipulation, special purpose dedicated registers in combination with a lack of general purpose registers, have been rather neatly sidelined. Sure, a modern x86 CPU can still do all those antiquated instructions, but they are unimportant.
Most of all, the architecture could be expanded. It has been expanded from 8bit to 16, 32, and now 64bit. More general purpose registers have been added. And it's been further expanded with MMX and SSE, which supports much more parallelism. Additional important capability with atomic test and set instructions was added in the 486.
What seems the biggest lack is some way to completely remove the cruft. The easiest way to do that is a reboot. Start from scratch with a new hardware design. That's been done many times, but somehow, x86 is still popular. Seems the efficiency gains from dropping useless instructions isn't significant enough to provide a compelling advantage over the x86 architecture.
So this project is attacking the lack of openness, as well as the excessive complexity. I wish them luck. But one thing I wonder, is the GPU eclipsing the CPU? I hope that thought has their attention, and their System on a Chip can do graphics. If it can't do the little that the still rather feeble Intel integrated HD graphics can do, then I'd say they're on the wrong path.
(Score: 3, Informative) by Anonymous Coward on Saturday September 23 2017, @02:27PM (2 children)
Arm has itself positioned as a replacement for x86 in the mobile environment. Desktop environments had of course the disadvantage that they required Windows support... And Microsoft, until recently, only supported x86. MacOSX was originally also on Power, but left it for x86 as well.
An other architecture would be possible, but you'll need someone willing to invest quite some money up front to get it going. Raspberry PI has done this, to be honest, quite successful. You can run them as a small-scale computer, but power is severely lacking there (including a few other things).
(Score: 2, Disagree) by anotherblackhat on Saturday September 23 2017, @08:28PM (1 child)
I know - It seems like all those x86 smart phones have been completely replaced by Arm, almost as if the x86 was never dominant in the first place.
Seriously, Arm has always been faster, cheaper, and drawn less power than the equivalent x86 CPU.
The only thing x86 has going for it is inertia.
(Score: 1, Insightful) by Anonymous Coward on Saturday September 23 2017, @11:08PM
The atom processors are faster, but generally draw more power.
When it comes to anything beyond tablets/phones, x86 does better on everything, and includes a fairly open-source friendly GPU unlike ARM.
(Score: 0) by Anonymous Coward on Saturday September 23 2017, @11:35PM
To pick a nit, the 8008 was 8-bit.
The 8086 was 16 bit.
The 8088 has a 16-bit internal architecture identical to the 8086 but it talked to the world via 8-bit busses.
The Motorola 68008 was another necked-down uP and might have given us an industry-dominant flat memory model but that company was slow getting that chip to market and IBM used Intel's 8088 in their PC.
-- OriginalOwner_ [soylentnews.org]
(Score: 0) by Anonymous Coward on Saturday September 23 2017, @11:47PM
Even the 80286 [uaf.edu] had microcode.
(Score: 1) by anubi on Monday September 25 2017, @10:43AM (1 child)
I can't quite figure out why anything between the 8051 and 386SX survived.
To me, the 8051 series is ideal for embedded stuff - when cost per device is important, but the devices aren't very complex.
I thought the 8086 was barely OK, I hated the 80286 and its segmentation registers, and I sneered at the architecture until the 386SX finally arrived with again a nice contiguous memory accessing scheme, which was what I had all along with the 68HC000.
Personally, I am highly into Arduino, as most of my stuff is cost-sensitive and not terribly complex. I like the Parallax Propeller series with its eight core chips as I/O, but I am afraid to design it into industrial stuff as I fear one day Parallax may stop making them, and as neat as they are, they are not second sourced and they haven't caught on as much as I would like to see.
Those Propeller chips are extremely powerful if one has real-time processes to manage... for instance HobbyTronix has some VGA controllers built with them, and I am interested to see if I can convert them to run from the I2C bus instead of the serial bus. I also see it should be possible to run three independent VGA displays from one chip... that would be quite useful to me in making online diagnostic and reporting tools to let me observe a plant controller without bringing in a mess of diagnostic equipment... rather the propeller hung on the I2C would spew out info like an OBD-II reader does for a car.
And not tie up any more of my precious I/O lines...
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
(Score: 2) by bzipitidoo on Monday September 25 2017, @03:51PM
Yes, you're right, but I'd skip the 386 as well. If you ever target the x86, go for the 486 as the base, or just use the 8086. The big lack in the 386, as I learned from others, is that it has no atomic test and set instruction. It can be worked around, but it's a lot more painful to implement semaphores and other such parallel and OS functionality on a 386. It's no accident that the Linux kernel maintainers dropped support for the 386 just a few years ago. The 286's support for multitasking OSes is even worse. Took Intel far too long to get that right-- should've got it right in the 286, instead of bungling it like they did for that iteration and for the 386.
(Score: 1, Insightful) by Anonymous Coward on Sunday September 24 2017, @03:55PM
there are lots of FOSS devs. time for any non-whore hardware engineers to stand up and be counted.