The F-CPU Project

FAQ

Site Map Search [NYI] The F Architecture Documents

Philosophy

Q1: What does the F in F-CPU stand for?

A: It stands for Freedom, which is the original name of the architecture, or Free, in the GNU/GPL sense.

The F does not stand for free in a monetary sense. You will have to pay for the F1 chip, just as you have to pay nowadays for a copy of a GNU/Linux distribution on CD-ROMs. Of course, you're free to take the design and masks to your favorite fab and have a few batches manufactured for your own use.

Q2: Why not call it an O-CPU (where O stands for Open)?

A: There are some fundamental philosophical differences between the Open Source movement and the original Free Software movement. We abide by the latter, hence the F.

The fact that a piece of code is labeled Open Source doesn't mean that your freedom to use it, understand it and improve upon it is guaranteed. Further discussion of these matters can be found here.

Architecture

Q1: Why did you choose a memory-to-memory architecture? Why not a register-to-register architecture like all other RISC processors?

A: Basically, for performance: we wanted to improve on RISC, so we had to look for a different solution. One of the critical performance bottlenecks in modern Operating Systems is the context switch latency, basically caused by saving and restoring register sets. The F architecture provides near-zero context switch latencies. However, there are many RISC-like ideas in the F architecture.

We are working on a White Paper which discusses this issue in detail. A preliminary version can be found here.

Q2: Why an external FPU?

A: This is implementation specific and depends entirely on how many gates we can fit in a single 122 mm2 die. The F2 could have up to 4 FPUs on chip, since it will be manufactured using 0.18 micron technology. The architecture only states that up to four FPUs can be used in parallel with the main CPU.

Q3: Why don't you support SMP?

A: SMP is an Intel-proprietary implementation of Symmetric Multi-Processing. In our case, it is not even desirable to implement shared-bus multiprocessing, because the F1-CPU already has a very high rate of bus utilization. Adding more processors would inevitably mean creating a bottleneck that would severely limit performance. We opted for a novel implementation of NUMA-style multiprocessing, which allows both shared memory (with cache-coherency) and message-passing.

Performance

Q1: Wat can we expect in terms of performance from the F1 CPU?

A: Merced-killer. :-).

Although the F1 CPU will probably run at a lower clock rate compared to the Merced, due to improvements in design (geared to achieving very high levels of parallelism at execution time) and gcc and kernel-specific optimizations, it is expected that integer performance will be comparable to or better than the Merced.

FPU performance will basically depend on the number of FPUs plugged on the CPU bus. With two FPUs the F1 will probably provide better performance than a Merced. With four FPUs it should leave the Merced in the dust.

Beowulf F supercomputer implementations should provide superior performance, because of the exceptional bandwidth and low latencies of our NUMA-style multiprocessing mechanism.

Yeah, we know that sounds a little bit ambitious...

Compatibility

Q1: Will the F1 run my DOS software?

A: Maybe. We are planning to build in an x86 emulator in the F1 BIOS. But we only want to boot the CPU on standard x86 motherboards. We doubt the F1 will support sophisticated DOS games and other x86-specific packages.

Q2: Is the F1 CPU Windows (98, NT) compatible?

A: No. It will not run WINE either.

It should however run Windows emulators that include x86 CPU emulators such as Twin, as well as Windows itself under whole-PC emulators such as Bochs. In either case however you will need to run another operating system, such as GNU/Linux, and emulation will likely be fairly slow.

And of course there is the slight possibility that Microsoft will port Windows NT to the F1, but I wouldn't hold my breath. ;-)

Q3: Will I be able to plug the F1 in a standard Socket 7, Super 7 or Slot 1 motherboard?

A: In principle, yes. This is one of its design parameters.

Your motherboard will have to support the 2.2V rating of the F1 CPU, and there may be other requirements/limitations. But in principle there is enough bus bandwidth in a 100 MHz Super 7 or Slot 1 motherboard to support a high-performance CPU like the F1. 66MHz Socket 7 motherboards will be supported too, but their performance will be somewhat limited.

Q4: What OS kernels will the F-CPU support?

A: Linux will be ported first, and MkLinux will perhaps be ported too later on. A port of Linux will be developed simultaneously with the F1 CPU development.

We will first port gcc to the F architecture. Basically the F1 will run all the software available for a standard GNU/Linux distribution.

Features

Q1: What kind and size of caches will the F1 CPU have?

A: Internally, the F1 will have Harvard-style separate caches for instructions and data. We are planning on 64KB 4-way set associative L1 caches (one each for data and instructions). We also have small L0 caches for instructions (512 bytes) and data/virtual registers (8KB).

Cost/Price/Purchasing

Q1: How much will the F1 CPU cost?

A: Our estimates are that an F1 CPU will cost approximately US$100.

See our detailed cost estimate if you don't believe us!

The F-CPU Project Last updated September 17 1998 20:03:51 PM. Copyright 1998 The F-CPU Project.
About This Site | Mirrors | Feedback