5 ms·

Let's say I'm making an SoC and I need an always-on service processor. It's a waste of effort for me to make it myself, so I'll either license one or grab one o

Let's say I'm making an SoC and I need an always-on service processor. It's a waste of effort for me to make it myself, so I'll either license one or grab one off the internet, if I could trust it. In the past, people just threw a little bit of money to ARM and called it a day. But now, I could grab picorv32 or rocket for free off the internet. Both have been taped out in this capacity before, both speak standard bus interfaces, and the former has been fully(?) formally verified. Sure, it's not a resounding success story, but it helps me get my SoC to market sooner and at a lower cost (no need to even spend time negotiating with anybody).

cwzwarich 8y ago
> But now, I could grab picorv32 or rocket for free off the internet. Both have been taped out in this capacity before, both speak standard bus interfaces, and the former has been fully formally verified. What do you mean by "fully formally verified"? My understanding is that picorv32 has been verified by riscv-formal, and riscv-formal performs bounded model checking, which is not full formal verification unless you otherwise establish an upper bound on trace lengths that must be considered to find a bug.
- _chris_ 8y ago
  Apologies, I may be speaking out of my $(# on that. I'm aware Clifford has used it to demonstrate formal method techniques, but I don't know the full extend to it. Caveat Emptor to anyone who decided to rush out and add it to their SoC. ;)
SlowRobotAhead 8y ago
>Sure, it's not a resounding success story, but it helps me get my SoC to market sooner and at a lower cost (no need to even spend time negotiating with anybody). Ok, but you're then dumping what at least a million dollars into someone else's firmware that is unsupported if there is an issue? IDK. I can think of lots of cases where it might make sense for the hobbiest, or for softcores or for weird applications - but... There are engineers from STM with desks at ARM, and engineers from ARM with desks at STM. I just don't see STM saying "fuck it, let's just spool up some core we contributed to as a fully in house project". They already need to support their peripherals and production, maybe they are paying enough to ARM to make it worth it to add core code to that list, maybe not. ARM makes a ton of money, but they also assume all of the contractual obligations for issues and support. I'm not sure the entire industry would be using ARM if it made sense to spool up your own, even as open source. But again, IDK.
- _chris_ 8y ago
  I think you underestimate just how many hardware startups there are and how many of them are NOT going to license an ARM core for their service core.
- snom380 8y ago
  Part of what you get with ARM is certainly support, but a lot of it is also tooling, OS support and so on. There's a _lot_ of vendors outside the traditional big ones. And even the big ones like Samsung has used OpenRisc for service processors before.

cwzwarich 8y ago

> But now, I could grab picorv32 or rocket for free off the internet. Both have been taped out in this capacity before, both speak standard bus interfaces, and the former has been fully formally verified. What do you mean by "fully formally verified"? My understanding is that picorv32 has been verified by riscv-formal, and riscv-formal performs bounded model checking, which is not full formal verification unless you otherwise establish an upper bound on trace lengths that must be considered to find a bug.

_chris_ 8y ago
Apologies, I may be speaking out of my $(# on that. I'm aware Clifford has used it to demonstrate formal method techniques, but I don't know the full extend to it. Caveat Emptor to anyone who decided to rush out and add it to their SoC. ;)

SlowRobotAhead 8y ago

>Sure, it's not a resounding success story, but it helps me get my SoC to market sooner and at a lower cost (no need to even spend time negotiating with anybody). Ok, but you're then dumping what at least a million dollars into someone else's firmware that is unsupported if there is an issue? IDK. I can think of lots of cases where it might make sense for the hobbiest, or for softcores or for weird applications - but... There are engineers from STM with desks at ARM, and engineers from ARM with desks at STM. I just don't see STM saying "fuck it, let's just spool up some core we contributed to as a fully in house project". They already need to support their peripherals and production, maybe they are paying enough to ARM to make it worth it to add core code to that list, maybe not. ARM makes a ton of money, but they also assume all of the contractual obligations for issues and support. I'm not sure the entire industry would be using ARM if it made sense to spool up your own, even as open source. But again, IDK.

_chris_ 8y ago
I think you underestimate just how many hardware startups there are and how many of them are NOT going to license an ARM core for their service core.
snom380 8y ago
Part of what you get with ARM is certainly support, but a lot of it is also tooling, OS support and so on. There's a _lot_ of vendors outside the traditional big ones. And even the big ones like Samsung has used OpenRisc for service processors before.