8 ms·

AMD MicroBlaze V Processor: A Flexible and Efficient RISC-V Processor

337 points by stevefan1999 3y ago

sylware 3y ago
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 3y ago
  > 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 3y ago
    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 3y ago
      Note that they were talking about _assembly_ code paths and parent explicitly mentioned using anything else then assembly would give you more portability.
      - brucehoult 3y ago
        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 3y ago
        This is what I told a commenter. But I don't even want to deal with those macros, just a nearly zero straight copy/paste. The preprocessor scares me, because once some devs starts to use it, many will want to push to max its usage everywhere and in the end, your code path is actually tied to the preprocessor, and sometimes with actually a whole new assembly language defined with the preprocessor, and if it is complex, the "exit cost" from it will sky rocket. For instance fasmg has an extremely powerful macro preprocessor, because this preprocessor is actually what's used to write assemblers. Due to the tendency of devs to maximize the usage of their SDK tools, some code paths actually end up with little assembly and a lot of macros! Then you must embrace that new language as a whole, like the opacity of the "object oriented model" of some big c++ projects BEFORE actually being able to do anything real for this very project. Personnally, I use a "normal" C preprocessor to define a minimal layer for a intel syntax assembler, which allows me to assemble with fasmg, gas and nasm/yasm. And I am very careful at assembling all the time with all assemblers. I do the same with C using cproc/qbe, tinycc, gcc, and I plan to add simple-cc/qbe. I actually do compile up to 1.1 times... the 0.1 accounting for cproc/qbe + tinycc and gcc get the rest.
  - sylware 3y ago
    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 3y ago
      > 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 3y ago
        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 3y ago
Is the core itself open source?
- adrian_b 3y ago
  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 3y ago
  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 3y ago
Does it have a psp or a me equivalent? I'm sick of shady blackbox cpus with insecure unpatchable mallard.
bfrog 3y ago
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 3y ago
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_goes_riscv/k7md4gv/ https://old.reddit.com/r/FPGA/comments/17mdcyt/microblaze_go...
- deleted 3y ago
  [deleted]
- deleted 3y ago
  [deleted]
- SilverBirch 3y ago
  > 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 3y ago
    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 3y ago
GeorgeTirebiter 3y ago
I wonder what the use cases of MicroBlaze V are vis a vi, say, SERV https://serv.readthedocs.io/en/latest/servant.html 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).
- crote 3y ago
  Tooling and support. You don't really want to mess around with a RISC-V softcore, you just want it to work and interface with the stuff you actually care about already. MicroBlaze allows you to literally construct your own softcore via drag-and-drop, selecting from a wide variety of configuration options and peripherals. It includes SDKs for your custom applications, and debugging tools to figure out what's going wrong. I would not be surprised if development using SERV would take several orders of magnitude longer, solely due to immature tooling.
IronWolve 3y ago
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 3y ago
  These are softcores for FPGAs. Xilinx definitely has RTL for video codecs available for licensing, should you need those in your design.
- mips_r4300i 3y ago
  Softcores on FPGAs tend to be used for housekeeping and babysitting silicon IP blocks. They never handle any actual data processing, because doing so in the fabric is orders of magnitude faster. The fastest softcore cpu at maybe 400mhz on a thousand-dollar FPGA is hardly faster than the slowest risc-V silicon.
dmitrygr 3y ago
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 3y ago
  ...as in the MicroBlaze architecture owned by AMD by way of its acquisition of Xilinx?
- tw04 3y ago
  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 3y ago
    What does "hardware compatible" mean here though? It runs on the same FPGA hardware, but has unrelated CPU architecture?
    - namibj 3y ago
      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 3y ago
        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 3y ago
        "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.
jadbox 3y ago
Can anyone comment on how notable this announcement is for RISCV?
- monocasa 3y ago
  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 3y ago
    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 3y ago
  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 3y ago
  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 3y ago
Are there any dev kits to tinker with this? How does one get started?
- snvzz 3y ago
  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 https://www.joelw.id.au/FPGA/CheapFPGADevelopmentBoards
- smallstepforman 3y ago
  Read the linked article? https://docs.xilinx.com/v/u/en-US/microblaze-quick-start-guide-with-vitis 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 3y ago
  You will find the entry-level boards here. (ranging from $150 to ~$4000) https://www.xilinx.com/products/boards-and-kits/cost-optimized-design.html https://www.xilinx.com/products/boards-and-kits/cost-optimiz...
phendrenad2 3y ago
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 3y ago
  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 3y ago
    NIOS V in this particular case...
    - GeorgeTirebiter 3y ago
      indeed https://www.intel.com/content/www/us/en/products/details/fpga/nios-processor/v.html https://www.intel.com/content/www/us/en/products/details/fpg...

337 points by stevefan1999 3y ago

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 3y ago
> 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 3y ago
  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 3y ago
    Note that they were talking about _assembly_ code paths and parent explicitly mentioned using anything else then assembly would give you more portability.
    - brucehoult 3y ago
      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 3y ago
        This is what I told a commenter. But I don't even want to deal with those macros, just a nearly zero straight copy/paste. The preprocessor scares me, because once some devs starts to use it, many will want to push to max its usage everywhere and in the end, your code path is actually tied to the preprocessor, and sometimes with actually a whole new assembly language defined with the preprocessor, and if it is complex, the "exit cost" from it will sky rocket. For instance fasmg has an extremely powerful macro preprocessor, because this preprocessor is actually what's used to write assemblers. Due to the tendency of devs to maximize the usage of their SDK tools, some code paths actually end up with little assembly and a lot of macros! Then you must embrace that new language as a whole, like the opacity of the "object oriented model" of some big c++ projects BEFORE actually being able to do anything real for this very project. Personnally, I use a "normal" C preprocessor to define a minimal layer for a intel syntax assembler, which allows me to assemble with fasmg, gas and nasm/yasm. And I am very careful at assembling all the time with all assemblers. I do the same with C using cproc/qbe, tinycc, gcc, and I plan to add simple-cc/qbe. I actually do compile up to 1.1 times... the 0.1 accounting for cproc/qbe + tinycc and gcc get the rest.
- sylware 3y ago
  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 3y ago
    > 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 3y ago
      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 3y ago

Is the core itself open source?

adrian_b 3y ago
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 3y ago
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 3y ago

Does it have a psp or a me equivalent? I'm sick of shady blackbox cpus with insecure unpatchable mallard.

bfrog 3y ago

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 3y ago

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_goes_riscv/k7md4gv/ https://old.reddit.com/r/FPGA/comments/17mdcyt/microblaze_go...

deleted 3y ago
[deleted]
deleted 3y ago
[deleted]
SilverBirch 3y ago
> 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 3y ago
  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 3y ago

GeorgeTirebiter 3y ago

I wonder what the use cases of MicroBlaze V are vis a vi, say, SERV https://serv.readthedocs.io/en/latest/servant.html 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).

crote 3y ago
Tooling and support. You don't really want to mess around with a RISC-V softcore, you just want it to work and interface with the stuff you actually care about already. MicroBlaze allows you to literally construct your own softcore via drag-and-drop, selecting from a wide variety of configuration options and peripherals. It includes SDKs for your custom applications, and debugging tools to figure out what's going wrong. I would not be surprised if development using SERV would take several orders of magnitude longer, solely due to immature tooling.

IronWolve 3y ago

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 3y ago
These are softcores for FPGAs. Xilinx definitely has RTL for video codecs available for licensing, should you need those in your design.
mips_r4300i 3y ago
Softcores on FPGAs tend to be used for housekeeping and babysitting silicon IP blocks. They never handle any actual data processing, because doing so in the fabric is orders of magnitude faster. The fastest softcore cpu at maybe 400mhz on a thousand-dollar FPGA is hardly faster than the slowest risc-V silicon.

dmitrygr 3y ago

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 3y ago
...as in the MicroBlaze architecture owned by AMD by way of its acquisition of Xilinx?
tw04 3y ago
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 3y ago
  What does "hardware compatible" mean here though? It runs on the same FPGA hardware, but has unrelated CPU architecture?
  - namibj 3y ago
    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 3y ago
      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 3y ago
        "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.

jadbox 3y ago

Can anyone comment on how notable this announcement is for RISCV?

monocasa 3y ago
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 3y ago
  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 3y ago
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 3y ago
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 3y ago

Are there any dev kits to tinker with this? How does one get started?

snvzz 3y ago
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 https://www.joelw.id.au/FPGA/CheapFPGADevelopmentBoards
smallstepforman 3y ago
Read the linked article? https://docs.xilinx.com/v/u/en-US/microblaze-quick-start-guide-with-vitis 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 3y ago
You will find the entry-level boards here. (ranging from $150 to ~$4000) https://www.xilinx.com/products/boards-and-kits/cost-optimized-design.html https://www.xilinx.com/products/boards-and-kits/cost-optimiz...

phendrenad2 3y ago

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 3y ago
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 3y ago
  NIOS V in this particular case...
  - GeorgeTirebiter 3y ago
    indeed https://www.intel.com/content/www/us/en/products/details/fpga/nios-processor/v.html https://www.intel.com/content/www/us/en/products/details/fpg...