Announcement

Collapse
No announcement yet.

MIPS Claims "Best-In-Class Performance" With New RISC-V eVocore CPUs

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • microcode
    replied
    Originally posted by PerformanceExpert View Post
    ...it is a highly competitive market already with many different suppliers and ISAs.
    That's why standardization is such a big deal. Having to get Tensilica tooling for one product iteration, then switch completely to ARM tooling, then maybe back a year later, is costly. This is why RISC-V is attractive to SoC makers like Espressif: upstream tooling is widely available, they no longer have to license some obscure nonsense, and they can maintain product compatibility a number of ways that were previously not possible.

    Originally posted by PerformanceExpert View Post
    it's hard to compete with basic 4-bit and 8-bit microcontrollers!
    It's really not; at this point packaging dominates the cost of 4- and 8-bit microcontrollers, the total cost of a 32-bit part is just not that different anymore (and is sometimes lower, depending on which 8-bit micro you're looking at). The selling point is maybe a bit greater in on-die microcontrollers in SoCs, but it's evidently not such a big selling point seeing as most on-die embedded processors share the address width of the application processor, and even if it were less costly, we're talking twice, maybe three times a small number. 8-bit micros still have legacy interest, but it's not because it's actually cheaper to put one on your board.

    Originally posted by PerformanceExpert View Post
    Btw One reason MIPS went down was due to trying to undercut Arm on licensing fees and royalties. They got some market share in microcontrollers, but it led to a vicious circle of less money invested into future cores, leading to fewer paying customers and even less money.
    Yes, and this owes in large part to centralization: because MIPS was basically the sole provider of MIPS designs in practice, they took on the costs of the race to the bottom, rather than externalizing them. RISC-V is maintained by a consortium, it doesn't have the kind of overhead that a whole company has, and they don't need to worry about making core designs because anyone can just get started without having to make the decision to license an ISA. The new company called MIPS that we are talking about today will probably find customers for these designs, they will at least break even if they find a customer every now and then; when they were managing the whole thing, they were struggling as you pointed out.

    Originally posted by PerformanceExpert View Post
    Having many RISC-V licensing companies will result in consolidation since so far they all seem to sell similar in-order microcontroller cores.
    The difference in this case is that the consolidation of RISC-V design shops will not result in a product lifecycle issue. When MIPS shrunk to acquisition size, it essentially brought the MIPS ISA and ecosystem down with it. When there's no fighting over the ISA IP, consolidations and de-mergers can happen freely and naturally without breaking ABIs, as the real prices of different categories of design and product are revealed through transactions. Issues associated with unavoidable consolidation are exacerbated by proprietary interfaces, and unavoidable consolidations happen all the time in the industry anyhow, with or without RISC-V.

    Espressif has a niche, highly integrated radio SoCs, and they aren't going anywhere. Esperanto has a niche: core designs at the edge of performance in a given power category, and they don't need to merge with SiFive to get the benefits of that, since they can market their cores directly to SiFive customers through the marketplace. SiFive will have a niche, being a first party core provider on their platform, but also if a category of core design is not being licensed they can just not bother resourcing that design org, it's not a huge deal.
    Last edited by microcode; 14 May 2022, 02:58 PM.

    Leave a comment:


  • PerformanceExpert
    replied
    Originally posted by microcode View Post
    I don't think so, at least, sophisticated people aren't overselling it; it just happens to be a huge deal to finally have this much momentum behind an open ISA that is very adaptable and quite well regarded.
    People keep overselling it. A single ISA for everything from the tiniest microcontroller to server class cores sounds like a nice idea if you don't have experience in ISA design, but it means a lot of compromises and fragmentation in reality.

    Every semiconductor consumer, that is to say every person who buys anything, should be cheering this on; it will drive down price on low-sophistication devices, dramatically increase the number of competing suppliers at every level, and generally improve the price-quality matrix for consumer and industrial electronics.
    It is a bigger deal than a lot of people give it credit for.
    That's exactly the kind of hype I meant. If you understand the industry you would know that it is a highly competitive market already with many different suppliers and ISAs. There are many dirt cheap microcontrollers. There is no evidence that adding yet another ISA will lead to smaller or cheaper microcontrollers - it's hard to compete with basic 4-bit and 8-bit microcontrollers!

    Btw One reason MIPS went down was due to trying to undercut Arm on licensing fees and royalties. They got some market share in microcontrollers, but it led to a vicious circle of less money invested into future cores, leading to fewer paying customers and even less money.

    Even if it is just three companies replicating ARM's core licensing business model, and that is way underselling it, that's a massive improvement from the status quo.
    How is it a massive improvement? MIPS was already licensing cores, others (ARC/Synopsys, Tensillica/Cadence etc) still exist. Having many RISC-V licensing companies will result in consolidation since so far they all seem to sell similar in-order microcontroller cores.
    Last edited by PerformanceExpert; 14 May 2022, 08:42 AM.

    Leave a comment:


  • tuxd3v
    replied
    Originally posted by microcode View Post
    Even if it is just three companies replicating ARM's core licensing business model, and that is way underselling it, that's a massive improvement from the status quo.
    I understand what you meant.

    But there are a lot more companies already with products..
    This are some that I know off, that have already products on the market..
    Sifive, StarFive, syntacore, cloudbear, Gigadevice, WCH, mikron, milandr, canaan, espressif, Nvidia(uses riscv in its graphics cards), Western Digital(has some controllers based in riscv),MIPS(Q4 2022), Imagination, Think Silicon( GPU ) and there are a lot of others more, some already with products, others in development faze, like STMicroelectronics..

    From this, replicating the business model of ARM, or close are Sifive,syntacore, cloudbear..maybe others that I don't recall now.

    Leave a comment:


  • microcode
    replied
    Originally posted by PerformanceExpert View Post
    The fact that the ISA is open is way overhyped, often by people who have no understanding about the difference between ISA and implementation.
    I don't think so, at least, sophisticated people aren't overselling it; it just happens to be a huge deal to finally have this much momentum behind an open ISA that is very adaptable and quite well regarded.
    Every semiconductor consumer, that is to say every person who buys anything, should be cheering this on; it will drive down price on low-sophistication devices, dramatically increase the number of competing suppliers at every level, and generally improve the price-quality matrix for consumer and industrial electronics.
    It is a bigger deal than a lot of people give it credit for.

    Even if it is just three companies replicating ARM's core licensing business model, and that is way underselling it, that's a massive improvement from the status quo.

    Leave a comment:


  • tuxd3v
    replied
    Riscv, as I see it its like a buffet..
    You design a core for a specific task, and almost for sure it will be smaller, because you include only what is really needed.
    For smartphones, tablets, laptops, desktops, workstations and servers Riscv can be ok.Because Riscv, in my opinion, was designed from the ground up, to work well for those places.
    I don't know about the MMU situation..

    The embedded space, it will depend.
    If you don't need low latency interrupts, there are already solutions.
    But if you need low latency interrupts, also called as hardware accelerated Interrupts( like arm, that do save/restore of the registers in hardware...the housekeeping of interrupts without burning cpu cycles, or with reduced core intervention ), you have a problem with Riscv.

    I understand that they doesn't wanted to create a Embedded ISA, but for a lot of devices it will be needed.
    Because one thing is using Riscv for academic purposes, and in that situation, it does indeed make sense that students learn how a interrupt works, and they need to perform all the steps in software.
    But for commercial use there are a lot of places that need fast interrupts, I also think they downplayed the interrupt controller part, and now they are trying to create solutions that don't brake compatibility, but they turn awkward..

    In Riscv ISA as a core, only the BIC( Basic Interrupt Controller ) is present, all the others are extensions( CLIC, PLIC, APLIC ).
    The thing is, BIC only allows for software interrupts, and timer interrupt, I don't know if it allow more.
    And each interrupt need to have a prologue and a epilogue( for housekeeping..they are not accelerated interrupts, there are no hardware stack, only software stack )

    On the other side, having various solutions as extensions, allow vendors to choose just what they want..
    But in my Opinion, I don't know if they will solve this problem without creating a Embedded ISA specifically to address low latency..

    Leave a comment:


  • PerformanceExpert
    replied
    Originally posted by microcode View Post
    Yes, who told you it wouldn't be this way?
    The fact that the ISA is open is way overhyped, often by people who have no understanding about the difference between ISA and implementation. The fact that it is extremely expensive to design and manufacture a CPU is typically omitted or downplayed. Similar for the fact that you need to charge license fees, royalties and protect your investment with patents. Companies like SiFive, MIPS pretty much emulate Arm's business model. So a lot of people got the wrong idea and believe RISC-V is something revolutionary.

    I believe we're getting past peak-hype as some realism is finally setting in.

    The interrupt controller and MMU are fully standardized, as is a base instruction set for linux-capable chips (RV64GC), this has been the case for years now. On the firmware side, UEFI is widely available. Not sure what you mean by fragmentation. I think it's likely that desktop class processors will have the V extension (ratified last year) in addition to G[MAFD]C, but it's the same sort of thing as SSE or AVX detection on x86, not a new problem.
    Others have already explained the fragmentation in interrupt controllers etc. As for the V extension, it has been talked up for many years now. It'll be 1-2 years before we'll see implementations, and even longer before it will be in common use and people can optimize software to use it.

    Leave a comment:


  • tuxd3v
    replied
    Originally posted by Developer12 View Post

    There are _multiple_ standards for the interrupt controller and MMU, and not everyone making linux run on their RISC-V chip implements the same version, or any at all. Same with "standard" extensions needed for linux.

    As an example, WD ported linux to the K210 without it supporting any MMU at all, with kernelspace and userspace both residing in the same physical address space with no protection at all. It's upstream.

    While it's true that (multiple) standards "do exist" for a lot of the stuff required, and more bits are being specified, until a consensus emerges that everyone follows then the fragmentation will continue.
    For what I understand you have BIC,CLIC,PLIC, and the last one that was ratified when they did last Riscv conference, so in total 4 types.
    Agree.. one just asks... what's going on here?

    One of the reasons why I didn't started already doing some micro-controller stuff with riscv, its exactly because of the mess of the Interrupts in Riscv..
    Depending on the microcontroller you may find some of the above, all, or almost none, and some closed spec interrupt controller from that company.
    Why companies implement their own version?I believe its because Interrupts are still a case where RIscv is "in Development"..

    To give you a concrete example..
    Just look to GD32VF103, yes it does some stuff that doesn't exist in Riscv standard, one of them is the interrupt controller that is different, and you will need a special toolchain for it
    However it also implements, I believe CLIC..but its basic.

    I was expecting something like ARM NVIC, but for Riscv.
    I don't know but some interrupt controllers, are very slow, they don't do the interrupt house keeping in hardware( like arm does ).
    Others you need to be inside a interrupt handler checking what source of interrupt launched the interrupt, puff,a lot of cycles burned for nothing..why not a Vector interrupt like arm has?!
    I am not a expert on it, but I read a lot before starting Riscv, and I found a lot of people complaining about this problem.So I went to Gigadevice GD32VF103 programming manual, and started to see that they implemented a proprietary interrupt controller, trying to be a vector interrupt controller like arm, but was a weird implementation.
    So I give up until everything is sorted out.

    Leave a comment:


  • Developer12
    replied
    Originally posted by microcode View Post

    Yes, who told you it wouldn't be this way?



    The interrupt controller and MMU are fully standardized, as is a base instruction set for linux-capable chips (RV64GC), this has been the case for years now. On the firmware side, UEFI is widely available. Not sure what you mean by fragmentation. I think it's likely that desktop class processors will have the V extension (ratified last year) in addition to G[MAFD]C, but it's the same sort of thing as SSE or AVX detection on x86, not a new problem.
    There are _multiple_ standards for the interrupt controller and MMU, and not everyone making linux run on their RISC-V chip implements the same version, or any at all. Same with "standard" extensions needed for linux.

    As an example, WD ported linux to the K210 without it supporting any MMU at all, with kernelspace and userspace both residing in the same physical address space with no protection at all. It's upstream.

    While it's true that (multiple) standards "do exist" for a lot of the stuff required, and more bits are being specified, until a consensus emerges that everyone follows then the fragmentation will continue.

    Leave a comment:


  • willmore
    replied
    Originally posted by microcode View Post

    Imagination (PowerVR guys) bought them.
    You missed a bit:
    Originally posted by Gonk View Post
    "MIPS Technologies was part of Wave Computing of Santa Clara, California, but Wave went bankrupt. Wave emerged from bankruptcy as just MIPS (now based in San Jose), and is wholly owned by Tallwood Venture Capital of Menlo Park."

    Leave a comment:


  • microcode
    replied
    Originally posted by Developer12 View Post
    Ah, another closed-source RISC-V chip.
    Yes, who told you it wouldn't be this way?

    Originally posted by Developer12 View Post
    Has RISC-V made any progress on their fragmentation problem?

    So long as nobody can agree on a basic set of extensions and system peripherals (on standard interrupt controller and MMU interface, for example) that should be available in *every* linux-capable chip, you're just going to continue to see dozens of vendors peddling their own mixed bag and long list of out-of-tree patches.
    The interrupt controller and MMU are fully standardized, as is a base instruction set for linux-capable chips (RV64GC), this has been the case for years now. On the firmware side, UEFI is widely available. Not sure what you mean by fragmentation. I think it's likely that desktop class processors will have the V extension (ratified last year) in addition to G[MAFD]C, but it's the same sort of thing as SSE or AVX detection on x86, not a new problem.
    Last edited by microcode; 12 May 2022, 10:46 AM.

    Leave a comment:

Working...
X