A kernel in hardware (making a very CISC architecture)

[AndrewAPrice]

Not a serious product proposal, but just a thought. I've seen CPUs written in HDLs running on FPGAs, I've seen Doom run CPU-less on FPGAs. Would it be possible to build an OS in, say VHDL or Verilog?

Building drivers and a window manager in a HDL seems a little overkill (more power to you though, if you can) mostly because any update or new device would require reprogramming the FPGA. Instead, I was thinking it might be more practical to implement a CISC architecture where the are microkernel-like instructions, with the CPU running all drivers, services, user programs in isolated address spaces and system calls are basically CPU instructions.

[Clover5411]

I'm not familiar with it, but I heard that Mill CPU architecture was like this.

[iansjack]

Why? What advantage would it have?

It sounds like a mini HiFi system as opposed to a high-quality separates audio system. You’re stuck with the designer’s original concept and you can’t easily update it without throwing everything away.

Apart from which, I don’t think any FGPA would have the capacity to host a useful OS.

But it depends upon what you mean by an operating system. This already happens, to a certain extent, in SOCs used in specialist applications. I presume you mean a general purpose OS.

So, why would it be a good idea?

[rdos]

I think the main obstacle is that Verilog and HDLs build highly specialized parallel hardware that can be extremely powerful, while CPU cores are serial and so are the programming languages used to build OSes. A CPU core on a FPGA is not very effective and takes a lot of resources. I think the integration of a multicore CPU and an FPGA would be more useful.

[linguofreak]

Not a serious product proposal, but just a thought. I've seen CPUs written in HDLs running on FPGAs, I've seen Doom run CPU-less on FPGAs. Would it be possible to build an OS in, say VHDL or Verilog?

Building drivers and a window manager in a HDL seems a little overkill (more power to you though, if you can) mostly because any update or new device would require reprogramming the FPGA. Instead, I was thinking it might be more practical to implement a CISC architecture where the are microkernel-like instructions, with the CPU running all drivers, services, user programs in isolated address spaces and system calls are basically CPU instructions.

From a strict mathematical standpoint, any Turing-complete language/device/system can be used to implement any other Turing complete system.

And from the perspective of a userspace program, system calls already do look very much like single CPU instructions. The program has no more visibility as to what goes on in kernel space than it does as to what the CPU microcode is doing. Indeed, the opposite approach to what you're proposing can be, and has been, used to implement cheap, low-performance versions of an architecture: simply don't implement the most expensive instructions in the architecture (in terms of silicon area and microcode space), and then have the OS catch the illegal instruction trap and emulate the instruction. This effectively turns an instruction into a system call.

It's really considerations of flexibility (might people want more than one implementation of this?) and resources (can the needed algorithms be implemented in hardware in the space available) that determine what services are provided by the CPU vs. the OS, and, as illustrated above, the resource part can vary between different implementations of the same architecture. I doubt a full CPU-OS will be practical in the foreseeable future: system calls differ widely in their complexity, and Moore's law seems to be running out of steam, so you might move some low-hanging fruit into an ISA, but the heavier system calls will likely remain prohibitively expensive to implement in hardware. And considerations of flexibility may prevent many things that could be moved into an ISA from actually being implemented in hardware. For example: If you're putting together an new OS API for your ISA, then that will limit the portability of software written for that API to other ISAs. If you're using an existing API (Windows, POSIX), then that will complicate porting software for other operating systems than the chosen system to your ISA.

[rdos]

Why complicate things? Put the FPGA on the PCI bus with many lanes & high speed, and you will have a very effective device that cannot be implemented using any number of CPU cores available today, and then you build a driver for your OS that interfaces it with your application software.

The fact is that parallel Verilog on a modern FPGA can achieve performance that cannot be realized with normal CPU cores, and it doesn't cost more than an ordinary motherboard. Of course, the FPGA program will be highly specialized, and can only do that specific function you designed it to do, but it does it much faster. For instance, many FPGAs come with hundreds of DSP cores that each can do one multiply & add operation per clock cycle. Even if you had a computer with 100s of CPU cores, your application would not be likely to use them all.

[jemo07]

Hi all, well, it’s strictly confined to the definition of an OS.

There are several Forth based HW CPU’s ( Forth is described as a soft virtual CPU )
In the ERA of CPM and DOS, it was considered an OS, and this was further extended in to 32bit real with OpenFirmware of OpenBoot.

Have a look at:

https://excamera.com/files/j1.pdf

and https://github.com/microCore-VHDL/microCore

Both of these let you interact with the HW directly, in essence the Forth System has become the OS, so, if accepting a Forth System as an OS, then yes.

Cheers from Spain.