6 ms·

SERV: 32-bit is the New 8-bit [video]

49 points by JoachimS 4y ago

kragen 4y ago
bit-serial cpus were common in the 01950s and still sold up to the 01970s; the lgp-30, the pdp-8/s, and the rca 1802 were three historically significant examples. the bit-serial approach cuts your hardware complexity by about half while cutting your performance by, typically, about a factor of 20. for a couple of decades, computers that weren't bit-serial were described as 'parallel' even if they only ran one instruction at a time (you can find this in early intel literature) probably 32 bits is wider than optimal for this kind of thing but not having to write your own c compiler and assembler toolchain is worth a lot, especially if, as in serv, your cpu doesn't try to trap on illegal instructions even if you're writing asm, risc-v asm requires a lot less bending over backwards than, say, 8051 or 6502 or pic or even avr, and you don't have to worry about overflow much. it's not quite as pseudocody as i386 assembly tho 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) wrt the question about educational applications, femtorv32 is probably an easier implementation of risc-v to understand; it's a lot less verilog and a lot more straightforward — ⁂ — for videos like this that are mostly slides and somebody talking, if you're interested in the verbal information and not the pretty face, i recommend yt-dlp --write-auto-sub --sub-lang en,es -f '[height<800]' https://www.youtube.com/watch?v=GSHasXHvZaQ (or possibly even just downloading the .vtt files without the video at all; it is unfortunate that youtube doesn't have an 0.5 fps 640×480 option for things like this) and then devtt.py < SERV：\ 32-bit\ is\ the\ New\ 8-bit\ -\ Olof\ Kindgren\,\ Qamcom\ \[GSHasXHvZaQ\].en.vtt | less where devtt.py is http://canonical.org/~kragen/sw/dev3/devtt.py http://canonical.org/~kragen/sw/dev3/devtt.py or equivalent (i can't have been the first person to want this, and probably someone has written a better version) the transcript is only 2130 words and so reading it only takes about 6 minutes, while the video is 21 minutes the transcript has a lot of errors but is adequate
- ilyt 4y ago
  > 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.
  - tromp 4y ago
    > 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.
    - kragen 4y ago
      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
  - danhor 4y ago
    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$).
  - kragen 4y ago
    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
pulse7 4y ago
How fast is it?
- vintermann 4y ago
  Fast enough to run doom at 1/4 fps, according to the video.
vintermann 4y ago
So he's talking about making 2 and 4 bit versions of this. I take it that means making it not-quite bit serial, but making it take 2 or 4 bits at a time? It would still have a 32-bit RISC V instruction set, right?
- tromp 4y ago
  Correct; a 2 bit version would double the width of the ALU and all data paths. And preserve the instruction set.
vardump 4y ago
Z80 was a bit... err 4 bit a like this. Used in for example Sinclair Spectrum, MSX, CP/M, Gameboy (although modified), TI-8x calculators, etc. had an ALU that computed 8 bit operations in two 4 bit slices. Edit: and now that I think about it, Motorola 68000 was also like this. Internally 16-bit ALU, but operated on 32 bit registers. 32-bit operations were done in two phases, just like on Z80.
- klelatti 4y ago
  More recently doesn't the AMD AVX 512 implementation do this too? [1] There is very little truly new! [1] https://www.phoronix.com/review/amd-zen4-avx512 https://www.phoronix.com/review/amd-zen4-avx512
- kjs3 4y ago
  The IBM 360/30 (lowest end of the 360 mainframe line other than the not-quite-compatible 360/20) used an 8-bit ALU to implement a 32-bit ISA in microcode.
rasz 4y ago
Academics, doing useless stuff just to publish. This takes more space than 6502 or Z80 while also being slower.
- vardump 4y ago
  µC performance doesn't always matter. Sometimes you need something that takes very little FPGA or ASIC space. This leaves more space for the actually important stuff. When performance does matter, you just use something speedier. More choice is good.
  - rasz 4y ago
    This is bigger than 8bit cores.
    - vardump 4y ago
      SERV seems to be very comparable to a 6502 in size in terms of ASIC gates required. On an FPGA, SERV's implementation seems to be a times smaller.
      - rasz 4y ago
        if you ignore register file
        vardump 4y ago
        True, unless you use a reduced one.
- JoachimS 4y ago
  Olof Kindgren is not in academia. He is an embedded consultant working for Qamcom, a consultancy in Sweden, USA etc. https://www.qamcom.com https://www.qamcom.com And as he points out in the presentation, SERV is used in several (and growing) real world systems as a flexible control plane in ASICs, FPGAs etc.

49 points by JoachimS 4y ago

bit-serial cpus were common in the 01950s and still sold up to the 01970s; the lgp-30, the pdp-8/s, and the rca 1802 were three historically significant examples. the bit-serial approach cuts your hardware complexity by about half while cutting your performance by, typically, about a factor of 20. for a couple of decades, computers that weren't bit-serial were described as 'parallel' even if they only ran one instruction at a time (you can find this in early intel literature) probably 32 bits is wider than optimal for this kind of thing but not having to write your own c compiler and assembler toolchain is worth a lot, especially if, as in serv, your cpu doesn't try to trap on illegal instructions even if you're writing asm, risc-v asm requires a lot less bending over backwards than, say, 8051 or 6502 or pic or even avr, and you don't have to worry about overflow much. it's not quite as pseudocody as i386 assembly tho 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) wrt the question about educational applications, femtorv32 is probably an easier implementation of risc-v to understand; it's a lot less verilog and a lot more straightforward — ⁂ — for videos like this that are mostly slides and somebody talking, if you're interested in the verbal information and not the pretty face, i recommend yt-dlp --write-auto-sub --sub-lang en,es -f '[height<800]' https://www.youtube.com/watch?v=GSHasXHvZaQ (or possibly even just downloading the .vtt files without the video at all; it is unfortunate that youtube doesn't have an 0.5 fps 640×480 option for things like this) and then devtt.py < SERV：\ 32-bit\ is\ the\ New\ 8-bit\ -\ Olof\ Kindgren\,\ Qamcom\ \[GSHasXHvZaQ\].en.vtt | less where devtt.py is http://canonical.org/~kragen/sw/dev3/devtt.py http://canonical.org/~kragen/sw/dev3/devtt.py or equivalent (i can't have been the first person to want this, and probably someone has written a better version) the transcript is only 2130 words and so reading it only takes about 6 minutes, while the video is 21 minutes the transcript has a lot of errors but is adequate

ilyt 4y ago
> 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.
- tromp 4y ago
  > 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.
  - kragen 4y ago
    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
- danhor 4y ago
  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$).
- kragen 4y ago
  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

pulse7 4y ago

How fast is it?

vintermann 4y ago
Fast enough to run doom at 1/4 fps, according to the video.

vintermann 4y ago

So he's talking about making 2 and 4 bit versions of this. I take it that means making it not-quite bit serial, but making it take 2 or 4 bits at a time? It would still have a 32-bit RISC V instruction set, right?

tromp 4y ago
Correct; a 2 bit version would double the width of the ALU and all data paths. And preserve the instruction set.

vardump 4y ago

Z80 was a bit... err 4 bit a like this. Used in for example Sinclair Spectrum, MSX, CP/M, Gameboy (although modified), TI-8x calculators, etc. had an ALU that computed 8 bit operations in two 4 bit slices. Edit: and now that I think about it, Motorola 68000 was also like this. Internally 16-bit ALU, but operated on 32 bit registers. 32-bit operations were done in two phases, just like on Z80.

klelatti 4y ago
More recently doesn't the AMD AVX 512 implementation do this too? [1] There is very little truly new! [1] https://www.phoronix.com/review/amd-zen4-avx512 https://www.phoronix.com/review/amd-zen4-avx512
kjs3 4y ago
The IBM 360/30 (lowest end of the 360 mainframe line other than the not-quite-compatible 360/20) used an 8-bit ALU to implement a 32-bit ISA in microcode.

rasz 4y ago

Academics, doing useless stuff just to publish. This takes more space than 6502 or Z80 while also being slower.

vardump 4y ago
µC performance doesn't always matter. Sometimes you need something that takes very little FPGA or ASIC space. This leaves more space for the actually important stuff. When performance does matter, you just use something speedier. More choice is good.
- rasz 4y ago
  This is bigger than 8bit cores.
  - vardump 4y ago
    SERV seems to be very comparable to a 6502 in size in terms of ASIC gates required. On an FPGA, SERV's implementation seems to be a times smaller.
    - rasz 4y ago
      if you ignore register file
      - vardump 4y ago
        True, unless you use a reduced one.
JoachimS 4y ago
Olof Kindgren is not in academia. He is an embedded consultant working for Qamcom, a consultancy in Sweden, USA etc. https://www.qamcom.com https://www.qamcom.com And as he points out in the presentation, SERV is used in several (and growing) real world systems as a flexible control plane in ASICs, FPGAs etc.