OSDev.org

So you just created a brand new CPU architecture and it is working on a FPGA board with some hand-assembled test program, now you need an OS for it. How to do that?

Assumptions:

• 64-bit architecture, with an ISA similar but not identical to AArch64, running at 100MHz.
• Everything is hooked up with an on-chip high speed bus, for example AXI4, also running at 100MHz.
• IP core: DRAM controller with 1GB DDR3-1333. (No configuration needed as memory specs are hard-coded in HDL)
• IP core: QSPI Flash controller with 4MB NOR Flash in XIP mode. (Actual chip is 16MB in size, but the first 12MB is used to hold FPGA bitstream, leaving 4MB available for XIP. This chip can be reprogrammed using FPGA programming tool.)
• IP core: SDIO/MMC controller going to a 32GB microSD card.
• IP core: UART controller
• IP core: Framebuffer-style video and audio output, going to an off-FPGA DisplayPort encoder
• IP core: Ethernet controller, going to an off-chip PHY chip, local network then Internet.
• The CPU core and the bus can be poked with over FPGA JTAG interface.

Teach a C compiler to support it. Look at Johnson's PCC, Fraser & Hanson's LCC, Bellard's TCC, etc.
Then you can port an OS written in C to it. Or write a new one.
You can also do it all in assembly too. It'll just take much much longer.

How would you communicate with these various devices? Are they hardwired to particular MMIO addresses?
Edit: Oh, I just remembered the high-speed bus item. I've never worked with that one though.... how would it be accessed?

alexfru wrote:Teach a C compiler to support it. Look at Johnson's PCC, Fraser & Hanson's LCC, Bellard's TCC, etc.
Then you can port an OS written in C to it. Or write a new one.
You can also do it all in assembly too. It'll just take much much longer.

How about write an assembler, then an LLVM backend? This should give rise to a full modern C++ toolchain in the form of LLVM/clang.

Ethin wrote:How would you communicate with these various devices? Are they hardwired to particular MMIO addresses?
Edit: Oh, I just remembered the high-speed bus item. I've never worked with that one though.... how would it be accessed?

Hard-wired MMIO addresses. The on-chip bus just hooks everything up using a packet switched architecture. The CPU core puts memory requests on the bus, then it is packet switched to the corresponding device.

technix wrote:

alexfru wrote:Teach a C compiler to support it. Look at Johnson's PCC, Fraser & Hanson's LCC, Bellard's TCC, etc.
Then you can port an OS written in C to it. Or write a new one.
You can also do it all in assembly too. It'll just take much much longer.

How about write an assembler, then an LLVM backend? This should give rise to a full modern C++ toolchain in the form of LLVM/clang.

Sure, the assembler and linker are implied and you can play with LLVM as well.
Btw, if you can change your architecture to use the same addressing modes as in the popular architectures, it should be much easier to reuse most of the existing code and file formats. OTOH, if you do that, a question will arise... How is yours going to be better/different and why bother at all?

alexfru wrote:Btw, if you can change your architecture to use the same addressing modes as in the popular architectures, it should be much easier to reuse most of the existing code and file formats. OTOH, if you do that, a question will arise... How is yours going to be better/different and why bother at all?

A major feature of my architecture is it gives the first class citizen treatment to FP and vector operations as regular integer ones - shared register file, unified instruction format and pipelines, etc. This makes my general purpose CPU good at DSP tasks, so I can use it later in my SDR project.

A SDR, or software defined radio, uses DSP techniques to deal with RF signals in the digital domain. SDR permits arbitrary modulation without regard to hardware modulator implementation limitations. My SDR project uses that FPGA-based CPU to handle the digital processing of the IF samples.