| commit | 778ac63b0873e736a731c3e5a12c9faa5b9e9517 | [log] [tgz] |
|---|---|---|
| author | Serge Bazanski <q3k@q3k.org> | Fri Mar 18 13:18:57 2022 +0000 |
| committer | Serge Bazanski <q3k@q3k.org> | Fri Mar 18 13:18:57 2022 +0000 |
| tree | d4d74afd793e43503856a5c850cfb10e7cd1ed94 | |
| parent | aa38a7b1335b276819b0f907faa16e0a7480c3a2 [diff] |
README: initial pass
The QF105 System-on-Chip is an OpenMPW5 tapeout of the QF100 System-on-Chip family.
The QF100 System-on-Chip family is a simple, microcontroller-style system comprised of the following:
Lanai is a family of RISC CPUs first introduced by Myricom in their NICs. Since then, its use seems to have mostly shifted to Google, whose engineers have contributed a Lanai target to LLVM. Not much is known about the use of the core inside Google.
The Lanai implementation in the QF100 series SoC targets the instruction set as generated by LLVM, called ‘Lanai 11’. It diverges in some aspects from the previous versions of the instruction set as documented by Myricom and as implemented by their network cards, by removing RRR (register-register-register, a.k.a. dual-ALU) instructions, removing the PUNT instruction, and tightening some pipeline timing.
TODO: document differences better
We have a work-in-progress LLD implementation for Lanai and Rust target for Lanai, that will be opensourced (and hopefully upstreamed) soon.
The QF100 is built from a ‘bundle’ of verilog exported from the ‘qfc’ repository. This bundle contains pre-processed files containing both compiled Bluespec as well as Bluespec standard library code. Each hard macro in the resulting design has a separate Verilog file named the same way.
To update the bundle from qfc:
$ cd qfc $ bazel build //boards/qf100 $ cp bazel-bin/boards/qf100/qf100/*v ../qf105/verilog/rtl/
You will then have to manually edit mkQF105.v to add power pin passing (gated behind ifdef) to all hard macro instantiations (TODO: automate this).