[HN Gopher] RISC-V Pushes into the Mainstream
___________________________________________________________________
RISC-V Pushes into the Mainstream
Author : PaulHoule
Score : 146 points
Date : 2022-12-23 13:27 UTC (9 hours ago)
(HTM) web link (semiengineering.com)
(TXT) w3m dump (semiengineering.com)
| eternityforest wrote:
| Riscv seems really cool. It's come so much farther than I would
| have guessed and seems to have a bright future.
| user3939382 wrote:
| As a high level language programmer, I look forward to
| understanding my computer all the way down i.e. including the ISA
| which is not happening on amd64.
| FullyFunctional wrote:
| TSMC is not going to give up their trade secrets, sorry.
|
| Also, if you are using a high-end RISC-V (none on the market
| currently), then the implementation is going to be proprietary
| and decidedly non-trivial.
|
| I'm not sure in which sense you expect to "understand your
| computer".
| mike_hock wrote:
| And you can definitely understand amd64 on an ISA level,
| which is the publicly documented "high" level interface.
| user3939382 wrote:
| I didn't find it accessible.
| sanxiyn wrote:
| Well, you could go buy and read Fundamentals of Semiconductor
| Fabrication (I did). This should give you understanding
| comparable to reading The C Programming Language. Yes, it is
| shallower understanding than what you would get by writing a
| C compiler yourself or working at TSMC, but it definitely is
| still understanding.
| user3939382 wrote:
| This is a surprisingly snarky/nasty comment "sorry"
|
| > I'm not sure in which sense you expect to "understand
|
| How about this? https://riscv.org/technical/specifications/
| If there are a few extensions buried in the chip that doesn't
| materially change what I said.
| mike_hock wrote:
| The equivalent manuals are available from Intel and AMD.
| user3939382 wrote:
| The issue isn't the manuals existing it's what they
| describe. Basically the R in RISC.
| connicpu wrote:
| For understanding what's going on all the way down to the ISA
| level, I'd say something like a PIC microcontroller is even
| easier since they tend to have only around 50 instructions,
| though RISC-V has the advantage that it could scale all the way
| up to potentially desktop CPUs some day
| psychphysic wrote:
| Im a big supporter of RISC-V doing my best to buy the hardware
| where possible and use it.
|
| The biggest hindrance to it is lack of software and distro
| support.
|
| The VisionFive2 is a lovely board but so far we only have a
| barren bootrom. No idea of OpenGl, OpenCl work on it!
|
| Someone lied about distro support being confirmed. StarFive
| probably...
|
| But those lies could torpedo the whole project.
|
| The early days of android were bogged down with complaints of
| fragmentation, patchy support.
| mananaysiempre wrote:
| Is there a decent hardware manual even for the first
| VisionFive, say to the extent the original BeagleBoards had one
| (even if the Pis never did)? I wanted to write a (slow)
| emulator that could at least boot the Ubuntu image into text
| mode, but I have absolutely no idea how it all hangs together
| beyond the SoC docs. For that matter, the page for the
| Unmatched doesn't have a link to a hardware manual either.
| rwmj wrote:
| We're actually waiting for VF2 boards to be delivered and then
| we'll have a go at porting Fedora 37.
| GoOnThenDoTell wrote:
| The star64 (from pine64) might have a better chance of being
| well-supported
| count wrote:
| It's been a while but nothing from pine64 was well supported
| without hacky 3rd party custom kernel rolls and the like,
| with no apparent effort to move stuff into mainline.
|
| I hope that's changed?
| snvzz wrote:
| With the same SoC, it should be about identical support-wise.
|
| It just launched, give it time. The whole point of VisionFive
| 2 is precisely to get these boards to developers in large
| numbers so that it can all be bootstrapped.
| [deleted]
| snvzz wrote:
| >The VisionFive2 is a lovely board but so far we only have a
| barren bootrom. No idea of OpenGl, OpenCl work on it!
|
| It is the first raspberry-pi like <$100 RISC-V SBC, and it only
| started shipping to customers last week.
|
| It is also the first board with a large run (long thousands vs
| short hundreds).
|
| Maybe there's just one Debian image and little documentation on
| how to get it all up and running, but that's today.
|
| In a month, it'll be a different story. That's the whole point
| of getting these into the hands of developers.
| Vt71fcAqt7 wrote:
| >The biggest hindrance to it is lack of software and distro
| support.
|
| https://debian.starfivetech.com/
|
| Ubuntu is working on it as well. May already be done I'm not
| sure
|
| As for software see _RISC-V Summit 2022--StarFive 's Efforts in
| Fuelling RISC V Software Ecosystem_[0]
|
| There is a lot of work being put into this, not only by
| StarFive but by other companies, the Chinese government (via
| the Chinese Academy of Sciences), researchers and hobbyists
| (once boards arive).
|
| [0]https://youtube.com/watch?v=VfA2HLibOOY
| andrekandre wrote:
| just booted up in debian on the visionfive 2 just this night
| (flashed to an sdcard from that very same link above)
|
| though 4k monitors dont work yet from hdmi... seems some kind
| of bug...
| BlueTemplar wrote:
| Let me guess : issues coming from recent monitors expecting
| DRM ?
| monocasa wrote:
| I've heard that the first rev of the boards have some
| signal integrity issues that should be fixed in later
| revs.
| the__alchemist wrote:
| I've only coded for ARM. On those devices, the toolchains etc
| handle the code logic, and each ARM device will have its own
| peripherals.
|
| Working at the MCU-register level and higher, is there any
| difference in RISC-V? Or does it only matter if writing compilers
| and toolchains?
|
| Maybe the way you handle interrupts changes? Eg you would no
| longer use a cortex-m library to handle them. Maybe low power
| modes too, since those use ARM registers in addition to MCU-
| specific ones?
| RobotToaster wrote:
| Most of the time it's only an issue if you're writing assembly.
| P_I_Staker wrote:
| Basically, No, IMO. I do embedded systems. Most of the
| important differences, would be covered under the peripheral
| side. Assuming you move to a drastically different ARM chipset,
| there would be no difference.
|
| As disappointing as it may be to some people, architecture
| rarely winds up mattering much (although you might be able to
| argue that some elements that make it into the peripherals are
| "architectural"). At least for software developers, there will
| never be a reason to dig into architecture. Maybe for some
| stuff interrupt, or hardware exception related.
|
| I've found that the specific chipset and compiler tend to be
| more important for software developers working close to
| hardware. Even ASM code probably won't really matter, unless
| you plan to heavily rely on it; I would guess it could come
| into play if you plan on writing heavy ASM code, which I doubt
| you'd ever do on a modern architecture... maybe you're REALLY
| trying to save memory, or think you can improve CPU performance
| for some reason. Seems far fetched in almost every application,
| but I bet people out there are doing it for good reasons.
|
| Of course, there may always be little places where you end up
| doing stuff with ASM, but again IME they tend to be where the
| peripherals and architecture meet.
| Sirened wrote:
| It is fairly different from a systems programming perspective.
| The base instructions (I) are essentially everything you'd
| expect when writing any kind of regular program and it feels
| very normal and natural for anyone who has ever written
| assembly, but once you start needing fancier things like
| exceptions you'll see a lot of new RISCV specific design
| choices. This is sort of to be expected, x86 has a different
| exception architecture from ARMv8A. It's just different, not
| necessarily less capable. Odds are whatever RISCV MCUs come on
| the market will eventually be supported with the same SDKs you
| know and love, but they will have a different implementation
| for all the system specific functions.
| jimmaswell wrote:
| What's the elevator pitch for RISC-V? My intuition is that RISC
| was dead for good reason.
| audunw wrote:
| Dead simple base ISA and easily extensible means it's an
| obvious choice if you want a custom processor with your own
| custom instructions.
|
| Scalable so the same ISA (with/without certain extensions) can
| be used from the smallest microprocessor to high end CPUs.
|
| Compressed instructions gives very high code density (and
| unlike ARM Thumb doesn't require weird mode switching and is
| available for 64-bit ISA)
|
| It's not the first popular open ISA. There was OpenRISC before
| it, but it was fatally flawed (branch delay slots). So RISC-V
| is arguably the first _good_ popular open ISA.
| erk__ wrote:
| There is also OpenPOWER (under the Linux foundation) which I
| assume is also good?
|
| Or is RISC-V stictly better than it?
| panick21_ wrote:
| OpenPOWER simply wasn't open, it was simply marketing. Only
| years after RISC-V started to grow did they change their
| licensing.
|
| RISC-V is more modular and and by now has far more support
| behind it.
| classichasclass wrote:
| OpenPOWER is also an open, royalty-free ISA. You're right
| that PowerPC and Power ISA didn't _start_ open, but they
| weren 't called OpenPOWER.
| classichasclass wrote:
| I have several OpenPOWER systems, including the POWER9 I
| use as my usual desktop. Besides IBM and other server
| manufacturers like Tyan and Wistron, you can get them as
| Raptor workstations and servers.
|
| If you want an OpenPOWER design to play with, look at
| Microwatt ( https://github.com/antonblanchard/microwatt )
| which is complete enough to boot Linux.
| mozball wrote:
| Compressed instructions
| (https://en.wikipedia.org/wiki/Compressed_instruction_set)
| negate one of the "good reason"s
| [deleted]
| gchadwick wrote:
| Licensing innovation - The open licensing model, anyone can
| make a RISC-V implementation, there's some rules/costs involved
| if you want to use the RISC-V trademark with it:
| https://riscv.org/about/risc-v-branding-guidelines/ but
| certainly a lot cheaper and permissive than arm's architectural
| licensing model.
|
| This enables far more competing RISC-V implementations, with
| more choice and more ability to modify things to your needs.
|
| On the downside you could see eco-system fragmentation and lots
| of subtle incompatibilities causing issues for broad software
| support.
|
| Ultimately anything technical happening is secondary to this,
| this is the reason RISC-V is taking off, not anything to do
| with technical superiority (it simply needs to be good enough).
| hakfoo wrote:
| "Good enough" is an incredibly big thing.
|
| RISC-V doesn't have to displace M2/Epyc/Xeon to be important.
| There are a trillion cores a year being shipped in embedded
| devices where "cheap and configurable" is more important than
| raw performance.
|
| What surprises me is that we haven't seen more "built to
| emulate" designs yet. Many of those "trillion cores" are
| zombie architectures with terrible price/performance ratios,
| but nobody wants to rewrite their software or retool things
| (anything 8051, AVR or PIC seems vulnerable). I could see
| replacement modules using a cheap-due-to-scale RISC-V core
| that just emulates the old chip in baked-in firmware.
| rwmj wrote:
| "Permissionless development" - want to develop a RISC-V core?
| Just download one from github or design your own from the
| freely available specs. No legal agreements to enter or
| licensing fees to pay. Very different model from Arm (sign a
| legal agreement before you start and pay for licensing) or x86
| (you want a license? LOL)
|
| RISC is hardly dead. It more accurate to say it won so
| comprehensively that it's pervasive. The design principles are
| now used in every significant chip (including x86).
| GoOnThenDoTell wrote:
| Not dead at all, its now a (conceptual) rocket ship
|
| No ISA/architecture licensing fees, no restrictions on what you
| can do with it - you can build an open source core or you could
| sell your design to others. ARM/x86 doest have this, its all
| locked up behind lawyers.
| snvzz wrote:
| >RISC was dead
|
| Dead how? I don't get it.
|
| They're literally everywhere, dominating the numbers both
| shipping right now and cumulative.
|
| Every new ISA of any significance in the last 3+ decades is
| RISC.
|
| The only pre-RISC legacy ISA in use is x86, and it is only
| losing market share.
| cesarb wrote:
| > The only pre-RISC legacy ISA in use is x86, and it is only
| losing market share.
|
| The only pre-RISC legacy ISA in _wide_ use is x86, but AFAIK
| the legacy ISA from IBM mainframes (s390 /s390x), which is
| still supported by mainstream enterprise Linux distributions,
| is also a pre-RISC one.
| error503 wrote:
| > The only pre-RISC legacy ISA in use is x86, and it is only
| losing market share.
|
| And for many generations now, x86 machines are basically RISC
| processors with a CISC frontend.
|
| Empirically it seems that CISC has 'failed' as a way to
| design processors, and it's better to let the compiler do
| that job when you're building a general purpose computer.
| marcosdumay wrote:
| Well, to be fair, this was easy to predict. RISK was only
| created because CISC did already fail at that time; people
| were already letting their compilers do the job and left
| the specialized instruction basically unused.
| RobotToaster wrote:
| >My intuition is that RISC was dead for good reason.
|
| ARM cores run most phones, routers, etc, and it's an acronym
| for Acorn RISC Machine.
| KMag wrote:
| Last I checked, most hard drives contain ARM cores, so some
| x86 machines actually contain more ARM cores than x86 cores.
| An ICE car likely has one or more ARM cores managing the
| engine and one or more ARM cores running the entertainment
| system.
| NoThisIsMe wrote:
| Isn't ARM a RISC? So no, far from dead, RISC is already hugely
| successful.
| marcosdumay wrote:
| ARM, MIPS, Power are all RISC. The only real CISC processor
| in mainstream usage seems to be the PICO, and of course, the
| x86 and amd64 are currently RISC processors with a CISC
| interpreter in front of them.
| solarkraft wrote:
| Some argue it has actually become a CISC (special
| instructions for JavaScript and so on), but I don't know how
| RISC-V compares.
| monocasa wrote:
| ARM's JavaScript instruction is actually a pretty good
| example of RISC philosophy. The instruction is a single
| cycle floating point conversion to integer using x86 abi
| default rounding modes rather than the rounding modes in
| the flag register. It's a great example of the RISC
| filtration test of 'what's a single cycle instruction that
| can be noticed in instruction traces as something that will
| give an actual perf improvement'.
| Sirened wrote:
| RISC is not about the number of instructions but rather
| _what_ the instructions do. The famous example of CISC gone
| to its logical extreme is the VAX 's polynomial multiply
| instruction, which ended up being almost a full program in
| a single instruction. RISC tends to go the other way,
| focusing on things that are easy for hardware to do and
| leaving anything else to software.
| jasonwatkinspdx wrote:
| In addition to the permissionless model as mentioned, another
| consideration is to standardize all the boring common bits.
| RISC-V incorporates a lot of industry learning about how to
| handle extensions, compression, etc. If a company is
| considering RISC-V vs a proprietary design for an accelerator
| or such, getting debugged versions of those features in the ISA
| vs whatever gets cooked up in house in crunch mode could be
| pretty big.
| andrewclunn wrote:
| Apple brought their chipset in house, using ARM is a base, to
| control their supply chain, cut costs, and allow for a RISC based
| architecture (which honestly just makes sense now these days).
| The biggest hinderance to RISC-V adoption will be if ARM remains
| customizable, cheap (from an IP perspective), and has widespread
| adoption. Honestly, I'm okay if RISC-V remains somewhat niche,
| but provides the necessary market pressure to keep non-open
| competitors honest. There's a meta-benefit to open standards as
| well.
| SanjayMehta wrote:
| Apple had a job listing last year for something which needed
| RISC-V knowledge.
|
| https://www.tomshardware.com/news/apple-looking-for-risc-v-p...
| qwytw wrote:
| It's common knowledge their are planning to replace some of
| their low-end embedded cores with RISC-V ones.
|
| RISC-V is probably 5-10 years behind on the upper end though
| tormeh wrote:
| Apple has a perpetual ARM license. It's unlikely they'll
| transition to RISC-V.
| snvzz wrote:
| I do not know the details of Apple's agreement with ARM. AIUI
| they are not public.
|
| But I do know they have a perpetual free RISC-V license like
| everybody else.
| justahuman74 wrote:
| In a long time horizon, it's probably in Apple's interest
| to migrate away from ARM just so that they have one less
| company to negotiate with or receive restrictions from
| klelatti wrote:
| Apple helped to design Arm v8 they probably have huge
| influence on the direction of travel of the ISA. Plus
| they have huge investment in Arm based software and
| probably get access to all of Arm's IP (eg big.LITTLE).
|
| They will migrate when there is a major performance
| advantage (as in the past).
| gchadwick wrote:
| My suspicion is they'll fork the arm architecture at some
| point (either via a legal agreement with arm or just taking
| the deploy the lawyers approach and doing it unilaterally).
| Apple like their walled gardens and closed eco-systems so
| there's no clear reason for them to switch to RISC-V whilst
| they're very happy with their arm eco-system.
| jasonwatkinspdx wrote:
| Apple is in a unique position with a perpetual ARM license, so
| they don't feel any particular competitive pressure from
| RISC-V. In fact they're adopting it for microcontrollers and
| such.
| GoOnThenDoTell wrote:
| ARM committed the sin of suing a really big customer of theirs,
| so there is likely some exit-seeking all around the industry
| klelatti wrote:
| I'm not sure what else Arm is supposed to do if it believes
| that the really big customer has broken their contract with
| them?
|
| I actually think this ought to be a positive for customers
| who are clearly abiding by the terms of their contracts.
| GoOnThenDoTell wrote:
| It doesn't matter which party is correct, its now added
| risk that ARM could be the bad actor
| klelatti wrote:
| Why if Arm is correct does that add a risk that it's the
| bad actor?
|
| Most firms will have legal departments can look at this
| case on its merits and decide whether or not Arm is
| acting in bad faith.
|
| If I'm another Arm customer I definitely don't want a
| competitor playing fast and loose with its Arm contract.
| smoldesu wrote:
| > Why if Arm is correct does that add a risk that it's
| the bad actor?
|
| Because nobody wants to fight over the licensing of a
| product they're shackled to. If you could buy a RISC-V
| board with software support similar to a Raspberry Pi,
| ARM's goose would be cooked. Every enthusiast would ditch
| ARM in a heartbeat for a more open ISA, and ARM licensees
| would see it as an opportunity to finally wiggle free of
| ARM's insane license restrictions. All we need is the
| software support, which should be pretty forthcoming
| since most projects have already been optimized for RISC.
|
| ARM could unseat x86 because both ISAs were encumbered
| with licenses at the time. Now, ARM is competing with
| much less restrictive architectures, and all it would
| take is a FOSS RISC instruction set to ruin their value
| prop.
| qwytw wrote:
| > of ARM's insane license restrictions
|
| You're assuming high end RISC cores will be available for
| free and or under much more favorable licensing than ARM
| cores. Which seems unlikely, why would someone sell their
| cores to a competitor for less than a company whose only
| business is designing them?
| monocasa wrote:
| Same reason why people would contribute to an open source
| compiler and toolchain and distribute for less than the
| cost of the old school paid compiler vendors like
| Borland. These contributors aren't really in the business
| of selling compilers and simply have strategic reasons to
| drop the floor of that market as much as possible. The
| same applies to RISC-V cores, with probably the most
| prominent example being Alibaba/T-Head and their open
| source cores.
| klelatti wrote:
| > Because nobody wants to fight over the licensing of a
| product they're shackled to.
|
| So when a firm licenses a RISC-V core from SiFive they
| should be free do whatever they want with that core
| irrespective of the license terms?
| smoldesu wrote:
| No, but they have the freedom to design their own core if
| SiFive threatens them in the way ARM does.
| klelatti wrote:
| So you believe that firms should abide by contracts but
| that firms shouldn't try to enforce the terms of those
| contracts.
|
| I find it odd how Qualcomm is portrayed as though they
| were innocently minding their own business when they
| suddenly got sued. They bought Nuvia knowing what was in
| the two sets of contracts.
|
| Also Qualcomm had and still has the ability to design
| their own Arm cores.
| smoldesu wrote:
| I'm not talking about Qualcomm, really. I'm talking about
| companies like Apple, who really only have a cursory
| attachment to ARM as an ISA. Then there's the hundreds of
| smaller manufacturers who have _zero_ attachment to ARM
| and would much rather build hardware on their own terms.
| _Those_ are ARM 's moneymakers, and those are the
| companies that frankly have the most to gain from using
| RISC-V.
|
| If Qualcomm is a relevant topic regarding ARM's success,
| then they've arguably already failed.
| klelatti wrote:
| > would much rather build hardware on their own terms
|
| Most of these firms are licensing a core from a third
| party. There is no such thing as 'on their own terms'.
| smoldesu wrote:
| Not Apple or many of the smaller manufacturers. Even
| still, the ones who _do_ want to license core designs
| still have the option to do so with RISC-V.
| error503 wrote:
| Does Apple pay _anything_ meaningful to ARM? They 're a
| founding member with (I believe still) a significant
| stake. I find it doubtful they didn't secure themselves a
| perpetual license when they founded the company, and that
| seems to be what the Internet believes to be true.
|
| I'm not so sure it's the expensive large chips, made in
| relatively small quantities, that make ARM the most
| money, do you have a source? I'd have guessed they
| actually make more on the billions of small ARM cores
| that ship every year that end up by multiples in pretty
| much every device with a battery or power cord. And
| these, I think, are at the biggest risk of leaving ARM.
| RISC-V development is mature enough at this end of the
| market that it's relatively easy for users to transition,
| there are multiple competitive cores on the market, and
| there's no concern here about backwards compatibility
| because these are embedded systems where there's usually
| not an expectation of having to run user code at all. It
| will be much harder for the likes of Qualcomm where
| there's a huge ecosystem built around their ARM
| processors - but as a share of cost-per-processor, they
| probably stand to gain the most. Qualcomm is a founding
| member of the RISC-V foundation after all.
| ip26 wrote:
| It's not obvious who is in the right, and in my armchair
| opinion it looks like ARM has a slightly weaker argument.
| IANAL, but all of this makes ARM appear more litigious than
| egregiously wronged.
| 0cf8612b2e1e wrote:
| All it would take is for AWS/Azure to start offering a RISCV
| Graviton-like system and I suspect we could see development
| skyrocket.
| fundad wrote:
| Agree and that would be the result of a lot of development.
| Vt71fcAqt7 wrote:
| I've had the same thought and took it even further. The cloud
| companies are in the business of managing capital, namely
| datacenters. They are not in the business of designing
| uarchs; to the extent that they do (ie. Graviton) it is to
| lower costs. For this reason I belive it is economically
| favorable for them to jointly create and fund an open uarch.
| Note thay they are already doing this through a middleman
| known as the Intel/AMD monopoly. Also note that a similar
| thing has happened already with Linux. Collectively throwing
| a few hundred million at the problem (or buying sifive, for
| example) _could_ save money in the long run. Although I can
| 't be certain about that.
|
| I hope someone pitches this idea to these companies. I think
| some people at Google may be thinking in this direction being
| that they are paying for tape out of open hardware at no cost
| to the developers and are investing in tooling.
| monocasa wrote:
| That's what Alibaba is already doing too. They bought
| T-Head and have been releasing open source RISC-V cores
| that have been taped out in a move to "commoditize your
| complement", thus bringing total costs down by making their
| vendors' markets more competitive.
| BirAdam wrote:
| ARM is already attacking one of their largest licensees, and
| RISC-V is already in use at Apple. As Apple's hardware
| accelerated x86 translation proves, they can proficiently
| transition to any hardware platform. The ISA really isn't that
| important anymore, and I expect Apple to do what makes the most
| sense regarding price/performance.
| qwytw wrote:
| Well switching to a new architecture is still probably
| extremely expensive which would permanently shift
| price/performance in favor of ARM unless RISC actually
| provides something unique.
|
| Freedom from licensing etc. shouldn't be a problem for Apple
| unless maybe if they want to sell their chips to 3rd parties
| which doesn't seem too likely.
| Varloom wrote:
| Lets go !
|
| After decades of open-source software, finally we have open-
| source CPU.
| jlokier wrote:
| Not yet. With a couple of exceptions, the RISC-V CPUs described
| in the article are all closed source.
|
| RISC-V is an open instruction set, so anyone can implement
| their own design using it, often with their own proprietary
| extensions.
|
| Because the instruction set is open, there are indeed hundreds
| of open source RISC-V designs out there, because basic CPU
| design is fun, easy and educational.
|
| However, at the moment, nearly all physical RISC-V CPUs you can
| actually buy, dev boards etc, and devices containing them, use
| closed source CPU designs.
| monocasa wrote:
| I wouldn't quite say that's the case. Two of the three full
| Linux capable RISC-V SoC releases this year are using open
| source CPU cores. The BL808 and the Allwinner D1 both use
| T-Head CPU cores that are available on GitHub
| https://github.com/T-head-Semi/openc906 . The JH7110 in the
| VisionFive2 and Star 64 does use a closed CPU core however.
| [deleted]
| aappleby wrote:
| Ibex is open source and has taped out -
| https://github.com/lowRISC/ibex
| solarkraft wrote:
| I have an ESP32-C3 and it _just works_!
|
| Sadly I haven't found much new it enables yet either (because at
| this point Xtensa is quite well supported too).
| sircastor wrote:
| Realistically, it doesn't really enable anything new. It's
| largely a replacement for the ESP8266. It has a few more
| features of course, but I think the point of early RISC-V
| products is that they're comparable to existing ARM (or other
| ISAs) products in their respective spaces.
|
| I like that the ESP32-C3 is a RISC-V chip, but I realized after
| playing with it for a week that it turned out to not mean much
| - that's probably because I'm a pretty simplistic user though.
| solarkraft wrote:
| A few years ago the only Wifi MCU you could use Rust on was
| an obscure Realtek one - because it had an ARM core. Having a
| standard core would've been a great benefit back then, but it
| seems like nowadays all the tooling you need has been ported
| to their current architecture as well.
| sircastor wrote:
| If I go through my parts box it's not hard to find Wifi
| modules that require a substantial amount of config and in
| some cases a solid understanding of how WiFi works. And
| they were 10s of dollars a unit. I'm delighted that modules
| like the ESP8266 showed up and made it easy and shockingly
| cheap. There was a real windfall moment when Arduino syntax
| was ported to the 8266, and Espressif has really taken
| advantage of it.
| pclmulqdq wrote:
| Several other ARM-based wifi MCUs existed from the major
| semiconductor companies (TI) and other competitors (Nordic
| Semi).
| tmpburning wrote:
| [dead]
| zackmorris wrote:
| Does anyone know of a good wiki for doing multicore RISC-V on
| FPGA? Something more substantial than:
|
| https://www.reddit.com/r/RISCV/comments/z6xzu0/multi_core_im...
|
| When I got my ECE degree in 1999, I was so excited to start an
| open source project for at least a 256+ core (MIPS?) processor in
| VHDL on an FPGA to compete with GPUs so I could mess with stuff
| like genetic algorithms. I felt at the time that too much
| emphasis was being placed on manual layout, when even then, tools
| like Mentor Graphics, Cadence and Synopsys could synthesize
| layouts that were 80% as dense as what humans could come up with
| (sorry if I'm mixing terms, I'm rusty).
|
| Unfortunately the Dot Bomb, 9/11 and outsourcing pretty much
| gutted R&D and I felt discouraged from working on such things.
| But supply chain issues and GPU price hikes for crypto have
| revealed that it's maybe not wise to rely on the status quo
| anymore. Here's a figure that shows just how far behind CPUs have
| fallen since Dennard scaling ended when smartphones arrived in
| 2007 and cost/power became the priority over performance:
|
| https://www.researchgate.net/figure/The-Dennard-scaling-fail...
|
| FPGA performance on embarrassingly parallel tasks scales linearly
| with the number of transistors, so more closely approaches the
| top line.
|
| I did a quick search and found these intros:
|
| https://www.youtube.com/watch?v=gJno9TloDj8
|
| https://www.hackster.io/pablotrujillojuan/creating-a-risc-v-...
|
| https://en.wikipedia.org/wiki/Field-programmable_gate_array
|
| https://www.napatech.com/road-to-fpga-reconfigurable-computi...
|
| Looks like the timeline went:
|
| 2000: 100-500 million transistors
|
| 2010: 3-5 billion transistors
|
| 2020: 50-100 billion transistors
|
| https://www.umc.com/en/News/press_release/Content/technology...
|
| https://www.design-reuse.com/news/27611/xilinx-virtex-7-2000...
|
| https://www.hpcwire.com/off-the-wire/xilinx-announces-genera...
|
| I did a quick search on Digi-Key, and it looks like FPGAs are
| overpriced by a factor of about 10-100 with prices as high as
| $10,000. Since most of the patents have probably run out by now,
| that would be a huge opportunity for someone like Micron to make
| use of Inflation Reduction Act money and introduce a 100+ billion
| transistor 1 GHz FPGA for a similar price as something like an
| Intel i9, say $500 or less.
|
| Looks like about 75 transistors per gate, so I'm mainly
| interested in how many transistors it takes to make a 32 or 64
| bit ALU, and for RAM or DRAM. I'm envisioning an 8x8 array of
| RISC-V cores, each with perhaps 64 MB of memory for 16 GB total.
| That would compete with Apple's M1, but with no special
| heterogenous computing hardware, so we could get back to generic
| multicore desktop programming and not have to deal with
| proprietary GPU drivers and function coloring problems around CPU
| code vs shaders.
| aseipp wrote:
| A k-LUT SRAM-based FPGA where k=6 is something like 100x more
| inefficient in terms of raw transistor count than the
| equivalent ASIC gates when I last did some napkin math (though
| there's a statistical element in practice when considering
| k-LUTs vs fixed netlists.) But the SRAM requirements scale 2^k
| with the LUT size, so the highest you get in practice today is
| 6-LUTs and 80% of vendors do 4-LUT. And then you need all the
| transistors for the scan chain to configure each bit, actual
| block RAM, fixed function DSPs, etc. Clocking them to really
| high frequencies is also difficult. They're mostly overpriced
| because the market is small and the only competitors in town
| can rob you; bulk buys from having costs 1/50th the list-price,
| per-device, isn't unusual.
|
| But the big problem isn't really the hardware. You can go
| create and simulate a robust design in a number of HDLs, there
| are all kinds of tools to do it now, though they aren't as
| fancy as proprietary ones. It's doable. But it's having a good
| software stack that matters. You can blow a billion dollars on
| a chip and still lose because of the software. Nvidia figured
| this out 10 years ago and everybody else is still playing catch
| up.
|
| And it takes an insane amounts of software engineering to make
| a good compute stack. That's why Nvidia is still on top.
| Luckily there are some efforts to help minimize this e.g.
| PyTorch-MLIR for ML users, though more general compute stack
| needs, such as accelerated BLAS or graph analytics libraries or
| OpenMPI, are all still "on you" to deliver. But if you stick
| your head in the sand about this very important point, you're
| going to have a bad time and waste a lot of money.
| Sirened wrote:
| What sort of wiki are you envisioning here? There is some
| decent tooling and docs around generating SoCs [1] but, as the
| article mentions, the most difficult part is not creating a
| single RISCV core but rather creating a very high performance
| interconnect. This is still an open and rich research area, so
| you're best source of information is likely to just be google
| scholar.
|
| But, for what it's worth, there do seem to be some practical
| considerations why your idea of a hugely parallel computer
| would not meaningfully rival the M1 (or any other modern
| processor). The issue that everyone has struggled with for
| decades now is that lots of tasks are simply very difficult to
| parallelize. Hardware people would _love_ to be able to just
| give software N times more cores and make it go N times faster,
| but that 's not how it works. The most famous enunciation of
| this is Amdahl's Law [2]. So, for most programs people use
| today, 1024 tiny slow cores may very well be significantly
| worse than the eight fast, wide cores you can get on an M1.
|
| [1] https://chipyard.readthedocs.io/en/stable/Chipyard-
| Basics/in...
|
| [2] https://en.wikipedia.org/wiki/Amdahl's_law
| rjsw wrote:
| You could do a trial build of an in-order Rocket RISC-V core
| [1] to see how much space it takes up.
|
| [1] https://github.com/chipsalliance/rocket-chip
___________________________________________________________________
(page generated 2022-12-23 23:00 UTC)