Nvidia’s acquisition of ARM could drive other licensees away, perhaps towards RISC-V. This is because ARM doesn’t allow licensees to make nonstandard changes to the architecture, while it appears Nvidia is looking to do just that. Being the owner of ARM, it will be the only vendor able to do that, which would give it an unfair competitive advantage. That will antagonize the other vendors, and encourage them to look for alternatives.
Sorry ... that is just NOT TRUE as written. ARM has different licenses, which support different types of usage of the ARM core designs. And if you look at what they have been doing in the last year alone, you will see that they have been lowering the entry barrier into making new designs... for eg they have this design start kit that lets a company take a cortex m core as bitstream (can burn it but not alter it) and then make their own custom extensions around it that they can either simulate of burn onto an fpga. This is how the RP2040 PIO was designed. You can buy the fpga board on digikey for 995$ and download the cortex m images for free today. But yes, in comparison an iCE40 board is 60$ and the risc-c core come in xhdl, python or scala code. But companies wanting to do things have always been able to do it... the statement that nvidia ‘will be the only vendor...’ is entirely without merit, but it does soud geat ... fud always does ;-) DISCLAIMER: I am neither pro nor against anything... I just like to give people FACTS rather than my own opinions.That is why I like and respect Andreas’ work so much!
@@Alperic27 Nvidia now owns ARM, as licenses expire they’re free to rewrite the rules. If you don’t like the new rules, fine, don’t use the chip. No other options? Meh, Nvidia won’t care. You’re analysis relies on the fact you believe Nvidia will play by the rules. It’s been proven they won’t.
@@c1ph3rpunk well Daren.... sorry, but nvidia DOES NOT own ARM... that IS A FACT... which I invite you to NOT BELIEVE ME ABOUT, and VERIFY YOURSELF. An acquisition of that magnitude is a BIG deal, and the FTC has an equally long and complex review process BEFORE the acquisition can be allowed. So, if you check, you will see that the process has entered phase 2, where nvidia and softbank are required to answer some questions about their intentions and other modalities. If you have checked, you also know that Qualcomm has raised an opposition in multiple jurisdictions against the sell, as well as ... Huawei .. and I think at least another chineese company. So.... ARM has not changed hands yet, and information is more than opinions ;-)
As I thought more about this, I think you may have the causality links all wrong: ARM does not prevent changes. ARM sells licenses that support making changes. They cost a lot of money because 1) ARM wanted to avoid fragmentation 2) this kind of license give access to IP that has cost millions and millions to develop over 30 years... BUT.. more importantly, there is the question of WHO/WHY want to make some changes to this IP? The easiest way to understand that is to look at who makes changes today, or who is jumping early on RISK-V. WD as an eatly adopter: what they want is to have a consistent toolchain to build some highly specialized chips (controllers). So to them, and many others who are doing specialized chips, they dont want to have a complete arm8 or arm9 core, much less all the interconnect to have multiple cores on a single die.... for them the base risc-v core ISA (integer) is plenty... that and the decoding/execution pipeline that goes with it. for these people, a full ARM license is very costly for very little value as they most likely want to remove functionality rather than modify any of it. Of course there are the ones who may want to add some specialised ports to handle some tasks tasks in the hardware... but these people can do it today .. the rp2040 likely did not require a full license for the rpi foundation to design the PIO peripheral. So, to fridge vendors wanting you to be able to manage it from the internet, most ARM cores are overkill.. therefore I believe that the ‘but the license is expensive’ argument is bogus.... if you have ever worked with fpga/xHDL then you may have seen that copying IP from opencores for your own design is not always easy (maybe it is just that I deeply suck at it), so the ‘oh but look, the IP will be reusable accross designs’ seems to me also dubious. the ‘not invented here syndrome’ will likely lead to more ‘yeah momy look i shared my cpu design on github’ than it will to ‘let me reuse this intelligently designed IP core’. much of the opensource code on github is IMHO of bad to deplorable quality, so the same could happen with HW designs that will be filled with statically defined multipliers/divider constants that could make porting any parts a nightmare
For me the RISC-V based ESP32-C3 is interesting, because for RISC-V there's already an official LLVM backend present, which allows coding in alternate languages like Rust. That's not currently possible on Xtensa, and they seem to have little interest to complete one. (I know there's an official repository, but it moves really slowly).
Is this also the case for the periphery like WiFi ?
3 года назад
@@AndreasSpiess I'm not familiar with how the WiFi stack operates on the ESP32-C3, but afaik Espressif ported all the necesarry code of their custom FreeRTOS SDK for the RISC-V architecture, and that contains the usual API calls for the WiFi stack. Rust compiles to native through LLVM so as long there's binding for the API calls, it should be possible to access all things similarly. I don't think there's such ESP32-C3 specific Rust bindings at the moment, but it's only a matter of time, and a more skilled person could probably autogenerate that from the C headers. For the RTL8710 there's the freertos_rs crate for similar purposes: polyfractal.com/post/rustl8710/
12:44 I always thought ARM was build out from Acorn ( producers of the BBC Micro and Acorn Archimedes) and that Apple got interested in RISC much later.
The original ARM architecture was created by Acorn as the "Acorn RISC Machine"; they did a couple versions on their own and then spun out the processor design team as a joint venture with Apple and VLSI Technology as Advanced RISC Machines, Ltd. in 1990. So, Acorn, Apple, and VLSI all owned some share of the original ARM spin-out business. Apple was interested in using the architecture as the CPU in the Newton. In 1998, the company went public on the London Stock Exchange and NASDAQ with a name change as ARM Ltd. They remained an independent company until purchased by SoftBank in 2016, and in Sept 2020 Nvidia announced plans to purchase them from SoftBank, though that's not yet finalized.
There was also a period of Acorn ownership by Olivetti - best known as a dot matrix printer manufacturer I think. I may be wrong, but I seem to remember ARM IP was not included in the Olivetti deal though.
@@iwbnwif Olivetti was originally a typewriter maker, but they got involved with computers early on and made one of the first transistorized mainframes. Adriano Olivetti, the son of the founder of the Olivetti company, created the semiconductor foundry SGS to make reliable diodes and transistors for Olivetti's mainframes. SGS later merged with Thompson Semiconductors to form the company we now know as STMicroelectronics!
Happy Birthday! Lots of health and a hundreds years of life! We wish you that your films have the greatest possible reach :) And of course thank you for your creativity! You really help us :)
Great video! Thank you for starting from first principles and including the business interest side of things. I started my career in semiconductors (pre-silicon verification, architecture, and design). I really enjoy the way you explained and simplified the overall market and motivations. I will gladly point to your videos in the future when friends ask to understand the concepts you presented.
I will ask a stupid question.... what do you think it will allow that cannot be done today? .... .. .... dont get me wrong.. I love to read assembly language.. and understanding how to build my own add-2-then-substract-5 machine instruction was a very ... pointless but exiting experience.... but most people here will only ever program their boards in C or python... so they will NEVER see if they run on a risk-v, mips or arm core.... simple fact. but i love the name risc-v, it sounds much cooler (forget that it just means it was their 5th time defining a new ISA for teaching) you want to truly FEEL empowered today? Learn to program the RP2040 PIO... and do it in C, not in python ;-)
@@Alperic27 Understandable. But in the grand scheme of things, widespread adoption will hopefully see more custom Soc being made. For example, there are already many companies working on RISC-V cores for AI workloads. And most of these companies will end writing APIs for them. As an end result, I would hope, that I don't need to buy a Jetson Nano, but rather something much cheaper even if it has 1/10 the performance. Right now there are not much others which can do that. Like your said, most users will still be using C, and that's good IMO, especially for beginners.
@@josephsebastian943 I apologize if my remark may sound ‘antagonistic’, let me assure you it is not my intention... I honnestly think that most people do not understand what risc-v is or means for the future Again I ask: for what tangible benefit? ‘Core’ is a misleading word that covers multiple realities. For eg, the jetson nano soc contains 4 a57 ARM cores, which make it a full blown general purpose cpu. That part has nothing to do at all with the ML part which is made of 128 maxwell cores (these are completely different core from the base risc-v integer core for eg). The maxwell core are not covered in the risc-c modular core IP, and the fact that many companies are building new AI cores will not change that. Burning them into a discrete asic or as part of an soc does not change what they are or how they work... risc-v, mips or anything else has zero influence here. Neither does having an API has anything to do with what an ISA is or does. Another eg: today coral is a dedicated asic that can be programmed with a library or used transparently in a tensorflow model. The only reason why people have not made more asics is that 1) the knowledge is scarce, 2) the manufacturing is expensive... not that people cannot do it, or need to risc-v ISA to be able to finally do it... truly unrelated!! Google chose to package coral either as a complete board with a NXP quad a53 core soc or as a simple usb dongle. Adafruit is also prototyping a spi (think i made a mistake here.. could be I2C) board with the coral asic. Now the intersection with risc-v will at best be that 1) someone will make an ISA extension for ML to expose some low level tensor operators to abstract what the coral asic or the maxwell cores do (via the nvidia libs), or 2) the next generation of coral-like asic may be replaced with SOCs like nvidia did with jetson... but that may actually mean LESS FREEDOM... as the main cpu will be chosen by the soc vendor.... I much prefer to have more coral like solutions where I can even attach it to my Raspberry PI if I want, instead of being limited to use whatever the soc will contain. But yes... there will be another benefit that you have not mentioned: IF people share some ML ISA extensions, then you and I will be able to burn them ourselves onto an ECP5 class fpga alongside a pico-32 or rocket core, and .... and what? .... we will have to wait for someone to also opensource the tensorflow library that will use these new instruction, and more importantly wait for them to be supported in the GCC backend......... .... but it will be fun, when it happens... in a couple years? Until then, tinyml can do a lot of things on a simple arm core.
@Alperic27 First off, don't worry, I feel like we are having a healthy discussion:) I understand the confusion regarding my use of "core". What I meant is that, in general, more people (who have the knowledge to design custom cores) can create application-driven SOCs; But of course if not for the mass market, it would not make a ton of sense to do that. Companies like Esperanto are working on this kind of stuff (they created a RISC-V based SoC with 1000+ cores targeted towards ML workload for server-side application). I agree that the coral is a good platform, and deserves more recognition (I am planning on getting one of those Coral Modules/ dev board for some vision-based projects). Right now, TensorFlow (Lite) Micro is still a work in progress; last I checked they are still porting most of the operations from TensorFlow Lite. Hopefully, we get a standalone TensorFlow package for Microcontrollers. TBH it seems that you know much more about these things than me; I am more of an applications person who doesn't have to care what ISA it is using. Nevertheless, it is exciting to see some competition for ARM.
I think it's worth noting that pretty much no semiconductor manufacturer uses a single ISA across their whole product line. The Maker community tends to have a somewhat narrow view of the world of CPUs and MCUs based on what's in PCs, powerful consumer gadgets like phones, and things that have been associated with some Open Source projects before. This is for pretty good reasons; you tend to have to pay a lot of money for development tools outside this little slice of the processor world, and they're marketed to specific kinds of companies. But they make up really significant parts of the whole semiconductor ecosystem, so you have to be careful about assuming the importance of one ISA family like ARM even if it's completely dominating the Maker-visible parts of the semiconductor world right now. RISC-V definitely has the potential to eat into the share of the market that ARM currently dominates, but as you noted, the ISA itself is only a very tiny part of the picture. ARM provides not just an ISA, but several reference design implementations of it, a number of bus architecture designs to connect various kinds of peripherals, a line of GPU designs, etc. This stuff is very mature and very well supported with 3rd party hardware IP and software. It's going to continue to dominate in parts that are meant for end-user programming for a while! RISC-V is going to first take over where companies need CPU cores to run the internals of some in-house hardware design. You can see this from the interest shown by Seagate, Western Digital, Nvidia, etc. It's going to run inside the *peripherals* of computers first, where users mostly won't even be aware that there's a CPU involved at all. I think it might also stand a chance of being relevant to "hyperscaler" data center hardware, where PC-born bus architecture standards are in place already and there's a ton of cash to burn on long-term projects that'll result in cutting out ARM license costs in the long run, and the software stacks are internally-maintained by armies of programmers. I can also see Apple looking at RISC-V for future gadgets; cutting ARM license fees out of products where possible seems like a very Apple thing to do. Espressif choosing RISC-V for its ESP8266-replacement follows along these same lines; if you remember when the ESP8266 first hit the Maker scene, it wasn't really meant to be user-programmable; it was just a super-cheap WiFi chip you could hook up to an Ardunio via serial and control via AT commands. A lot of radio chips are designed like this; they take care of some layers of the radio protocol on their own, and you communicate with them over some serial bus from a more powerful MCU. Their choice of a weird Tensilica CPU architecture doesn't really hurt anything if they're the only ones coding for it, and switching to RISC-V makes it even more accessible now that Makers have exposed the usefulness of the chips when loaded with custom firmware. Don't think for a minute that STMicroelectronics is wedded to ARM, or that they won't embrace RISC-V if they see a benefit to it. They embraced some odd architectures in the past, and they still have a sizable line of 8-bit STM-8 and automotive Power MCUs. There may not end up being a reason, but I wouldn't be surprised either way.
I agree with your statements. And I am far from saying that ARM is dead. I am too old and saw many such wars. I tried to give an update from today's point of view and hope, I di not do too much prediction for the future.
An important issue for RISC-V is the fact, that chinese companies have to get independant from American-owned IP. And this is an issue for European companies and countries as well, as it might become a topic in trade wars and a subject of manipulation of NSA and friends. Thus it is quite a good idea to become somewhat independant from American-owned IP at least in critical infrastructures.
Quite a comprehensive and detailed overview. The future looks very interesting with this kind of development. Looking forward to see the next experiments.
Windows did actually run on other platforms and not just Intel x86 platforms. Windows NT 4.0 and its predecessors supported PowerPC, DEC Alpha and MIPS R4000. Windows RT was specifically created for computers with ARM architecture where ARM is still used for Windows smartphones with Windows 10 today. Source: en.wikipedia.org/wiki/Microsoft_Windows
Interesting and informative - have been in the IT industry (mostly Linux-related stuff) for longer than I want to admit, still learned several new things from this video. Your presentation of so much history/material is organized, coherent, and easy to follow. Well done!
Well RISC-V is open source to an extent. The core ISA and vector instructions (somewhat different to SIMD). But it also has a dark side into the custom extensions realm, for example a DSP, accelerators (matrix ops Etc.), some MCUs ext., GPU (despite a few open initiatives), ADs/DAs, etc. So must be taken with a grain of salt. Anyways, is way better than live into the x86 and ARM proprietary ISAs.
The increasing interest in RISC V from companies and institutions all over the world is also result of recent USA politic. People realize that just out of an arbitrary decision of Washington's administration the companies you source your chips/IP from can be forbidden to deliver in your country, even if they do ship this administration will require them to implement backdoors, ... But it's much harder to try to rule open source project than a private company's project, who will you sue ? The fact that the consortium's head moved to Switzerland follow that same logic. The stake is independence. If a bully country decide to make pressure on your supplier you can just go to any other and have another chip build for you from another country without having to rewrite your software. Just make sure you don't pay in US$ !!! Ask Huawei who invested billions dollars in 5G relying on Xilinx rfsoc technology that they can't purchase anymore. Almost all defense institution all over the world (all but US) are financing research projects around RISC V also for this reason. It's not so much about sharing, but more a way to be more resiliant toward bullies countries.
That was amazing coverage! You're always awesome Mr. Spiess! I have lots to consider now. My stomach turned when I heard Nvidia bought ARM. I didn't see how that was good for anyone except Nvidia, if it's even good for them in the long-run to survive the blowback. Many IT I know are buying up AMD because they perceive Nvidia to start bullying more, and they wish to stay flexible.
haha, "driving on the wrong side ..." Sh*tstorm incoming. Nice video, could serve very well to teach marketers and beancounters about the importance of standards. But on one thing you are wrong in my opinion: Having less operating systems is not only an advantage for users. Of course it is easier to use. But if we had some more mobile OS as example, Google and IOS could not play "we have big balls" like they are doing. So, standards and interchangable systems, or a wide variety of systems, are great. Yep, others migh have a different view at it.
This joke only works if you drive on the right side, of course... I agree that choice can be a benefit. But in my (corporate) world choice is exaggerated and creates all sorts of problems. I still like the fact that we do not have 10 standards for roads, electricity, and telecom. I also would not mind driving on the "wrong" side to have a standard. I see no advantage to have two different systems here because I do not have a real choice. We must pay attention to who makes the rules for the standards. But this is a topic for another video...
@@AndreasSpiess I guess we agree somehow. Choice is good for a society and a market. Now imagine, there was a standard so you could run your once written app on IOS, Google Android and ANY other mobile system following this standard, without any possibility for one party to break such a standard. If one party becomes to powerful, the society could switch to other parties supporting the same standard. Google and IOS would have to run true competition, not pseudo competition as per today. Noone could force you to comply with self established rules set for app stores or play stores. Instead there would be a fully accepted scheme of APIs for running application distribution stores. Wouldnt this be beneficial, somehow? And standards should not be in the control of a single power of course. On car driving we failed to create a full accepted standard, some countries still drive on "the wrong side" ;)
We have lots of such standards like html or many IEEE standards. After the Betamax-VHS disaster industry understood the importance of standards. But it is not easy.
@@AndreasSpiess Exactly, which is why i avoid it like the plague whenever possible, as tomorrow there will be a new standard for doing something and all the old standards still exist and don't die quickly. Choice is great for sure, but it fragments development and user communities to the point where if you need help with something you're the only one with that combination.
@@DominicClifton It is of course entirely your own business and I don't want to talk you into it. BUT ... if you exclude change from your life out of fear or laziness(or something more honorable:) ), then one day you will wake up and find that everything around you is out of date, broken and unable to exist further. Finding the right balance between the freshness of renewal and the stability of the traditional is an art and requires knowledge and work. I don't think the price is too high. Of course, I'm only talking about electronic components such as MCUs and CPUs and not about wisdom. How could I? ;) To "if you need help with something you're the only one with that combination": You are the only one on this planet with your exactly genetic expression. You can't get help? But in contrary to this philosophical stumbling block, what is wrong with it that you can be the person who can help others with this "specific vague" problem above? You just need to invest time, learn your equipment/environment and start giving something back! "Choice is great for sure, but it fragments development and user communities to the point" ... So you are maintainer of all known repositories? Well, then it is exactly your job to prevent this kind of fragmentation and steer the wheel in the right direction. I suppose you are not. That is why I find your remark to be both exploitative and patronizing at the same time. There is no point in generalizing the big and difficult topic of project management in this way.
@@dieSpinnt Do you actually do any hardware or software development? I do, I'm aware of striking the balance between new an old and the pros and cons; but when there's 10 libraries that all do the same thing, or when there's 10 package managers and 10 programs to swap out different versions of other programs and their libraries you gotta ask why?!? Linux and embedded developers seem to like reinventing the wheel instead of leaning how an existing system works and using or improving it. That's my 2 cents and until the situation changes I'm sticking to it.
@@DominicClifton 62716. Is the number of current Debian packages. They must do something different if they can work with the dependencies or use the very enhanced management tools. It is not my job to criticize your dependency management. I can't and wont answer this:) I do mixed signal PCB and product development. I have the same concerns as you when it comes to firmware development. The best package manager you ask? **whisper** we ourselves:)
I have NEVER EVER EVER gotten so much value from a single RU-vid video EVER! Words will never evolve to a place where it is enough to express how grateful and thankful I am to you for this video (,and neither will bytes lol. )
I made a video about MicroPython 2 years ago. There you see my position. But you can also reads the comments. You do not find another MicroPython video on this channel since :-( But with the appearance of Pi Pico it might change...
Calling it an ESP32 variant seems like a bad idea, it needs its own name outside the ESP32 family. Espressif already has naming problems, with WROOM and WROVER and the various sub-models. Ugh.
What a great summary. I think this should be compulsory viewing for engineers at university as not only does give a great statement on RISK 5 but a history lesson as well. A Brilliant episode. Thank you. Simon
The RISC-V is good for embedded systems as it is free and open. But it will never become a general all-purpose processor. The RISC-V is based on 40-year old ideas as RISC-V Foundation claims. There is no sense to port the huge x86 and ARM software ecosystems on it. Thus, RISC-V will never gain a victory over x86 and ARM. The most of positives about the RISC-V processor are arbitrary speculations. The advantage of RISC-V is open architecture. RISC-V has instructions of variable lengths. This is bad, it is a departure from the RISC architecture principles. The Contemporary microprocessors contain 8 specific hardware components: (1) SMT (Simultaneous Multithreading), (2) register renaming, (3) instruction reordering, (4) out-of-order execution, (5) speculative execution, (6) superscalar execution, (7) delayed branch, (8) branch prediction. These components make up some kind of a “magnificent eight” of components which essentially raise the performance of microprocessors. But unfortunately they are very complex. A processor core having these components is a full-fledged one, otherwise it is good for simple applications, e. g. for embedded systems. The “magnificent eight” of components is very hard to design, only the experienced firms and developers are able to do this, and much know-how was acquired, some effective solutions are patented. Particularly complex is the SMT. Only powerful and advanced firms like Intel, AMD, IBM are able to equip their processors with the “magnificent eight” components. It is not surprising that some Intel processors, and the famous Apple's M1 processor do not contain SMTs. If a company is able create the full-fledged RISC-V processor with all “magnificent eight” components then it would be a serious achievement, and such RISC-V would be considered of the World's class comparable with x86, with ARM, but not more. As far as I understand most of the developed RISC-V processors have no components from the “magnificent eight”, and are intended for embedded systems. A course directed on further development of RISC-V is a wrong way, and leads the computer architecture to deadlock. The RISC-V is not promising for computer industry. In fact, RISC-V hampers the further development of the state-of-the-art microprocessor technologies. The World demands absolutely novel microprocessor having much more higher performance than all contemporary ones. The novel and effective ideas on computer architectures do exist! Here’s such a novel processor architecture: V. K. Dobrovolskyi. Microprocessor Based on the Minimal Hardware Principle. Electronic Modeling, 2019, vol 41, No 6. pp. 77-90. The article is posted (under the Cyrillic name добровольский.pdf): www.emodel.org.ua/en/ then touch ARCHIVE, then move to 2019, then to VOL 41, NO 6(2019) pp. 77-90. You see: DOBROVOLSKYI V.K. Microprocessor Based on the Minimal Hardware Principle Click “Microprocessor based...” At the very bottom you’ll find Full text: PDF Click it. This processor does not have the “magnificent eight”, it is not necessary at all. This comment reflects different view on the RISC-V architecture, and the computer community has a right to become familiar with such a view. I’m Volodymyr Dobrovolskyi (V.K.Dobrovolskyi).
I am no CPU architecture specialist. I tried to explain the dynamics behind standardizations. I know that standards hardly ever are the best technical solution. But economical, they often make a lot of sense. We will see what happens in the future when the chip supply chain is full and everybody has overcapacity...
10:00 "Microsoft until recently only supported Intel ISA's" Windows NT4 also ran on the DEC Alpha, IBM PowerPC and MIPS R4000 ISA's back in the 1990s (and Windows XP & 2003 ran on Itanic, but that's Intel again).
For makers, Diy open-source CPU on FPGA is entirely possible. A small basic MIPS or OpenRISC architectures are fully opensource. I have used RISC-V board (Maixduino with K210 SoC) in the past, and compared to that, I have always loved STM 32 performance and price. I love the open-source community for Academic and research purposes, but RISC-V, although have a selling point of open source it is clearly not. While Comparison of ARM and RISC-V, the I clearly dont see and advantages of RISC-V over ARM. Maybe some day diy community will come up with their own CPU core and i will see a video about it on this channel. Thanks for a wonderful content✨✌😇 Cheers ✨
As a teen, many years ago, I along with two other friends were avid photography fans. We each bought SLR cameras ... but different brands. I had a Pentax, one friend had a Nikon, and the other a Canon. We often spent hours upon hours, as young people do, debating the merits of one system vs the other. But in truth, functionally these cameras were virtually identical. Except of course, they were completely incompatible with each other. Nikon lenses, filters etc. fit only Nikon cameras etc. There were other camera companies as well, which were similarly incompatible. They all deliberately avoided any standard ... presumably to force customers to buy only their products. Then Tamron came along, introducing the t-mount and a whole series of 'really great' lenses, which could be universally fit on any of these cameras, simply by switching inexpensive t-mounts. Tamron came into existence and thrived, by exploiting the lack of standardization in the camera industry. ... and so it continues.
A very good example how non-standard things can destroy value. You three probably only needed one particular good lens. Like that, non of you had one. But you had three very similar sets for the same price...
@@AndreasSpiess The problem with lenses and optics is that most coupling rings do not permit focus out to infinity. The Tamron improvement was making the lense infinity available using their flexible lenses. Exit barrier is the lock-in mechanism.
@@AndreasSpiess I just re-watched your video and have a few more comments. You made the point that RISC-V is a competitor to ARM. I think there's another reason RISC-V will soon take off. The USA seems determined to deny China access to technology, presumably to protect American IP and security concerns. It's not a simple question of royalties, China may not have access to ARM at all. This is forcing them to seek alternatives, and RISC-V is an obvious solution. By denying access, the USA may inadvertently unleash a flood of cheap alternatives to the market, which could come back and bite them. Forcing your opponents to innovate, may have unintended consequences. For the rest of us however, this may be the beginning of a huge opportunity. For the past 2 weeks I've been tinkering with some ESP32-C3 modules which I recently bought on AliExpress for around CAD$3 each. My goal was to set up an environment for RISC-V assembler programming, including hardware debugging. I've done this on Eclipse and can tell you that it works great, especially since the ESP32-C3 chip includes an onboard hardware JTAG debugger (super easy to use.) And ... as you suggest, there is also a LOT of additional functionality on these chips besides just the open source RISC-V ISA. Setting up the environment is not for beginners, but others have done it, and there is a fair amount of information available for those wanting to try. For beginners, these are still very powerful and super affordable boards, which are fully supported on Arduino etc. My point is, 'now' might be a real good time to start embracing RISC-V.
Interesting and informative video as usual. Interesting though about Intel and AMD..they are asleep at the wheel or resting on the megabucks they ahve made. Apple have released their new ARM based M1 chips in some of thier computers now just recently and they are killing the intel based stuff already but the next generation of chips called so far by others the M1X version will be orders above in speed and power. This will leave Intel back in the weeds and most likely AMD. I know its not maker stuff but interestingly being RISC style it shows this will be the way most will be going I think. If you are not up with the Apple hardware have a look at these new ones. Apple have a pretty closed ecosystem really but the performance is pretty dramatic..so much so that microsoft are now doing and release a ARM version so it looks like in the near future that you will be able to run possibly MacOS and Windows natively on a MAC
Probably talking bullsh*t myself, but I suppose you can base a RISC V design around a wishbone bus an use the zillions of peripherals written for it, you can have fully open source designs that way. The problem comes when you need to manufacture the chips... Probability makes more sense for FPGAS.
@@AndreasSpiess not sure how to translate correctly to English... but once I hear great way to distinguish: great businessman is always immoral beast. If you see businessman who is good man, probably he is bad businessman...
One main reason for RISC-V is the linear energy consumption when scaled up. Yes, no maker needs that. That is for big server farms and the cloud. - RISC-V better than other ISA on a large scale - one source says: arstechnica.com/gadgets/2020/12/new-risc-v-cpu-claims-recordbreaking-performance-per-watt/
Dear Andreas 10:12 ... totally Correct! and there was not even the need to continue the video ... that would suffice to make a Great video :) :) ... A bit of numbers: - Linux is 90% + of all major Web server. - 90% of all Smartphones. - 99% of all Large display Tv's ... yes inside they all have a ARM-Based Linux CPU. - 99% of all Supercomputers. - 90%+ of all Automotive Smart-drive and multimedia onboard cars. - 95+ % of all Home Routers and multimedia stand-alone hardware. ... Linux RULES! :):) Great video Andreas once again, but ... some parts of it would by themselves required Hundreds of hours of videos ... specially those regarding the architecture wars and OS-wars ... oh boy that was a big part of the last 4 decades on the Tech world! But you warned everyone the subjects mentioned were super-simplified ..so it's ok. Great video!
I agree with the hundreds of hours. This fact made it not easier to create this video ;-) Your Linux Chart remembered me of the statistics of the first browsers... They were similar. And a few years later, Netscape was dead and Chrome king. I am curious what we will see in the future...
@@AndreasSpiess It is indeed the history of Technology "battles" of the last decades, a very complex subject over which many many books have been written and many more will come I'm sure. About the future it is clear who won by the statistics I mentioned. It is by now Totally Irreversible. Since early 90's I knew Linux would be the future and by then I had to install MS-DOS first in order to know hardware driver parameters, only after that I was able to install Linux. But the issue remains, All Architectures are supported by Linux. Other then the Desktop with Strong Application dependency on MS platform all new contenders will search for something that is Open-Source, not because of Open-source itself but rather because that automatically creates a huge advantage on their ecosystem ... like in the case of the IBM and SUN DEC ... Platform makers know that they can either create their own little niche platform and end up like IBM/SUN or ..appeal to the entire developer community and offer Open Source Access to all in order to gain the most traction. Cost of entry is lower and giving everyone a Standard platform is a tremendous advantage for New system. No new contender on Any new Technology will ever come out again with proprietary stuff (I mean they will but it is doomed to failure) ... also Extending Linux Support for your hardware instantly gives your Hardware access to Everything All others developed for all other Platforms. It is a huge Leap forward from the get go. Moreover the most likely scenario is that some years ahead Linux dominance on the areas mentioned will extend into the Desktop also. Anyone with simple knowledge of IT could today install Linux as a primary OS, run Virtualbox for example for one or two MS-only Applications. I agree that obviously Chrome would kill Firefox simply because for each PC sold there are 3 smartphones sold ..all with Chrome installed ... But even like that Firefox is ahead of All MS browsers all versions of edge and they come pre-instaled ... In the case of OS choice and support there is no way out today of what Linux has achieved ... Linus Torvalds once said that Linux Wins the Day Microsoft becomes a major Kernel Contributor ... Biggest corporate code contributor to Linux Kernel since about 4 years ... Microsoft! Complete and total Surrender. The fact remains Andreas, for every PC sold (almost all with Windows less then 10% with iOS) ... 5 Linux devices are sold ! (Mostly smartphones) ... All of the Biggest companies on the world are fully behind Linux ... they range from HP, Oracle, IBM (acquired Red Hat), Intel, AMD, Samsung, Western Digital, even big Banks ..you name it. NVIDIA acquired ARM (SoftBank had huge problems because of their Lunacy investing on the We Company they were "forced" to sell ARM to cope with the losses )... 80% of ARM revenue comes from Linux-Based sales. ARM sells hugely Because of Linux on Smartphones. NVIDIA will be forced to hugely increase their support to Linux ... at least on ARM ... The momentum has turned hugely, and what I've foreseen in the early 90's is now coming into plain view.
I agree and it shows how important the "standardization on the lower level" is. I am not sure if only the open source aspect of Linux was important. I think it was also important that many big companies on the higher level contributed, as I mentioned in the video. BTW: I am still a heavy Windows user because it works. Linux, unfortunately does not work for me as soon as a leave the Raspberry world. And I think, I am not a complete idiot :-( It is still not made for the masses.
@@AndreasSpiess Yes I get what you are saying. My opinion is formed on the basis of the Consequences for big companies of the Open Source Model ... Let's imagine you get the finance to make a Brand New from the ground up Hardware Ecosystem ... Chips, Hardware ..the all lot. You get the backing of a Major Corporation, say IBM for example, they call you and say : Andreas your mission is simple: Destroy ARM ! :) :) we want all their sales ..no More NVIDIA nagging on us! You are going to spend a Lot of time developing your hardware from the ground up, like in the our present example on a RISC-V architecture. Then comes the problem ... are you also going to Spend Even more time and resources Making Everything useful for that Hardware, that is Software, from the ground up? That is, all drivers for All other Hardware like network cards, video, sound, displays, peripherals all connectivity and telecom stack , from TCP/IP to everything else. All web protocols ... Everything Has to be built from Scratch ... If you Adopt Linux you not only get Literally ALL available Hardware (ALL Hardware) as well as the Most Rock Solid implementations of Everything Else ... fromTCP/IP all the way to ftp/ssh/http/File Systems/image and sound and video formats and processing ... everything ... you would have instantly after building the hardware and adopting and adapting your hardware to the Linux Kernel you would get the Most Rock Solid and Extended Software Stack instantly running on your platform as well as the Even Bigger ... User Space Application Stack! All of that Rock Solid, massively Certified and ... the magic word for any Corporation: Instantly And Free ... you would get the Software Ecosystem instantly for Free (very low cost at least many thing have to be adapted of course). Most importantly ..that Software ecosystem si evry time the number one Choice for Developers ... the most Important aspect of all. - Or, Scenario 2: You turn to the Big Corp overlords and break then the "good news": Ok, we will make our Own Software Stack that No One Knows about, (No Developer will spend a second on that even if the Hardware was for free ...) And we will spend the next 10-15 years on Developers and another 10 Years developing a New OS (full of bugs .. ) ..oh and let's hope developers see some traction on the hardware sales to justify any user Space Application development ... What do you think the Big Corporations would accept? And to their question but but ... it's Open Source ... how can we "protect our IP" ... the answer is simple: Why protect something No ONE would want to buy 15 year from now? Loose 15 years of Huge Work and in the end after seeing all platforms Standardizing surrender it all? It's a hands down choice at this moment. About your Linux in the desktop experience. I know it is more complex and requires more time than windoze. But I use Linux since 1997 and as a Full Time Primary Desktop since 2002 on a 64Bit AMD ..Windows did not even had half-decent 64 bit support until 2006 .... and it is all a matter of spending some time learning the tricks on the OS. I also Save a lot time because i do not know what a anti-virus program is ... my hardware last much much longer and if you get VirtualBox you have the Best of Both worlds although every time more I get less and less need to go to VirtualBox and run Windows inside it. Also I consider the Raspberry Pi several OS's very very lame when compared to Real Distros Like OpenSUSE, Red Hat, Ubuntu and the like ... of course the Desktop of choice on RPi can not be a KDE or Gnome ...
I think we do not need to agree. Future will tell. In this video I tried to focus on history and tried to explain what happened and my interpretation about it. Maybe I am wrong in some places. One thing is sure: I am not good in predicting. As Einstein (or somebody else) said: It is difficult to make predictions, especially about the future.
Excellent video. I think we will see more open source chip designs, e.g. coming from not-for-profit organisations like LowRISC where all the RTL is open source. You can also get chips manufactured for the order of €10k or so through Europractice, which is doable for University research projects that might want to add new experimental features to an open source RISC-V core, which is not something you can do with an ARM core. A couple of minor corrections: you usually hand off GDSII to a chip foundry, not RTL; Windows NT was supported on DEC Alpha.
I think ARM is more of a right place right time success, they had a nice low power chip when no-one else did and no capitol or skills to set up high volume chip fans to they leicenced it.
I think now ARM is owned by a company whose intrests might be served by restricting access to it's products As you say RISK 5 might have an opportunity, I'm not convinced by open source as being compelling always from a comercial perspective. Which mostly will be about getting product to market quickly and hence building quickly on prexiting technology and code.
Wow, this is an awesome video. It’s packed full of insight, including some thoughtful ones concerning industry and company strategy. The video is only 25 minutes long, but I feel us viewers are benefitting from years of experience and knowledge. I just wonder how many hours (even years) you spent in the making of this video. Thank you for sharing. What a gift to the community. Truly Open Source!
@@AndreasSpiess Look at all the choices of USB connectors you have.... A B A micro A mini B min B micro C B micro USB3 ... or RF connectors bnc hnc tnc sma sma-r gr uhf f rca smb n smc mcx mini-uhf
aaaah! I thought you were speaking about the ESP32-S3 in the last video, not the C3 Version :D Ok, I'm gonna watch this! But the mentioning of FPGA already excites me! edit: very cool video, thanks for that overview! I'm sure, i'll also stick to the Sx Line of the ESP32 series. But I'd love to see some more of FPGA stuff in the maker scene :D
1. I do not have any S3 chips (so far) 2. Unfortunately I did not find a lot of cool Maker projects for FPGA where you do not need a Ph.D. to understand them :-(
@@AndreasSpiess I hope you get one of them soon :) 👍 in the end you are the most known swiss maker! Hmm I know one cool project! FPGA based Ethereum miner! I think there are even HDL sources for that available 🤔 And if not.. oh well, it's never too late for PhD XD
3:25 Really, the only CISC architecture that survived was Intel x86. And that survived because it sold into a market that was 10× or more larger than all the RISC machines put together. So Intel could afford to spend 10× as much on the necessary extra complexity to maintain competitive performance. So all the other CISC architectures (e.g. Motorola 68K, VAX) went extinct. Also some RISC ones (e.g. Alpha, SPARC) ran into trouble. But really, all the remaining serious alternatives to x86 nowadays are RISC: ARM, MIPS, POWER, and of course newcomer RISC-V.
wait... if standard on the lower level means flexibility on the upper level, standardization of the material means the flexibility on the spiritual level? guess Marx was right lol
IBM did partner with Motorola to create PowerPC (from Power), which was used by Apple (and Cisco) for a while, in between 68k and Intel. Motorola sold of that business, which as been passed around a few times since. We're still using the QorIQ iteration of PowerPC but the new chips are ARM. Intel mostly won out on market volume driving down costs (they even killed their own 64-bit architecture!). ARM, under licence, has managed something similar with the mobile revolution. It is beginning to look like ARM will get into more laptops (Apple) and servers but the Nvidia purchase combined with RISC-V is clouding the future.
For me Motorola was a supplier (chip manufacturer) to IBM and Apple. Partners for this video were placed on the same stack level. But I agree, you can use partner in different configurations.
@@AndreasSpiess I wouldn't put Motorola in the same league as IBM but I think recall you may have had more to do with mainframes in the past(?). In the 80s, the big battle was between Motorola processors (68k) and Intel - IBM just bought Intel chips and Intel won (Apple was Motorola 6502/68k). As an embedded developer, the chips of interest to me were Motorola (6502. 6809, 68k), Zilog (Z80, Z8000), Inmos (Transputer). Then I nearly used AMD RISC 29k but AMD botched it and I discovered PowerPC. PowerPC has worked well for over 20 years but it is more or less replaced by ARM now. Enough rambling, I have generally been happy with ARM as far it goes - it's the acquisition by Nvidia that I'm more worried about, the precedents are not good.
I worked for DEC back then. Not really mainframes, we hated them (including IBM, of course). But I always had MCUs around me and I know about these battles. In my opinion they were not too much related to the topic of my video. As I said: I had to shamelessly simplify. And the video was already 25 minutes long ;-)
Love your videos, but you make a false statement about Microsoft, Windows and Intel. You stated that Microsoft only supports Windows on Intel ISA. This is provably false as Windows NT ran just fine on MIPS (a RISC chipset) on my workstation at work in the 1990s. It also ran just fine on DEC Alpha and PowerPC systems (all RISC based). This included NT 3.5.1 and 4.0. Back then Intel lagged far behind others in computational performance so we often compiled applications to run in these alternative systems using the Window s NT API set. You also hammer home the fact that the companies "we're proud and didn't partner". This again is false and misleading as the PowerPC alliance included Motorola and IBM and a long list of licensees, including Microsoft. Keep in mind that at the time many PC manufacturers we're shipping on Motorola to include Apple, Atari, Commodore Amiga and others. To overlook this part of history in such a flawed way really takes away from this power of this video. Please consider sticking to the emerging tech, or reach out to an actual authority in the subject before producing videos like this.
I agree that this video takes my view and you have experienced other things during the last 40 years. Things are more complex than 15 minutes. I worked for DEC and was involved in some of those things. For me, NT back then was a minor thing compared to desktop Windows. Still in 1995 when I joined SAP, Unix people laughed about it (they were wrong). And I suffered when the much better Alpha disappeared against Intel silicone. I also did not read a lot about PowerPC recently. But maybe I am biased again. I never liked IBM. I always fought against them when I was young.
@@AndreasSpiess Thanks for the reply. I understand that the video format doesn't allow for all of the detail I just wanted to add this bit to the record. I think the video could have been more pointed without these "observations" which was the point of my original post. Personally, I used Alphas for some heavy computation and Motorola processors for embedded HW purposes in the 1990s, POWER and PowerPC RISC chipsets in addition to Sun and SGI systems. Actually, whey I think about it I used all of the RISC platforms at work. I guess I was pretty lucky. Personally I always view PowerPC as a Motorola initiative since they drove it down to the desktop with Apple and I'd been using Apples since 1979.. At the time (G4, G5) they had some really compelling systems vs. Intel. There was quite a push by Microsoft to get NT into the upper end of the desktop/ lower end of the workstation market that ended with NT4.0. I find it quite amusing that MIPS is making such a strong comeback in the 2020s.
@@retroattic4647 Thanks for bringing that history into the conversation. That was my experience as well. I've worked in the Bell System (when it existed), An *ix OS company, and Hewlett Packard over my career.
Brings me back. I worked on Unix compilers from 88 to 95. I worked on every RISC chip mentioned, plus Intel and Motorola CISC. You covered it very well.
I know it's unrelated to this video, but, have you seen anything abiding helium coin using LORA to communicate locations of rental bikes and scooters and delivery tracking information. I'm buying a box but I was wondering if you could advise me on an antenna that would be best to use. Thanks for all you amazing content. I'm hoping going to build a LORA network (following your video) to message with my friends soon too.
@@AndreasSpiess Ok. I'll have a look. Thanks for the reply. It would be interesting to hear your opinion on the Helium LORA network if it interests you.
Very nice video, where do you see apple there ? they switched from a top layer to the one under, and they could take a good 30% to 40% to intel and arm no ?
23:05 In fact, you might say RISC-V deliberately uses older technology in many ways, both to lower design/manufacturing costs and to avoid the potential for patent lawsuits. Even their approach to vector instructions evokes an older way of doing things that dates back to the original machines designed by Seymour Cray, but in this case they may actually be more forward-looking.
@@AndreasSpiess Its effects on the production economics of chips ? I think nothing much has changed with this. Nvidia buying ARM will make RISC-V harder to popularize rather than easier. ARM see themselves as the experts on RISC CPUs: "whatever you want in RISC, we already have it!" would be their slogan towards consumers screaming for RISC-V. implementations.
Great presentation, I learned a bunch of stuff that I hadn't before, despite my obsession with tech videos. Anyway, I understand your disappointment about the amount of open source on the silicon, but the piece that IS open source, I think, is exciting enough to still make it pretty exciting. That common standard you talked about will provide a free means to compatibility for a vast number of companies, and hopefully, software! I'm happy to wait for more open source silicon, because of the possibilities we will have now! unless I misunderstand something, which could easily happen here!
1:06 this distiller makes no sense to me.. normally you want the cooler to be just above the solution being distilled (like on the left of this image), so that the water can drip back down while the alcohol stays gaseous and can be collected (like on the right of this image). wtf
I know people don't find Richard Stallman very sympathetic but he is correct - and I understand why he's so mad with Linus. Linus Torvalds created the Linux kernel but it was the GNU project that created all the other parts including the Compiler. SAP did do some very interesting things and has a professional Suze available - with a free version also available. Very nice job!
Nice dose of cold water Andreas - for makers, a free-and-open-source tool chain is much more important than license-free-open-source silicon designs. With the Pi Pico, ARM has cleverly proven that its IP license is not exactly a significant tax on chip cost! And that ARM instruction set graphic is revealing! Clearly RISC is using some strange new definition of the word 'reduced'!
@@AndreasSpiess I'm quite puzzled then! ARM delivers on being a standard (ISA) quite well, the only complaint being that it is not open in that you have to pay a license fee. I'd rather pay a few cents per chip than a few thousand dollars entry fee for development tools licenses. But I quite see that a maker who wanted to play with soft-core processors on an FPGA or a large scale manufacturer who can amortize tools costs over hundreds of thousands of units might have a different view. I recall the famous cynical saying "the great thing about standards is there are so many to choose from" and note that bringing yet another ISA to market contributes less than nothing to this unless the new thing displaces all of the old. RISK-V will not succeed in this without clear market advantages and as far as I can see, the only thing it has going for it is being free-and-open-source, but that will need to apply to the whole 'eco system' not just the wanna-be ISA. Would Linux have got anywhere if developers, of whatever size, had to pay a fixed-cost license for a closed-source tool chain?
@@AndreasSpiess I certainly get the commercial argument, particularly since the NVIDIA takeover. Licence fees may be trivial as an increment on each chip, but they are still a potential point of commercial and political leverage and this is likely to be of particular concern to a Chinese company. But I do not get the "Lord of the Rings" strategy - there are too many standards so we'll make another, and by some kind of hand-waving magic it will be the "one standard to rule them all"! And re. the old standards joke - it is funny because it's true! A standard is not a standard if there is more than one in the same market.
If you want to put Windows and Linux in the same bucket, you should pick Windows NT as DOS-Windows was no real operating system. And Windows NT was designed to run on different hardware architectures and it is still to this day. It was even developed on non-x86 machines. They only reduced supported architectures because the market was too small.
My stack has something between hardware and applications. For the sake of simplicity I called it operating system. There I see Windows and Linux and others. Maybe you call this part differently. I agree that markets have a huge influence on technology and not always the best succeeds...
@@AndreasSpiessSorry, I should have added the timestamp. My comment was directed at your question @ 9:45 "Windows only running on Intel?". That was true only for 16-Bit DOS/Windows not for Windows CE or Windows NT+ (runs on ARM, MIPS, Alpha etc). Ein bissle Kugscheisserei muss sein ;-)
Genau! Leider wollte niemand das NT auf andern Plattformen. Ich weiss, wovon ich rede. Wir (DEC) hatten einen 1GHz 64bit Prozessor 10 Jahre vor Intel und niemand wollte ihn...
@@AndreasSpiess Jo, Intel war da recht spät dran. Und irgendwie will immer noch keiner Windows NT auf ARM, abgesehen von den letzten paar Windows-Phone-Nutzern...
Actually the title was a bit misleading, I thought I would not spare that much time to watch that content, and shelved it. Got a bit of time and get acquainted with very thoughtful and well researched review covering very many aspects of technology, business and history of electronic developments. Excellent video Andreas, a real gem.
@@AndreasSpiess I perceived the video would be mainly dedicated to the ESP32-C3 that does not have a robust toolchain at the moment thus not my piece of cake. The video was so much more than that. I would like to add one consideration to your CISC vs RISC discussion that was far from evident to me : CISC was not an oversight; at the time RAM was so expensive that it was much more economical to make the processor as sophisticated as possible to reduce the required code RAM footprint. (Just compare the number of FETs spent in a recent megaprocessor.com design on the decent 16 bits CPU and paltry 256 B memory.) The step change came along with the Gordon Moore's observation that was actually related to RAM chips. When there was enough fast RAM, design effort became focused on the CPU, and now the memory is lagging behind processors hence caches.
You are right with the expensive memory. And before RISC, nobody talked about CISC. We just had microprocessors. Only when RISC appeared they talked about CISC.
@@AndreasSpiess Yes, coining the term RISC undeniably helped promoting the concept of having more registers and exchange data with the memory using the dedicated instructions only. But it could be confusing to those who joined the party later.
The major problem in Risc-V progress are the "accelerators" usually written in ASM and making requirements to reimplement for the new architecture. Especially problem when some portion of RTL design is proprietary/under NDA
Correct side: OK. I found it interesting that the English "right" has two different meanings. I German we have two words (which are similar, but not the same)...
@@AndreasSpiess I can see how a non-native speaker might see some confusion, but there is some satisfaction in being able to say that 'left is right and right is wrong' when it comes to which side to drive on :).
Very interesting and educational, thanks! I just have one question: where does Apple's new M1 silicon fit in to this? And will the M1 shake and move the industry closer towards ARM? I've read several articles about Microsoft racing to produce their own "M1". Is this going to be the future of silicon?
For Apple using ARM on all their products is a big advantage. Microsoft does not have anything on Mobile, so they do not care so much. Now many applications will be ported to ARM. So maybe Windows on ARM will get a push. I am too old to value the speed of a processor too much. The next generation is always faster and power efficient.
@@AndreasSpiess But the M1 isn't just "more power efficient" - it's orders of magnitude more efficient - same single core speed as the latest core i7, but sips 5W instead of 125W!!! Thanks for your reply, by the way. Love your channel!
MS Windows 10 runs natively on ARM64 since 2019 - MS offers their own laptop Surface X with 8-core ARM CPU from Qualcomm (core is ARM Cortex A76 with IPC about AMD Zen1, BTW the new CPU core Cortex X1 introduced in 2020 and in current phone Samsung S21 has IPC about +5% higher than AMD Zen3). So basically everybody can buy license and manufacture its own CPU with higher IPC than best x86 CPUs from AMD or Intel. Not speaking about Apple M1 - this CPU is +60% IPC over Zen3 and has double IPC than Intel Comet Lake or AMD Zen2. Apple M1 is MONSTER and shows how AMD and Intel are years behind in CPU development. For example: - integer execution units: M1 = 6x INT + 3x Branch = 9-wide ...... Zen3 = 4x INT + 1x Branch = 5-wide ....... Intel TGL = 4xINT(2xbranch shared) = 4-wide - L1 cache for instructions: M1 = 192 kB ....................................Ze3 = 32 kB (6x less) .................................. Intel TGL = 32 kB (6x less) - L2 cache: ..........................M1 = 12 MB ..................................... Zen3 = 0.5 MB (24x less)............................ Intel TGL = 1.2 kB (10x less) - Reorder Buffer: ................ M1= 630 .......................................... Zen3 = 256 (2.5x less)............................ Intel TGL = 350 (1.8x less) Not speaking that ARM64 instruction set is much better than old garbage x86: - better/relaxed memory model for higher IPC - 32 registers for INT and FPU while x86-64 has only 16/16 - ARMv8.6 has MATRIX calculation instructions - ARMs SVE2 SIMD supports up to 2048-bit vectors (AMD supports only AVX2 with only 256-bit) - SVE2 is flexible: supports 128-bit up to 2048-bit while same SW can run at all these HW variants (x86 cannot do that because SW has to match HW) - SVE2 supports size-less types and can process unlimited length vectors far bigger than 2048-bit - decoupled SW vector length from HW FPU width (sci-fi for x86) - ARM releases every year new update for instruction set, today we have ARMv8.6 and new ARMv9 is coming soon (probably 2022 with Makalu) - and as last Apple M1 CPU has no 32-bit compatibility (was abandoned in 2017 with 1st super wide 6xINT CPU core A11 Monsoon) - x86 CPU has to keep ancient 16-bit and 32-bit compatibility even nobody uses that today (wasting transistors) - ARM announced for 2022 brand new Cortex CPU core architecture codenamed Makalu with 64-bit only as Apple
Thanks for the comparison! I think I mentioned, "until recently, Windows only supported..." I am curious how the market will react to the M1 in the Apple computer and which companies will offer ARM PCs... Because Apple owns the whole stack it seems to be easier for them to change the silicon., They also did it twice before...
Thank you, Andreas, that was very interesting. I remember in my twenties, when we had our 'own' portable hard drive which one could just about hold and carry under one's arm, in the 1970's. We would offer the portable hard drive up to the Archturis computer which would automatically accept the portable hard drive into the computer. I was hoping that someone would design and manufacture an update to the Ohio Scientific Challenger 3 series computers, (containing triple processors containing Z80, 6502 and 6800.) They incorporated two large 65kB floppy drives which ran continuously. As there are so many off the shelf commodies, it could be an interesting product. I wonder what the best choice of processor devices would be selected today?
@@AndreasSpiess Some Colleges had to dispose of these computers by physically taking the equipment apart. A few of them were rebuilt. They are used with a terminal and use 8" floppys, running CPM, Unix 3.0, and many other programs on the different processors. I purchased an Acer 915, a 286 computer for £ 1,700 and was 'sick as a parrot' when they brought out the 386 and then the 486 within the same year. I bought an Epson HX-20, computer with cassette drive. I chose the Epson HX-20 over the BBC computer because it was going through a problematic period. Although a basic computer, I found the HX-20 very useful for verifying my calculations at work. Unfortunately it has become intermittent which I believe is due to the 'conductive plastic' type of interconnection cables used. The Epson Technical Reference Manual for the HX-20 is a piece of Art. Showing how a computer manual should be written. The manual encloses test programs printed out from a 6301 cross macroassembler, some of which I have tried and they work well. Computer magazines were very helpful. PCN September 22 - September 28, 1983 provided a 6301 machine code disassembler for the HX-20 written by Elizabeth Wald. I entered the machine code into the HX-20 assembler and it worked. I printed out about 1" thick fanfold paper of the whole operation system program.
You riding yet? I had my first night ride with a summer kit last night here in California :-) When looking at the Linux kernal, I get the impression most software drivers are reverse engineered. Linus has said before that he tries to use the latest hardware because everything old is broken in kernel space. I'm no kernel dev, and have no ability to contextualize this. I've run Gource on the Linux kernal and other project git repos where it's easy to see the periodic nature of development and how various software branches stagnate. If RISC-V is the standard and grows to the size and complexity of an x86, I hope there is a much greater potential for ongoing maintenance and development of existing hardware support. I think we have already seen the plateau of hardware due to quantum effect size constraints. Which should mean there is no longer a reason to have our disposable device culture. How the culture shifts back to a long term serviceable and maintainable hardware philosophy will be interesting in my opinion and is my main hope for RISC-V. -Jake
I started with the road bicycle (500km). The Harley is still in the garage. It is still cold here. Concerning obsolesce: As you mention, the crowd is a good protection. This is why I stick to Arduino IDE and Raspberry Pi, for example. They survived already now longer than most other things.
Wonderful and comprehensive video. How viable would it be to emulate/interpret an ARM microcontroller in a RISC-V (or vice versa) just as a fun project? 😃 I've seen people emulating Nintendo NES (CISC 6502 ISA) on STM32 MCUs (ARM ISA) altough maybe there's no point in doing ARMRISC-V emulation since you can just compile C programs directly to ARM or RISC. Anyway... Great video 👍
Very good analysis of what is going on behind the curtains, makers are always so deep involved in their projects that they so not know what is coming from where. It is very difficult to find all these information in one place like your video and surely this will help makers to make decisions if/when they want to go for business. thanks for the deliting "nerd" videos I watch every sunday morning.!
Thank you Andreas for the theory and analysis...Very ,very important and on the spot... I never thought of this level in computing theory... As the Ancient Greek, Solon said " Always learning, getting older"... 73 de SV2LLJ
I'm going off in a different direction with this comment but... I can't say I'm the biggest fan of STM-32 but the Blue Pill and Black Pill are such CHEAP dev. boards their price attracts me. I'd rather not support ST because I don't like them much as a company *and they don't support RISC-V*. But the best (i.e. cheapest) (e.g.) Microchip dev boards are the AdaFruit Feather and they are so much more expensive and, it seems, with even "thinner" support than STM-32. I've not enjoyed STM-32 development anywhere near as much as AVR because the assembly language (yeah, I did say "assembly language"... I've got a severe "mental illness" that forces me to always use assembly language) has so many inconsistent compatibility layers it feels like Intel designed it ;) ... I'm also wondering if RISC-V will make me feel better there???
Your Windows story is not quite true. Windows ran on Alpha, ARM, MISC and Itanium for quite some time before those versions were cancelled in favour of x86 (and also x86_64)...
As said: I simplified a lot. NT on other platforms was not dropped. Just nobody used it because they did not get enough applications. As a DEC employee I suffered a lot because our Alpha was way better than x86. But nobody cared :-(
Ok, your video is misleading. You claim that only a small part of RISC-V is open source, and on your diagram, you present all sorts of totally unrelated things to the CPU, that are interchangeable, and they do not belong to RISC-V, even if they wanted to give you say all the specs for some wifi chip or whatever, it does not belong to them. I have heard this argument before, that RISC-V is not fully open source, is this what they meant? Cause if so, that's a false argument to trick the clueless, and sway them away to maybe x86 or ARM. RISC-V offer you an open source ISA, which is what you want to build stuff around this CPU. Once you have this, you know all the intricacies, all about how this CPU operates, and how you interact with it. Which is great not only for manufacturers, as they don't have to pay extra to build that wifi chip or whatever, just so they can work with RISC-V, but it's also great for open source firmware. It opens the door to developers to create their own open source firmware for peripherals or anything RISC-V related. It also opens the door to hardware manufacturers who wanna improve the architecture and build stuff around it. Ok, RISC-V won't give you the details to manufacture the CPU for free, and I don't see a problem with this. They have done a huge investment, if you wanna be a part of it, do your dues. Open source is not free as in beer, it's free as in freedom. They give you the freedom for it, but they invested a lot, why expect freebies? ARM, not only won't give you the details to manufacture for free, they won't even give you the ISA unless you are dealing with them, and if you do, you have to keep those a secret. Which means, no open source firmware, no-one gets to see how ARM behaves, its intricacies or whether there are security issues between an ARM CPU and a compiler. You might be able to read the code of an open source compiler, but you can't know much about ARM, other that the very little they might give. It's not only the IP they hold, they hold much more than that. And let's say should there be security 'issues' between an ARM CPU and compilers, good luck to those 5-10 employees who are working building their peripherals for their business, or their firmware or whatever to work on ARM, in finding those issues - not gonna happen. I'm not even gonna mention x86, the issues there are obvious, and some came out lately like spectre etc, but ARM is not better or safer either. There are huge issues in regards to security and closed ISAs or closed source firmware. Many people in the open source world have been vocal about those, with the creator of Ubuntu, one of them. He basically had said in the past, it doesn't matter how well we audit software, when you have to deal with closed source firmware. As for standards, standards are best when they emerge, not when one specific business dictates them. RISC-V does have standards, it also allows for modifications on the CPU, if there are needs for those. Again, I don't see anything wrong with it, we now have CPUs and specialised CPUs, NPUs, GPUs, etc. RISC-V is a huge step in the right direction, and I hope they succeed and surpass the rest.
Wonderful Swiss accent ;) I wish other makers extend the IP for WiFi and Bluetooth, and LTE, GNSS, JTAG. Floting point ALUs, GPUs, AI ... etc. So we could have a chip for smartphone that we truly trust (somehow). Hopes and dreams.
You got two important points wrong right off the bat: Early processors were quite RISCy, microprocessors even more so. Chips like the RCA 1802, the Motorola 6800 family, and the Mostek 6502 were essentially 8-bit RISC chips. CISC designs grew out of mini and mainframe CPU designs, and were designed for assembly language programmers. The pinnacle of this design ethos was probably the DEC VAX, or maybe Prism, which never saw a customer install. Early RISC designs, most especially MIPS and SPARC, were created by analyzing thousands of programs compiled with C and Fortran compilers, then implementing the (mostly Motorola 68000 family) instructions the compiler actually used. Most compilers used a tiny subset of the instructions available on CISC chips. Modern "CISC" chips like the Intel Core i series microcode these instructions and never bother to optimize them. The focus is on the instructions that compilers use.
I agree that the early processors were simple. However, I would not classify is as "wrong" because nobody talked then about RISC. It first needed CISC to find out what RISC is.
Well, looking at current MCUs from TI, STM, MPCHIP/ATMEL, NXP/FRSCL, etc. what really matters is how many of 'em I can get for a buck. Freescale, TI and STM usually have cheap Cortex-M products (that is before the covid shortage). So if I get a typical CM3 (TQFP-32 to 64 with some 32k RAM and 64k flash) for 0.5~2$ a piece in volumes, then who cares whether RISC-V rocks or not. But if I could get more R-V MCUs (comparable SoC to the typical CM3) for the same amount of money, then I am all game. As for now the easiest to get RISC-V are scarce anyways (like the SiPeed AI-modules with a 64bit core for 10$ on Ali and ESP32-C3 with a 32bit core for much less $) whereas CM0~7 are basically everywhere (even recyclable from old hardware). Money/costs and availability will decide I'd say, not the fact that it is open source (even if open source could be the reason to drive some costs down).
Crucially, the main aspect of RISC-V which is not open-source, is any individual implementation. One can not independently verify that the chip you have in your hand precisely matches the behavior of the open-source RTL that defines any particular RISC-V. In fact, the implementation most assuredly will differ. At the very least, manufacturing test structures that provide deep observability into the state of the uProc will have been added, frequently along with on-chip instrumentation. What is not open-source between RTL and silicon that should be for any device is: post-synthesis gate-level net-list byproduct of the place-and-route step along with the technology libraries, the LEF and DEF that describe the layout and, finally the GDS-II for the device. But, RISC-V providers will not release any of these design descriptions.
I think you missed a particularly interesting RV chip- the K210. Dual core 600MHz 64 bit with FPU, 8MB of RAM, and numerous accelerators for audio recognition, AI, and so forth. Very inexpensive and available in several different SBCs from Sipeed for around $20-30 that include a color LCD, micro SD, VGA camera, onboard microphone and stereo audio amplifier. It has 64 I/O ports as well, though many are dedicated. It ships natively with microPython and is very powerful, not sure how successful they were after their Kickstarter that I tried, but I had a very positive experience.
Unfortunately, I do not see a lot of projects using the K210 even it is an impressive chip. Libraries and projects are very important for the acceptance of hardware in the Maker community.
A few minor issues that I would like to correct: RISC architectures are generally slower than a well developed CISC one within the scope of applications that it were developed for. Since the CISC architecture can leverage more advanced functions to do more work without needing to cycle through any control logic between operations within the instruction. While a RISC architecture will need to implement the same instruction with a set of simpler instructions, where each of these instructions will need to be processed by our control logic. This decreases the performance of the RISC architecture, and usually also the power efficiency as well. Even with instruction compression (aka microcode) this problem still remains. (and yes, x86 does contain microcode as well, but then it is typically building further on top of what it already has. It does also do some simplifications of some instructions, but x86 is CISC. But x86 isn't a perfect CISC architecture, nor the only CISC architecture.) And your example of compiler complexity in regards to CISC and RISC, it is typically the opposite to what you described. Compiling on CISC tends to require more effort than a RISC architecture. Since we can't measure the intensity of the work of converting our code to instructions by how many instructions were required in the end product. It would be like comparing the complexity of a given code based on how many lines including comments it consists out of. Having RISC as a standardized ISA is also a bit bogus. Since different architectures can take fairly drastically different approaches to similar problems, for larger system related reasons, making it infeasible for them to share a common ISA. Ie, the future of RISC-V isn't going to create a standardized ISA in the market. And to be fair, even GNU/Linux is very fragmented in its support due to its various distributions that makes running software on it a living hell at times. ARM already is fairly fractured in a similar fashion, where one ARM chip doesn't run/support stuff natively, even if stuff is compiled for ARM. RISC-V is likely to end up in a similar situation in fairly short order. Making the standard more strict will only limit RISC-V's ability to be applicable for more varying approaches to architectures. In the end. The main advantages for RISC-V is that it can be used as a lower cost alternative to ARM in some sections. Where device makers can adapt the core to their needs without having to undergo the development of the whole thing themselves. In higher performance markets, it to a degree will have issues competing, since the RISC-V ISA is fairly limited in what architectures it can implement.
Consider the following scenario: You need to make a device that is small and battery powered, so as few chips as possible. Some parts need fast response times, so you need some form of specific hardware. Some parts of the implementation require complex decisions that could not be implemented in pure hardware. It is too complex to be implemented using only software in a microcontroller. So what's left ? Self booting FPGAs or CPLDs. The hardware part fits right in, no problem there. What about the "software" part ? You need to implement a so called "soft core" a piece of hardware looks enough like a CPU so it can run code. Now, last question, what machine code will I have to use ? Either I use an "in house" thing in which case I need to develop an adapter for an existing compiler OR Use a known (closed) machine code and risk being sued my eyeballs off Hmm, an open source ISA seems like the right answer: It is standardized, so someone could write tools for it and no risk of getting sued. If it also can be extended it is even better, I can have a very tight integration between my new custom opcodes and the specific application hardware. So, one of the very big candidate uses for RISC-V is as embedded soft-cores. This is besides the original use of RISC-V which was academics (example code in teaching material).
