[HN Gopher] AMD MicroBlaze V Processor: A Flexible and Efficient...
___________________________________________________________________
AMD MicroBlaze V Processor: A Flexible and Efficient RISC-V
Processor
Author : stevefan1999
Score : 297 points
Date : 2023-11-04 02:01 UTC (20 hours ago)
(HTM) web link (www.xilinx.com)
(TXT) w3m dump (www.xilinx.com)
| dmitrygr wrote:
| I'm all for new soft cores. However, do we really need to pollute
| the name space? Microblaze is already a name of an _architecture_
| that somebody might want to Google.
|
| Just call it AMDcoreV or some such thing
| ynx wrote:
| ...as in the MicroBlaze architecture owned by AMD by way of its
| acquisition of Xilinx?
| tw04 wrote:
| Correct, microblaze is the name of an architecture AMD owns,
| and this is compatible with, per the article.
|
| > It allows developers to leverage the open-source RISC-V
| software ecosystem, is hardware compatible with the classic
| MicroBlaze processor
| mkj wrote:
| What does "hardware compatible" mean here though? It runs on
| the same FPGA hardware, but has unrelated CPU architecture?
| namibj wrote:
| I assume it means it's essentially pin-compatible, like,
| say, a PCIe GPU upgrade would be. Still needs new software.
| But has the same HDMI and PCIe and the same low-level
| protocols.
| AlotOfReading wrote:
| Soft cores don't have their own pins. I think "hardware
| compatible" means that it runs on the same FPGAs as
| microblaze arm with the same toolchain product suite.
| addaon wrote:
| "Pins", in this case, means the logical ports used to
| interface one module within an FPGA to another. Think
| AMBA bus, clock(s), interrupt lines, etc. An FPGA SOC
| design that currently throws a bunch of different IPs
| (modules) together to do... something... could do the
| same with this core thrown in to replace a (classic)
| Microblaze with only a resynthesis on the hardware side,
| and a recompile on the software side.
| brucehoult wrote:
| It has the same interface to the rest of the design -- the
| buses and control signals etc. You can drop the new RISC-V
| soft core straight into an existing design using Microblaze
| and change only the program code.
| hajile wrote:
| CPU is just one part. You're probably adding your own
| coprocessor and whatever other IO to the FPGA. If the CPU
| uses a different interconnect/protocol design, you'll have
| to redesign and debug your entire interface which will be
| very expensive.
|
| Meanwhile, microblaze is a proprietary architecture. AMD
| puts a few hundred thousand dollars of dev time into it
| here or there, but most software stacks will have tons of
| stuff not at all designed for that ISA. If you can switch
| to RISC-V, you get access to an ecosystem where tons of
| companies are all pouring multi-millions in every year.
|
| EDIT: a great example is that microBlaze was added to LLVM
| in 2010, but then removed in 2013 because nobody was free
| to maintain it.
|
| Now AMD comes along and says you can swap out the CPU ISA
| to RISC-V without needing any hardware redesigns and then
| with a simple recompile, you can start using that massive
| ecosystem instead of spending man-years writing your own
| stuff which saves your company lots of money.
| FastFT wrote:
| Hardware compatible doesn't mean very much in this case. It's
| a different ISA so you'll need a different tool chain and
| recompilation (possibly rewrite given that assembly is very
| common in deeply embedded processors). It'll also have
| different LUT usage, etc.
| tails4e wrote:
| It means it's designed as a direct drop in replacent for a
| traditional microblaze ISA code..sure software must be
| recompiled, but hardware interfaces match what was there
| before for peripheral access, debug, instruction offload,
| etc. This makes the transition to using RISC-v much more
| seamless if you were already using microblaze
| pclmulqdq wrote:
| This is the new Xilinx Microblaze. They went from an AVR-like
| instruction set to RV32.
| 8K832d7tNmiQ wrote:
| or simplify it as AMD V core to make it easier to say.
| userbinator wrote:
| Not to be confused with AMD-V, the existing virtualisation
| extension (subtly different from and incompatible with
| Intel's VT-x) for its x86 CPUs.
| snvzz wrote:
| "AMD V core" would only work (ignoring AMD-V virtualization
| assisting x86 extension) if AMD only ever planned to make one
| RISC-V core.
|
| I am looking forward to Zen-V.
| snvzz wrote:
| It is the same interface facing your HDL. Whereas on the
| software side, it is RISC-V, the ISA that's rapidly growing the
| strongest ecosystem.
|
| Just a recompile away, except this time, you don't have to deal
| with poor, proprietary, bespoke, low quality tooling, but you
| can instead use reputable industry standard tools like gcc,
| binutils, llvm.
| opello wrote:
| I'm pretty sure the "bespoke" tooling was just older versions
| of those industry standard tools because of poor upstreaming
| of architecture support. And there are probably many, very
| reasonable, justifications for that having been the case...
| the least of which is shipping toolchains with their own
| design tools.
|
| RISC-V doesn't seem like the "strongest" ISA ecosystem,
| unless you mean among soft core CPUs?
| fleventynine wrote:
| Among 32-bit microcontroller-class architectures, modern
| toolchain support for rv32imc is second only to armv7m
| IMHO. Nobody wants to maintain support for any other
| vendor-specific ISAs.
| brucehoult wrote:
| Strongest of any ISA after ARM and x86 at this stage, I
| should think.
|
| I can't really see AMD/Xilinx or Intel/Altera offering a
| free 486SX soft core, even though they legally could. It
| would I expect use a lot more LUTs, and be slower.
|
| Licensing Cortex-M1 doesn't seem likely either.
| snvzz wrote:
| >unless you mean among soft core CPUs
|
| Note that RISC-V hard cores in FPGAs are already a reality,
| including Microsemi PolarFire as well as GOWIN GW2N.
|
| Not long from now, I expect every FPGA vendor to switch
| over. The ones that already offer soft cores won't take
| long.
|
| >RISC-V doesn't seem like the "strongest" ISA ecosystem
|
| RISC-V is rapidly building the strongest ecosystem.
|
| It already is the strongest besides x86 and ARM, and the
| position of these two isn't, by any means, secure.
| opello wrote:
| At least it's "MicroBlaze V" which is better than no affix.
| jadbox wrote:
| Can anyone comment on how notable this announcement is for RISCV?
| BirAdam wrote:
| It's a microcontroller that can also function as a real-time
| CPU. RISC-V is already quite popular in that market.
| OhMeadhbh wrote:
| For some definitions of the word "popular". Definitely
| getting more popular than Tensilica, but still hasn't quite
| reached 8051 levels of popularity.
| BirAdam wrote:
| Every Western Digital HD, the Titan M2 in Pixel 6 and 7,
| newly manufactured Seagate HDs, and more... I'd say that
| counts as popular. Is it as popular as ARM? Technically,
| nothing comes remotely close to ARM in chips shipped. If
| that's your measure, X86 isn't popular.
| brucehoult wrote:
| All the other major FPGA manufacturers already started offering
| an official supported RISC-V core as an alternative to their
| proprietary ISA cores a few years ago. Of course people also
| use 3rd party cores off github, but supported and integrated
| into the IDE and other tools means something to a lot of
| customers.
|
| MicroSemi have been offering RISC-V soft cores since 2017 and
| hard cores (PolarFire SoC, in e.g. the new BeagleBoard Fire,
| Icicle) since late 2020.
|
| Lattice announced their first official RISC-V soft core in I
| think June 2020 (collab with SiFive announced December 2019),
| and improved versions e.g. an 800 LUT core in mid 2021.
|
| Intel introduced Nios V in October 2021.
| monocasa wrote:
| Microblaze was in the gate count that is being actively
| decimated by RISC-V. Just like tensilica, arc, etc. have lost
| most their value add in the space. Having personally ported a
| kernel to microblaze, it's basically a halfway point between
| MIPS and SH4, classic pipelined RISC in the ~20k gate range.
|
| Probably the most interesting part of this announcement is that
| they're so in that they're straightup redefining their
| trademarked term "Microblaze" rather than making a new term and
| continuing to support classic Microblaze updates.
| kramerger wrote:
| Microblaze is designed for optimal mapping to Xilinx FPGA
| cells, it doesn't make sense to compare ASIC gate count.
|
| Also, their secret sauce is the ecosystem and tooling around
| it. If you don't use that, you are not their target and are
| free to use any open source riscv core you please.
| willis936 wrote:
| Xilinx is a pretty big FPGA manufacturer and Microblaze offers
| a nice selection of fault tolerance features, including TMR.
| TMR on RISC-V is not novel here, but it does mean the large
| number of projects already using Microblaze, and new ones that
| want to use Microblaze, can now use RISC-V.
| OhMeadhbh wrote:
| Back in the day, SiFive had a RV32 core that could fit in an
| Artix-7 that was pretty bare-bones. IO was random, it couldn't
| use the onboard DRAM, etc. It would be cool to see an
| officially supported RV32 softcore on an Artix-7. I had
| reasonably good experiences with the MicroBlaze back in the
| day, but would never think of using it for anything other than
| testing or education 'cause it was (very) closed source. And
| while I'm not the worlds biggest RISC-V cheerleader, this is
| the kind of thing that it's good at: "here's a tool that uses
| an ISA you may have already invested in. also, we're not going
| to try to lock you in to THAT side of the toolchain." I'm
| somewhat okay with AMD/Xilinx locking you in to whatever is
| underneath the ISA since you're probably going to have to pay
| for hardware somehow: either buying the FPGA or buying a
| catalog part (if they ever emerge.)
|
| Also... thx for pointing out AMD bought Xilinx. I had
| completely forgotten about it and was mildly surprised to see
| AMD adopting MicroBlaze.
| devmunchies wrote:
| Are there any dev kits to tinker with this? How does one get
| started?
| smallstepforman wrote:
| Read the linked article? https://docs.xilinx.com/v/u/en-
| US/microblaze-quick-start-gui.... It's an Xilix FPGA design, so
| a Xilix dev board is the where to start ...
| CodeArtisan wrote:
| You will find the entry-level boards here. (ranging from $150
| to ~$4000)
|
| https://www.xilinx.com/products/boards-and-kits/cost-optimiz...
| snvzz wrote:
| I'd go with any cheap[0] xilinx one that supports microblaze
| soft CPUs.
|
| If all you need is a RISC-V softcore, then there's plenty of
| options outside of Xilinx ecosystem. I like anything
| yosys/nextpnr supports well.
|
| 0. https://www.joelw.id.au/FPGA/CheapFPGADevelopmentBoards
| phendrenad2 wrote:
| This is confusing unless you remember that AMD bought Xilinx
| recently, so random new Xilinx products will likely get the AMD
| name applied on them.
| kramerger wrote:
| Random? Xilinx MicroBlaze is 20+ years old. It was one of the
| first "real" softcores developed for FPGA.
|
| The Intel counterpart would be Altera NIOS II.
| SomeHacker44 wrote:
| NIOS V in this particular case...
| GeorgeTirebiter wrote:
| indeed https://www.intel.com/content/www/us/en/products/det
| ails/fpg...
| sylware wrote:
| This is the first step. Those are good omens.
|
| That said, instead of a 32bits core, I would have prefered a
| 64bits core, because once I write 64bits RISC-V assembly code
| paths, I could really re-use them on desktop/server/embedded.
| RetroTechie wrote:
| > This is the first step.
|
| No, one of many steps already taken.
|
| > I would have prefered a 64bits core
|
| Sounds like you're not in the target market.
|
| > because once I write 64bits RISC-V assembly code paths, I
| could really re-use them on desktop/server/embedded.
|
| Not really. There's not much overlap between "desktop/server"
| (a 64 bit only affair) and "embedded" ( _mostly_ 32 bit cores).
| Not to mention that apart from 32 <->64 bit, the programming
| environment tends to be very different between these: system
| complexity, boot procedure, how to interact with outside world
| - just to name a few.
|
| In short: pick target device(s), code for that. Want code to
| move easily between different types of devices? Then code in
| something _other_ than assembly.
| einpoklum wrote:
| Agree generally, but not with this statement:
|
| > There's not much overlap between "desktop/server" (a 64 bit
| only affair) and "embedded" (mostly 32 bit cores).
|
| Most code compiles nicely targeting either 32-bit or 64-bit
| platforms. Certainly, there's quite a lot of code that's
| architecture-specific, and some code that's useful in general
| in embedded environments and less in full-fledged
| PCs/servers, but - the symmetric difference not being empty
| doesn't imply the overlap is empty.
| braho wrote:
| Note that they were talking about _assembly_ code paths and
| parent explicitly mentioned using anything else then
| assembly would give you more portability.
| brucehoult wrote:
| It's easy to write RISC-V assembly language that works on
| both 32 bit and 64 bit, using a handful of simple macros.
| sylware wrote:
| This is a first step: as far as I know its an explicit first
| for AMD (they may have had private RISC-V cores though).
|
| There is so much code actually shared, or with very little
| variations, that it is a big win for code re-use to stick to
| 64bits, even for "embedded".
| RetroTechie wrote:
| > There is so much code actually shared, or with very
| little variations, that it is a big win for code re-use to
| stick to 64bits, even for "embedded".
|
| "Embedded" is a broad concept. Sure there's applications
| where the size/cost penalty of a 64 bit core is
| insignificant. Or you want it anyway to use software
| designed for it (like common Linux distributions).
|
| But there's also a loooottt of applications where you
| really want the simplest, lowest cost, lowest power cores
| available: solar powered mesh sensor networks, RFID tags,
| tiny controllers in eg. an USB peripheral, AA powered
| childrens toys, that clock in your microwave, etc, etc,
| etc. Often referred to as " _deeply_ embedded ".
|
| For such uses, 32 bit cores like ARM Cortex-M series or
| RV32I (or even -E) _rule_. To the point that even ancient 8
| /16 bit architectures like 8051 are still used.
|
| It would be dumb to put a 64b core there just to 're-use
| code paths'. C compilers are a thing, and assembly
| programmers know how to handle different ISAs.
| sylware wrote:
| This is exactly what I do not want to do: use a C
| compiler. And even though 32bits RISC-V assembly is very
| close to 64bits RISC-V assembly, I don't want to rely too
| much on an assembler macro pre-processor to do the
| switch.
|
| And yes "embedded" is nowdays quite "broad". Of course,
| for the "very" "embedded" even a 32bits RISC-V core is
| overkill, a broadly available 8bits processor will be
| enough if you really are going for the bucks, which I am
| not going for.
|
| In my world, I would have 2 targets, a mini domestic
| server (email, maybe a few small web servers, more?). A
| linux based OS would be the start, but I guess it would
| end up more like a custom patchwork of code paths from
| various projects than vanilla "linux". There are already
| many 64bits RISC-V SOC with existing boards for that.
| Then a mini-board with a SOC with at its center a 64bits
| RISC-V MCU for a DYO custom keyboard, which would require
| a USB device hardware block, flash memory, timer, a lot
| of GPIOs, etc. There are already some options here too,
| but a tad too overkill (often with "AI").
|
| Ofc, if I could get a RISC-V powerful workstation on
| which I could play AAA 3D games...
| gautamcgoel wrote:
| Is the core itself open source?
| adrian_b wrote:
| I doubt that, but AMD said that it is free to use in any AMD
| (Xilinx) FPGA.
|
| Had it required to pay a fee, there would have been no interest
| in this announce, because there are free alternatives.
|
| It can be assumed that this core is well optimized to use
| efficiently the resources of a Xilinx FPGA, which is likely to
| be its advantage over alternatives.
| londons_explore wrote:
| While it may not have an open source license, the source code
| for previous microblaze cores is part of the development kit,
| lightly obfusticated (but not even removing source code
| comments!)
| huggingmouth wrote:
| Does it have a psp or a me equivalent? I'm sick of shady blackbox
| cpus with insecure unpatchable mallard.
| bfrog wrote:
| would love to get like a soft core overview of all these riscv
| cores. Like are they open source, what sort of coremark score do
| they get, how big are they, etc
|
| neorv, serv, vexrisc, nios v, microblaze v, etc
| gsmecher wrote:
| According to a Reddit comment [1], this is the same MicroBlaze
| RTL with a RISC-V instruction decoder in front of it. This seems
| crazy from a let's-make-the-best-RISCV-core perspective, but
| that's never been Xilinx/AMD's goal.
|
| MicroBlaze has always been a great example of a boring in-order
| RISC CPU in a boring niche. For an FPGA vendor, soft cores are
| loss leaders: they sell silicon but don't make money on their
| own. They are also boring technology: they are "integration
| glue", and don't belong in the portion of the FPGA that drives
| performance. "Good enough" is good enough.
|
| If AMD really is reusing MicroBlaze RTL, then they're able to
| keep their existing firmware (core, FPU, debug, peripherals, etc)
| and software (HAL, compiler, drivers). These are all highly
| desirable from the perspective of the vendor, and any users
| looking for a painless transition to the new MicroBlaze core.
|
| 1:
| https://old.reddit.com/r/FPGA/comments/17mdcyt/microblaze_go...
| SilverBirch wrote:
| > For an FPGA vendor, soft cores are loss leaders: they sell
| silicon but don't make money on their own.
|
| This is dead right, the enabling technologies like this don't
| make money in their own right so they aren't considered
| valuable in hardware companies. It's why the billionaire CEOs
| of Xilinx and Altera shake their heads ruefully when they hear
| Jenson Huang continue to throw money away on nvidias software
| stack. One day he'll learn where the real value is.
| GeorgeTirebiter wrote:
| I sense just a bit of snark here ;-) Jenson Huang is clearly
| a visionary genius regarding GPU compute. I thought software
| ate the world?
| gsmecher wrote:
| > This is dead right, the enabling technologies like
|
| You fundamentally misunderstand. Soft core CPUs aren't
| enabling technologies and haven't been for decades. They are
| plumbing, like FIFO or SERDESes. You can't sell an FPGA into
| most markets without them.
| brucehoult wrote:
| That Redditor has -5 karma. Also that idea makes pretty much
| zero sense when it's a matter of a couple of days to implement
| a simple RISC-V core from scratch.
|
| I would not rely on that information.
|
| It does, however, have the same external interface as
| Microblaze and hardware wise is a drop in replacement in
| existing designs.
| GeorgeTirebiter wrote:
| I wonder what the use cases of MicroBlaze V are vis a vi, say,
| SERV https://serv.readthedocs.io/en/latest/servant.html
|
| That is, the only advantage MicroBlaze V gives you, besides
| blessing from the chip manufacturer, is speed. Aren't FPGA CPUs
| usually used to do tasks that aren't especially time-sensitive? I
| mean, that's what the FPGA fabric is for, to get high-speed,
| time-sensitive tasks done (in conjunction with the on-chip I/O
| interfaces).
| IronWolve wrote:
| Think new processors need to have 264/265 support so it can be
| used for many popular different applications, thus making them
| more popular. Trying to use a pi as a desktop replacement kinda
| sucks if you watch youtube or want to encode. A nice bonus would
| be some sort of AI acceleration too.
| snvzz wrote:
| These are softcores for FPGAs.
|
| Xilinx definitely has RTL for video codecs available for
| licensing, should you need those in your design.
___________________________________________________________________
(page generated 2023-11-04 23:01 UTC)