Hacker News Reader

Comment by ilyt | Hacker News Reader

> there are an awful lot of control tasks where one frame of doom every four seconds is much more performance than you actually need, like kindgren's examples in this talk: ddr memory initialization, logging, slow sensor data aggregation, and control planes; i'd add pid control, motor control waveform generation, and guitar pedals and other audio dsp applications (maybe using the serv core to orchestrate the activities of a larger dsp core, similar to how the s1 mp3 used a z80)

You can get proper 32 bit core for less than $1 these days, I can't see it competing. It has a niche, saving gates on FPGA, but that's about it

It being awfully slow also means it will be awful on power usage.

View on HN

You can get 32 bit MCUs for much less (~20ct). But many sensors, USB Hubs, specialized chips have some kind of small processor inside (which is often an 8051 right now) where this could be a good replacement, being low-gate-count, having good tools and a very low licensing cost (0$).

> You can get proper 32 bit core for less than $1 these days, I can't see it competing. It has a niche, saving gates on FPGA, but that's about it

Competing for what? Having a super small subcent CPU is an interesting niche (in ASICs). Having a well documented, really small CPU for FPGAs and a ecosystem is great for hobbyist and academia who need to string something together without tripping themselves. Even it serves as an educational example of a RISC-V CPU SERV is competing pretty well.

> It being awfully slow also means it will be awful on power usage.

On the contrary; for every RISCV32 instruction you'd expect the same energy requirement as in a bit parallel implementation. If you take 32x longer by processing 1 bit at a time, your power (energy per time unit) could be as much as 32x lower.

you probably know more, but my ignorant guess is that you need about half as many gates, but about 20× as many cycles (because things that would stall for an entire instruction time in a bit-parallel implementation only stall for a single cycle), it might consume about 10× as much energy?

but generally the kinds of places you'd want to use something like this, the cpu won't be even 1% of the power draw

i agree that it doesn't make sense to fabricate serv as a discrete chip, but i think of fabricating cpus as discrete chips as being the small niche, not embedding cpus inside fpgas or asics

Not only that, but you could replace a lot of fixed logic in that FPGA with s very small programmable thing. "Fast" only matters if it is on the critical path.

Reply on news.ycombinator.com