SiFive has made a multicore RISC-V chip. Some infos here
- 5 cores RISC-V 64 bit
- 2 MByte chache RAM
- up to 2.6 GHz clock
- 28nm process, 30 mm2 die size
- HiSpeed link to FPGAs
- no USB on chip
- no Flash on chip
Evalboard early next year
There are also a few other companies that work on multicore RISC-V chips.
But there is still a long way to go until the industry adopts RISC-V and you can buy
cheap controllers with RISC-V comparable to all the ARM Cortex M0..M4 controllers or the MIPS based PIC32s.
A 28nm process real, physical RISCV is actually interesting. I wonder what the cost of the eval board will be. If it's reasonable I would be interested.
Downside is that the hypervisor mode is software, not hardware implemented. But I could live with that.
I suspect those wily Chinese might be on the RISC-V case soon enough. Consider devices like the ESP8266/ESP32. They use Xtensa processor cores from Tensilica. Why license a CPU core when you can just get one for free? RISC-V could make it possible for lots of little guys to get their ideas off the ground with minimal fuss and expense.
I wonder what that high speed link to FPGA looks like. Perhaps we can hook the P2 it.
Interestingly the 2M Byte cache can be configured as simple static RAM for real-time determinism. 2M Byte is a good size space. Perhaps the whole thing can run with out any external RAM.
SiFive has made a multicore RISC-V chip. Some infos here
- 5 cores RISC-V 64 bit
- 2 MByte chache RAM
- up to 2.6 GHz clock
- 28nm process, 30 mm2 die size
- HiSpeed link to FPGAs
- no USB on chip
- no Flash on chip
Evalboard early next year
I see the link says this
"The system is supported by the Eclipse-based Freedom Studio that runs on Windows, Linux, and MacOS.
The chip will work with JTAG emulators like Segger’s J-Link Probe."
That could be significant & useful for P2 debug, if P2 can run a JTAG(subset) interface well enough via smart pins ?
Can the streamer do 2 bit wide ?
...and the FPGA link is called ChipLink, but I suspect may be LVDS - too fast/incompatible with P2.
However, it does also show QuadSPI, UART, SPI, i2c, GPIO peripherals, so maybe those have enough speed to be useful ?
Also shows ROM and OTP, but I cannot find how much OTP ?
"Coming soon: Gapduino
Greenwaves is getting ready to roll out in April its GAP8 hardware development kit priced at 100 euros (about $123). Included in the kit are the GAPDUINO board and the GAP8 SDK.
GAPUINO is an Arduino Uno compatible Master or Shield with a camera connector for external cameras, according to the company. It can be powered via a battery (SAF17500), DC connector or USB.
Greenwaves also created a sensor board (Arduino shield format) containing several sensors including: 4 x MP34DT01 microphones, VL53 time of flight, IR sensor, pressure sensor, light sensor, temperature and humidity sensor and a 6-axis accelerometer / gyroscope."
April is not far off, and ~$123 is tolerable price.
I do notice a HyperBUS block in the peripherals, as these Octal Serial ports gain traction (HyperBUS. OctaSPI).
Mentions 133MHz ans 175MHz, which are modest clock speeds, but this targets lowest power, & has 9 cores.
No sign of memory sizes ?
Sadly, there are also cringe inducing levels of marketing-bandwagon-buzzwords, as AI is the 'hot new thing' to chase funding.
"Consider, he said, traffic lights in a smart city. With machine learning capabilities, the traffic light can count cars are at any given time."
Groan.... Traffic control system have been tracking cars, for decades, long before AI fashion .... seems we can expect any embedded system that measures values to now be tagged as 'AI' ?
Looks to have 512kB shared memory, so very P2 like there.
aQFN 84 package, so very much in microcontroller package space here.
SDK even has an expensive clamshell ZIF, to allow latest alpha silicon to be tried
Some quite good P2-litmus test numbers appear in the data brief. I see
0.5 ms cold boot time - not bad, no code size mentioned ? 32 kHz external quartz 70nA RTC stand-by current 3 uA to wake up from a GPIO 8 uA to retain each of the four 128kB banks of L2 memory
1 fabric controller core, with 16 kB data and 4 kB instruction cache for system control
8 compute cores with 64 kB shared data memory and 16 kB shared instruction cache
Hmm, shared data memory & shared instruction cache, does not sound like hard real time ?
Groan.... Traffic control system have been tracking cars, for decades, long before AI fashion
Do you have any links to such sophisticated traffic control systems.
My experience the past few years is that in Scandinavia, England and California is that they don't.
Yes traffic controller have computers and some crude loop detectors, perhaps even radars and cameras, but there is no tracking going on. The control algorithms are not quite "clock work" but still 1980's "microprocessorization" style crude.
An example I was looking at today, in San Jose, has dozens of loop detectors at each intersection. But they are wired in parallel across the road. It's impossible to even tell what lane a car is in. Any adaptiveness to traffic volumes, is minimal.
Groan.... Traffic control system have been tracking cars, for decades, long before AI fashion
Do you have any links to such sophisticated traffic control systems.
My experience the past few years is that in Scandinavia, England and California is that they don't.
Yes traffic controller have computers and some crude loop detectors, perhaps even radars and cameras, but there is no tracking going on. The control algorithms are not quite "clock work" but still 1980's "microprocessorization" style crude.
An example I was looking at today, in San Jose, has dozens of loop detectors at each intersection. But they are wired in parallel across the road. It's impossible to even tell what lane a car is in. Any adaptiveness to traffic volumes, is minimal.
I was meaning tracking in terms of sense, (as in 'count cars') rather than identifying each individual car.
Sync of traffic lights to give a 'green wave' is also quite common (for decades), and bus lanes & buses certainly have light-affecting abilities.
No, no, I know what you mean. I did not mean tracking individual vehicles either.
Having had discussions with the guys in cities across the globe responsible for traffic control I have learned that such seemingly smart things as "green wave" are largely a myth. Despite such systems being sold to them for decades. It mostly does not work and these guys have no data to even judge if it works or not.
The bus priority thing is still a dream in most places. Been speaking to the guys that do that in various places as well.
Thanks for the heads up on "Become a Traffic Engineer". I'll show that to our in house traffic engineers. They will get a good giggle.
We have had bus priority, if you can call it that, for years in Oz.
When a bus is waiting in its lane, it gets a short go before the rest of the adjacent vehicles get their turn. Allows the bus to get in front of the traffic, so it can then stop 100m down the road for passengers (oops, I mean customers) to get off/on.
We have had bus priority, if you can call it that, for years in Oz.
When a bus is waiting in its lane, it gets a short go before the rest of the adjacent vehicles get their turn. Allows the bus to get in front of the traffic, so it can then stop 100m down the road for passengers (oops, I mean customers) to get off/on.
Sounds wrong, but is better then nothing.
In Berlin, Germany we had that system too, and it worked quite well, since waiting to get behind the traffic would render the bus useless for transportation.
Here in Clearlake Oaks, California I have not seen any special treatment for public transportation, that lonely bus running every 2 hours around the lake needs not much support on crossroads or signal lights.
On the other hand the Signal lights on HW53 are nicely synchronized, so when keeping a steady 55-65 you usually do not need to stop. So "Green Waves" exist here. But just synchronized on a timer, not the traffic.
I personally find the RISC-V quite interesting, but I am unsure about the whole modular concept. Writing software for something that may or not may have certain instructions seems quite complicated too me.
I personally find the RISC-V quite interesting, but I am unsure about the whole modular concept. Writing software for something that may or not may have certain instructions seems quite complicated too me.
That was a worry for me as well. On reflection I don't think it should be much of a problem.
Firstly for a general purpose machine running Linux or whatever there is a set of ISA extensions defined. All such machines will support that set and software will just work.
Some optional extensions will be taken care of by the compiler. Don't have floating point hardware? No worries the compiler will use software floating point. I'm not sure but even this can even be taken care of at run time. Processor hits a floating point instruction that it does not know, that causes a trap, the trap handler emulates the operation in software and returns to your program with the result. Intel and ARM processors can do this. There is a performance penalty but your code does at least run.
I don't think there will be hundreds of different processors with hundreds of different combinations of RISC V extensions. There will be convergence to common subsets.
Secondly we have had "modular" instruction sets for decades. An intel machine could be 16 bit (286) or 32 bit (386 and up). May or maynot have floating point, i386 vs i486 and up. May be old Intel 32 bit ISA or new AMD 64 bit ISA, they are very different. May or may not have SIMD instructions, in Intel and ARM. And so on. The ARM world has dozens of different instruction sets.
All in in all this ISA extensions thing has to be done. A micro-controller of soft core in FPGA may need to be very small. Other applications can tolerate requiring more transistors for extensions like floating point and vector processing, virtual memory and so on. Better to have this variability standardized as well defined ISA extensions than the chaos of random instruction sets we have today.
Point is, much of the software support you need, compilers and other tools, will be the same.
The bus priority thing is still a dream in most places. Been speaking to the guys that do that in various places as well.
Back in my student days I and a friend visited a former classmate who had moved to a bigger city. He took us on a drive around town. At an intersection he pulled out a long stick which he waved out of the side window and up against a pole. He explained that the poles had sensors which detected the (taller) busses and then changed the light to green much sooner. He used the stick to pretend to be a bus.
It's not really what I'm talking about when I say bus priority. What a bus wants is that intersections ahead are clear of vehicles in the approach and green when they get there. Such that they don't even need to be stopped or slowed down at an intersection.
Well, for that we have bus lanes. They work pretty well, most of the time, even if the lights aren't part of the system (the bus has to wait, but will be first in line). And for approaching roundabouts and the like.
In general, it often pays to avoid making it too complicated. I'm reminded of various payment systems for buses which have been tried out in different cities. The simple ones are cheap, work, and do the job. The flashy ones are never finished, cost a fortune, and don't work.
The RISC V must be connected to a bus.. no? So it's almost relevant..
As for the ISA, like Mike I've also been concerned about the instruction set mess. Because that's what it is, really. My stomach definitely doesn't like the idea of optional and extendable instruction sets. And comparision with x86 doesn't make it better.. it kind of proves the point (=it's a mess).
We now have bus roads in Sydney that have bridges over/under other roads such that traffic lights are almost non-existent. Work extremely efficient. There are similar ones in Brisbane.
I've been at OnSemi in Pocatello, Idaho this week. These guys are extremely fast and smart. Their layout guy, Nathan, punched our layout into shape in a couple of hours. He's like a shark. We had a meeting with some of their ESD engineers and they recommended that we make some modifications to our ESD structures. I was thinking, "Oh, no, this is going to take another day." Nathan had all those edits done in about 20 minutes. it took me a little longer just to modify my schematic.
Everything is coming together very quickly, so that what is left is mainly place-and-route. That is underway, already, and I will post some pictures today.
The place-and-route engineer mentioned something that blew me away yesterday. Across from the office building where these guys work is their 350nm fab. He mentioned that the cost of a 350nm mask set has dropped to $7,000 and the tape-out-to-delivery time is down to 6 weeks. The mask set for the 350nm Propeller 1 chip was $60,000 and it took 12 weeks to get parts back. This means that very small companies can design chips now. The barrier to entry is extremely low these days. It is mainly a matter of knowledge.
That's right Tor. The 32 bit RISC V variant is suitable for single deck buses, the 64 bit variant for London's double deckers and don't forget the 16 register embedded variant for minibuses. Trams and trains will need the 128 bit RISC V variant if anyone ever builds one!
I think "mess" might be putting it a bit strongly.
It's a very well thought out mess that Patterson and the team have been thinking about and experimenting with for almost 40 years! The RISC V specifications have been rather slow in reaching finality as much time is allowed for the world to review and comment.
The extension idea is essential for those in accademia that want research different ideas about building processors. It's essential for the little guys who are not in the processor business but want CPU's in their chip and FPGA designs whilst being able to leverage all the RISC-V development tools.
It's certainly essential for me stuffing RISC V into a corner of my FPGAs
Whilst pondering your statement a nightmare "mess" scenario occurred to me. What if Intel looks at RISC V and thinks "That's a great idea, everyone is enthusiastic about that, we can do that and we can do it better than anyone else". Then they create a super fast RISC V processor. Of course it would have it's own Intel ISA extension, namely the entire x86 instruction set! Potentially ARM could do similar.
Well.. the mess.. maybe a bit strong, but I've struggled with low-level (asm) libraries that implement e.g. various encoding/decoding/error correction stream handling (needs to be fast), and it's a jungle of #ifdefs this and that, and sse vs sse2 vs mmx etc. And just take a look at /proc/cpuinfo|grep flags to see what's available.. not only instructions, but also other capabilities. There's not much fun there. I just wish for a fixed, firm, reasonably good architecture.
I think I mentioned elsewhere in this forum. But I'm taken with pondering the idea of building a RISC V out of late 1970's vintage AMD bit slice CPU chips.
The AMD 2903 has 4 bit ALU and sixteen 4 bit registers. Eight of those should make the guts of the embedded RISC V extension that only has 16 registers.
The other day, whilst pouring over the AM2903 data sheet an idea came to me: In RISC V register R0 always returns zero and throws away anything written to it. That means register zero of an AMD 2903 could be used for the program counter. That's all the registers we need.
I have a couple of tubes of 1980's vintage 2K by 8 static RAMs that have been waiting for a project for a decade.
What about the rest of the logic? Well, I'd cheat and do that instruction decoding and ALU sequencing and stuff with a Propeller. It's a big 1980's looking DIP in keeping with the style
I think I mentioned elsewhere in this forum. But I'm taken with pondering the idea of building a RISC V out of late 1970's vintage AMD bit slice CPU chips.
The AMD 2903 has 4 bit ALU and sixteen 4 bit registers. Eight of those should make the guts of the embedded RISC V extension that only has 16 registers.
The other day, whilst pouring over the AM2903 data sheet ...
I've been at OnSemi in Pocatello, Idaho this week. These guys are extremely fast and smart. Their layout guy, Nathan, punched our layout into shape in a couple of hours. He's like a shark. We had a meeting with some of their ESD engineers and they recommended that we make some modifications to our ESD structures. I was thinking, "Oh, no, this is going to take another day." Nathan had all those edits done in about 20 minutes. it took me a little longer just to modify my schematic.
Everything is coming together very quickly, so that what is left is mainly place-and-route. That is underway, already, and I will post some pictures today.
The place-and-route engineer mentioned something that blew me away yesterday. Across from the office building where these guys work is their 350nm fab. He mentioned that the cost of a 350nm mask set has dropped to $7,000 and the tape-out-to-delivery time is down to 6 weeks. The mask set for the 350nm Propeller 1 chip was $60,000 and it took 12 weeks to get parts back. This means that very small companies can design chips now. The barrier to entry is extremely low these days. It is mainly a matter of knowledge.
Ha, thanks. I have never heard of the Mick and Brick book. It is possible that it was the White book I was enthralled by back in the early 80's. The cover kind of looks kind of familiar.
A year or so before I had been working in the same department of Marconi Radar that that had built the Marconi Locus 16 computer for radar systems using the AM2900 chips. Previously that machine was built from TTL. As a fresh out of university, know nothing, greenhorn I had a lot of great discussions with those guys about CPU design. So I was fascinated by the whole thing.
Life has taken me in many other directions since then, but here I am thinking about it again...
Finally an article talking about Moore's law that actually gets to the point of Moore's observations.
Moore was into the economics of the thing. He pointed out that at any given time there is an economically optimal number of transistors to put on a chip. Give the technology available at the time working at too low a density is wasting resources. Pushing density too high gets expensive, what with reduced yield and so on. The trick is to to hit the sweet spot.
The fact that the sweet spot has been a doubling of density every two years or so is kind of incidental.
With that insight one can plan ahead. Invest in designing things that are not economical to build today but will be when the design is ready. Hence the huge success of Intel.
$7000 dollars for a tape out? Wow, I have been hearing that things have been getting cheaper at the low end of technology but that is amazing.
As for the "matter of knowledge" I think that is what the SiFive guys are about. If you have a working gadget in Verilog or whatever on an FPGA they will turn it into a real chip for you really cheaply.
It's a long while since I worked on any important code in assembler but even at the C level a lot can need tweaking to get code to run on different operating systems or hardware platforms.
I get the feeling, what with the "end of Moore's law" and such, that what people want is hardware optimized/customized for their specific task. That is even doable very cheaply now as Chip points out above. Be it tiny IoT devices or neural network engines in the cloud like Google's tensor engine or processors embedded in video cards like Nvidia.
For them a stable base instruction set, that is licence free, like RISC V, with all the development tools you need, is just the ticket.
It's some kind of balance between a stable, standardized base and the "secret source" you can add.
The dream of the single, standard, infinitely fast, processor that can do everything you need efficiently is, since the end of Moore's Law, dead. If it ever existed at all.
Comments
- 5 cores RISC-V 64 bit
- 2 MByte chache RAM
- up to 2.6 GHz clock
- 28nm process, 30 mm2 die size
- HiSpeed link to FPGAs
- no USB on chip
- no Flash on chip
Evalboard early next year
There are also a few other companies that work on multicore RISC-V chips.
But there is still a long way to go until the industry adopts RISC-V and you can buy
cheap controllers with RISC-V comparable to all the ARM Cortex M0..M4 controllers or the MIPS based PIC32s.
Downside is that the hypervisor mode is software, not hardware implemented. But I could live with that.
I suspect those wily Chinese might be on the RISC-V case soon enough. Consider devices like the ESP8266/ESP32. They use Xtensa processor cores from Tensilica. Why license a CPU core when you can just get one for free? RISC-V could make it possible for lots of little guys to get their ideas off the ground with minimal fuss and expense.
I wonder what that high speed link to FPGA looks like. Perhaps we can hook the P2 it.
Interestingly the 2M Byte cache can be configured as simple static RAM for real-time determinism. 2M Byte is a good size space. Perhaps the whole thing can run with out any external RAM.
I see the link says this
"The system is supported by the Eclipse-based Freedom Studio that runs on Windows, Linux, and MacOS.
The chip will work with JTAG emulators like Segger’s J-Link Probe."
That could be significant & useful for P2 debug, if P2 can run a JTAG(subset) interface well enough via smart pins ?
Can the streamer do 2 bit wide ?
...and the FPGA link is called ChipLink, but I suspect may be LVDS - too fast/incompatible with P2.
However, it does also show QuadSPI, UART, SPI, i2c, GPIO peripherals, so maybe those have enough speed to be useful ?
Also shows ROM and OTP, but I cannot find how much OTP ?
At the other end of the scale, I see this $25 PCB for the smaller sibling.
https://hackaday.com/2017/09/18/a-smaller-cheaper-risc-v-board/
Things are ticking along... this 9 core model, in 55nm
https://www.eetasia.com/news/article/18022703-mwc-greenwaves-enables-battery-powered-iot-ai?utm_source=EETI Article Alert&utm_medium=Email&utm_campaign=2018-02-27
"Coming soon: Gapduino
Greenwaves is getting ready to roll out in April its GAP8 hardware development kit priced at 100 euros (about $123). Included in the kit are the GAPDUINO board and the GAP8 SDK.
GAPUINO is an Arduino Uno compatible Master or Shield with a camera connector for external cameras, according to the company. It can be powered via a battery (SAF17500), DC connector or USB.
Greenwaves also created a sensor board (Arduino shield format) containing several sensors including: 4 x MP34DT01 microphones, VL53 time of flight, IR sensor, pressure sensor, light sensor, temperature and humidity sensor and a 6-axis accelerometer / gyroscope."
April is not far off, and ~$123 is tolerable price.
I do notice a HyperBUS block in the peripherals, as these Octal Serial ports gain traction (HyperBUS. OctaSPI).
Mentions 133MHz ans 175MHz, which are modest clock speeds, but this targets lowest power, & has 9 cores.
No sign of memory sizes ?
Sadly, there are also cringe inducing levels of marketing-bandwagon-buzzwords, as AI is the 'hot new thing' to chase funding.
"Consider, he said, traffic lights in a smart city. With machine learning capabilities, the traffic light can count cars are at any given time."
Groan.... Traffic control system have been tracking cars, for decades, long before AI fashion .... seems we can expect any embedded system that measures values to now be tagged as 'AI' ?
More info is here
https://www.cnx-software.com/2018/02/27/greenwaves-gap8-is-a-low-power-risc-v-iot-processor-optimized-for-artificial-intelligence-applications/
https://greenwaves-technologies.com/en/developer-kits/
Looks to have 512kB shared memory, so very P2 like there.
aQFN 84 package, so very much in microcontroller package space here.
SDK even has an expensive clamshell ZIF, to allow latest alpha silicon to be tried
Some quite good P2-litmus test numbers appear in the data brief. I see
0.5 ms cold boot time - not bad, no code size mentioned ?
32 kHz external quartz
70nA RTC stand-by current
3 uA to wake up from a GPIO
8 uA to retain each of the four 128kB banks of L2 memory
1 fabric controller core, with 16 kB data and 4 kB instruction cache for system control
8 compute cores with 64 kB shared data memory and 16 kB shared instruction cache
Hmm, shared data memory & shared instruction cache, does not sound like hard real time ?
Thanks for the heads up on Greenwaves. Do you have any links to such sophisticated traffic control systems.
My experience the past few years is that in Scandinavia, England and California is that they don't.
Yes traffic controller have computers and some crude loop detectors, perhaps even radars and cameras, but there is no tracking going on. The control algorithms are not quite "clock work" but still 1980's "microprocessorization" style crude.
An example I was looking at today, in San Jose, has dozens of loop detectors at each intersection. But they are wired in parallel across the road. It's impossible to even tell what lane a car is in. Any adaptiveness to traffic volumes, is minimal.
I was meaning tracking in terms of sense, (as in 'count cars') rather than identifying each individual car.
Sync of traffic lights to give a 'green wave' is also quite common (for decades), and bus lanes & buses certainly have light-affecting abilities.
here is an example of today's engineering teaching practice...
https://www.wikihow.com/Become-a-Traffic-Engineer
Having had discussions with the guys in cities across the globe responsible for traffic control I have learned that such seemingly smart things as "green wave" are largely a myth. Despite such systems being sold to them for decades. It mostly does not work and these guys have no data to even judge if it works or not.
The bus priority thing is still a dream in most places. Been speaking to the guys that do that in various places as well.
Thanks for the heads up on "Become a Traffic Engineer". I'll show that to our in house traffic engineers. They will get a good giggle.
When a bus is waiting in its lane, it gets a short go before the rest of the adjacent vehicles get their turn. Allows the bus to get in front of the traffic, so it can then stop 100m down the road for passengers (oops, I mean customers) to get off/on.
Sounds wrong, but is better then nothing.
In Berlin, Germany we had that system too, and it worked quite well, since waiting to get behind the traffic would render the bus useless for transportation.
Here in Clearlake Oaks, California I have not seen any special treatment for public transportation, that lonely bus running every 2 hours around the lake needs not much support on crossroads or signal lights.
On the other hand the Signal lights on HW53 are nicely synchronized, so when keeping a steady 55-65 you usually do not need to stop. So "Green Waves" exist here. But just synchronized on a timer, not the traffic.
I personally find the RISC-V quite interesting, but I am unsure about the whole modular concept. Writing software for something that may or not may have certain instructions seems quite complicated too me.
Anyways,
Mike
Firstly for a general purpose machine running Linux or whatever there is a set of ISA extensions defined. All such machines will support that set and software will just work.
Some optional extensions will be taken care of by the compiler. Don't have floating point hardware? No worries the compiler will use software floating point. I'm not sure but even this can even be taken care of at run time. Processor hits a floating point instruction that it does not know, that causes a trap, the trap handler emulates the operation in software and returns to your program with the result. Intel and ARM processors can do this. There is a performance penalty but your code does at least run.
I don't think there will be hundreds of different processors with hundreds of different combinations of RISC V extensions. There will be convergence to common subsets.
Secondly we have had "modular" instruction sets for decades. An intel machine could be 16 bit (286) or 32 bit (386 and up). May or maynot have floating point, i386 vs i486 and up. May be old Intel 32 bit ISA or new AMD 64 bit ISA, they are very different. May or may not have SIMD instructions, in Intel and ARM. And so on. The ARM world has dozens of different instruction sets.
All in in all this ISA extensions thing has to be done. A micro-controller of soft core in FPGA may need to be very small. Other applications can tolerate requiring more transistors for extensions like floating point and vector processing, virtual memory and so on. Better to have this variability standardized as well defined ISA extensions than the chaos of random instruction sets we have today.
Point is, much of the software support you need, compilers and other tools, will be the same.
Ha!, yes, such things do exist.
It's not really what I'm talking about when I say bus priority. What a bus wants is that intersections ahead are clear of vehicles in the approach and green when they get there. Such that they don't even need to be stopped or slowed down at an intersection.
In general, it often pays to avoid making it too complicated. I'm reminded of various payment systems for buses which have been tried out in different cities. The simple ones are cheap, work, and do the job. The flashy ones are never finished, cost a fortune, and don't work.
I agree. Keep it simple. That is the trick in coming up with good solutions.
Anyway, as this is a RISC V thread, I'm sure the RISC V can solve all the worlds road traffic problems
As for the ISA, like Mike I've also been concerned about the instruction set mess. Because that's what it is, really. My stomach definitely doesn't like the idea of optional and extendable instruction sets. And comparision with x86 doesn't make it better.. it kind of proves the point (=it's a mess).
Anyway, back to RISC-V
https://www.sensorsmag.com/components/moore-s-law-dead-so-let-s-talk-about-future-socs
I've been at OnSemi in Pocatello, Idaho this week. These guys are extremely fast and smart. Their layout guy, Nathan, punched our layout into shape in a couple of hours. He's like a shark. We had a meeting with some of their ESD engineers and they recommended that we make some modifications to our ESD structures. I was thinking, "Oh, no, this is going to take another day." Nathan had all those edits done in about 20 minutes. it took me a little longer just to modify my schematic.
Everything is coming together very quickly, so that what is left is mainly place-and-route. That is underway, already, and I will post some pictures today.
The place-and-route engineer mentioned something that blew me away yesterday. Across from the office building where these guys work is their 350nm fab. He mentioned that the cost of a 350nm mask set has dropped to $7,000 and the tape-out-to-delivery time is down to 6 weeks. The mask set for the 350nm Propeller 1 chip was $60,000 and it took 12 weeks to get parts back. This means that very small companies can design chips now. The barrier to entry is extremely low these days. It is mainly a matter of knowledge.
I think "mess" might be putting it a bit strongly.
It's a very well thought out mess that Patterson and the team have been thinking about and experimenting with for almost 40 years! The RISC V specifications have been rather slow in reaching finality as much time is allowed for the world to review and comment.
The extension idea is essential for those in accademia that want research different ideas about building processors. It's essential for the little guys who are not in the processor business but want CPU's in their chip and FPGA designs whilst being able to leverage all the RISC-V development tools.
It's certainly essential for me stuffing RISC V into a corner of my FPGAs
Whilst pondering your statement a nightmare "mess" scenario occurred to me. What if Intel looks at RISC V and thinks "That's a great idea, everyone is enthusiastic about that, we can do that and we can do it better than anyone else". Then they create a super fast RISC V processor. Of course it would have it's own Intel ISA extension, namely the entire x86 instruction set! Potentially ARM could do similar.
The AMD 2903 has 4 bit ALU and sixteen 4 bit registers. Eight of those should make the guts of the embedded RISC V extension that only has 16 registers.
The other day, whilst pouring over the AM2903 data sheet an idea came to me: In RISC V register R0 always returns zero and throws away anything written to it. That means register zero of an AMD 2903 could be used for the program counter. That's all the registers we need.
I have a couple of tubes of 1980's vintage 2K by 8 static RAMs that have been waiting for a project for a decade.
What about the rest of the logic? Well, I'd cheat and do that instruction decoding and ALU sequencing and stuff with a Propeller. It's a big 1980's looking DIP in keeping with the style
Not Mick & Brick?
Very good news
How much has the 180nm mask set price declined ?
...and not forgetting the White Book...
Ha, thanks. I have never heard of the Mick and Brick book. It is possible that it was the White book I was enthralled by back in the early 80's. The cover kind of looks kind of familiar.
A year or so before I had been working in the same department of Marconi Radar that that had built the Marconi Locus 16 computer for radar systems using the AM2900 chips. Previously that machine was built from TTL. As a fresh out of university, know nothing, greenhorn I had a lot of great discussions with those guys about CPU design. So I was fascinated by the whole thing.
Life has taken me in many other directions since then, but here I am thinking about it again...
Finally an article talking about Moore's law that actually gets to the point of Moore's observations.
Moore was into the economics of the thing. He pointed out that at any given time there is an economically optimal number of transistors to put on a chip. Give the technology available at the time working at too low a density is wasting resources. Pushing density too high gets expensive, what with reduced yield and so on. The trick is to to hit the sweet spot.
The fact that the sweet spot has been a doubling of density every two years or so is kind of incidental.
With that insight one can plan ahead. Invest in designing things that are not economical to build today but will be when the design is ready. Hence the huge success of Intel.
$7000 dollars for a tape out? Wow, I have been hearing that things have been getting cheaper at the low end of technology but that is amazing.
As for the "matter of knowledge" I think that is what the SiFive guys are about. If you have a working gadget in Verilog or whatever on an FPGA they will turn it into a real chip for you really cheaply.
Anyway, great to hear the P2 is full steam ahead.
P1B with 64 i/o, anyone?
I do feel you #ifdef pain.
It's a long while since I worked on any important code in assembler but even at the C level a lot can need tweaking to get code to run on different operating systems or hardware platforms.
I get the feeling, what with the "end of Moore's law" and such, that what people want is hardware optimized/customized for their specific task. That is even doable very cheaply now as Chip points out above. Be it tiny IoT devices or neural network engines in the cloud like Google's tensor engine or processors embedded in video cards like Nvidia.
For them a stable base instruction set, that is licence free, like RISC V, with all the development tools you need, is just the ticket.
It's some kind of balance between a stable, standardized base and the "secret source" you can add.
The dream of the single, standard, infinitely fast, processor that can do everything you need efficiently is, since the end of Moore's Law, dead. If it ever existed at all.