From b50a6640de358aec8b25a4c913bebea643f8f2a0 Mon Sep 17 00:00:00 2001 From: Yehowshua Immanuel Date: Fri, 17 Jan 2025 10:19:37 -0500 Subject: [PATCH] first commit --- Architecture.md | 55 ++++++++++++++++++++++++++ Vision.md | 101 ++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 156 insertions(+) create mode 100644 Architecture.md create mode 100644 Vision.md diff --git a/Architecture.md b/Architecture.md new file mode 100644 index 0000000..95f6bff --- /dev/null +++ b/Architecture.md @@ -0,0 +1,55 @@ + +# Architecture + +We have 15 servers, two of which are currently racked and online (the rest are in storage). +Each installed/racked server is configured with **128GB RAM** and **two Intel Xeon E5-2690v4 CPUs**. + +One **FrontendMaster (FM)** server is dedicated to serving the actual website, managing user authentication, hosting the git repository service (`git.joyofhardware.com`), and maintaining the Nix cache. The remaining servers function as **Compute Nodes**, which leverage the git and Nix cache to support IDE sessions. + +All servers are interconnected via a **40Gbps QSFP+ switch** with 32 ports, ensuring high-speed communication and scalability. + +--- + +## Online IDE Inner-Workings + +The Online IDE is designed to operate seamlessly on both desktop and browser environments. Below is an overview of the architecture and workflow: + +### Compute Resource Allocation + +- Each Compute Node houses **13 pre-allocated Docker containers**, configured to handle user IDE sessions. + - **Container specifications**: 4 cores, 8GB RAM each. + - The remaining 4 cores per node are reserved for **over-subscribed, single-core containers** (512MB RAM) to accommodate peak demand. + +- Docker containers derive from the **NixOS Docker image** and are equipped with an **s6 Rust Actix-based service**. This service manages frontend requests for: + - Language server completions. + - File browsing and listings for the file pane. + - Bitstream file handling (e.g., piping to WebUSB). + - Real-time telemetry on CPU and RAM utilization. + +### FrontendMaster Node Responsibilities + +The FM server handles user session orchestration by: +1. **Allocating an IDE Session**: + - Assigning an unallocated Docker container from the pool of Compute Nodes. + - Monitoring container availability and spinning up replacement containers when needed. + +2. **Session Initialization**: + - Ensuring the user has a valid git repository on `git.joyofhardware.com`, containing required files (`nix.shell` and `default.nix`). + - Establishing a websocket/tunnel connection between the frontend (FM server) and the container-side Rust Actix service for the user’s session. + - Closing connections and destroying containers when users log out. + +--- + +## Containerized vs Desktop IDE + +For the desktop version (via Tauri): +- The container-side Rust Actix codebase will be modified to operate natively on the user’s desktop, supporting features like language servers and file management directly on local hardware. + +--- + +### Vision for Scalability + +- **Dynamic Scaling**: Containers are spun up on demand, ensuring optimal resource utilization. Idle containers maintain availability for new sessions. +- **Modular Services**: Rust Actix-based services enable efficient handling of language servers, file requests, and telemetry across a distributed infrastructure. + +--- diff --git a/Vision.md b/Vision.md new file mode 100644 index 0000000..35b095b --- /dev/null +++ b/Vision.md @@ -0,0 +1,101 @@ +# Vision + +Designing custom silicon is really challenging for a number of reasons, but +it doesn't have to be. The reasons for this feed into eachother. +Since chip manufacturing is incredibly expensive, the silicon design +industry as a whole is incredibly conservative and resistant to adopting +new tools and highly innovative design methodologies. Because the industry +is so resistant to innovation on the tooling front, capable young talent +that could make an impact in this industry often find careers in alternative +industries. + +To address this problem, we're creating a platform that makes it a joy +to learn how to do custom hardware design. Joy Of Hardware. We're targetting +high-schoolers and young college students who have not yet been biased into +the current mindest on how to design chips. + +Our platform will teach chip design using innovative tools and approaches +including Bluespec(allowing us to build IPs that "just work" when +snapped together with various compiler enforced guarantees), Haskell for +formal modeling, Yosys, and NextPNR(for hassle free syntehsis and place and +routing), and our own custom IDE with a built-in waveform veiwer. + +# ReplIt, but for Hardware + +Essentially, we're trying to make ReplIt, but for hardware. A user logs into +app.joyofhardware.com and is greeted by an IDE containing a code editor, +terminal, and, file browser pane. The user must create a `shell.nix` +and `default.nix` so that they can have reproducible builds. They +might for example work on an FPGA deisgn in Bluespec targetting +the Lattice ECP5. Below is a link to an example `shell.nix` and +`default.nix` that a user might write for their design. + + + +The IDE drops the user into a nix shell session. If the user wants their +work to be persistent, they must commit their work to `git.joyofhardware.com`. +Once they've commited, they can visit their repo on git.joyofhardware.com +and click, "Open In JoyofHardware", which would take them to app.joyofhardware.com, +start their IDE, and open their git repo. The terminal in the IDE would drop them into +the shell with packages available specified by `shell.nix`. + +Right now, everything is hosted with co-location with very capable and powerful +infrastructure. More on this in [Architecture.md](./Architecture.md). + +# Programming Hardware + +The user can purchase their own FPGA hardware and program it through their browser. +We have proted OpenFPGALoader to work in the browser via webUSB which means that +it is possible to program FPGAs such as the Lattice ECP5 based ULX3S. + +We may at some pont in time start manufacturing ULX3S boards at scale should user +demand grow. + +# Tutorials + +We will have tutorials that assume users have little to no knowledge on digital design. +Our aim is to give the user all the knowledge to eventually be able to design implement +a CPU on an FPGA that is capable of running the Linux kernel. + +# Hardware Centric But Not Exclusive + +This platform is hardware/FPGA first, but it doesn't mean that a user couldn't also simply +use JoyOfHardware for learning how to write standard software. The FPGA-first components of +the JoyOfHardware experience mainly stem from the fact that our online IDE has an integrated +waveform viewer as well as the ability to program FPGA from the browser. + +# Low Cost + +Becasue we make use of co-location, our monthly hosting costs are an order of magnitude +lower than they would be in AWS or GCP. As such, we can charge a fraction of the price charged +by other platforms such as ReplIt. + + +# Loading Times + +The platform must feel snappy at all times! Every possible interaction should +always happen in a 10th of a second including page loads. Right now, it takes up +to 30s to load a GitHub codespace, and up to 15s to start a ReplIt session! This +is insane!!! We're writing our frontend in Elm and backend in Rust. Frontend IDE page +loads must be measured in KB. The average page load should never be more than 500KB. + +In rare cases, I might make an exception for the maximum page load to be capped at +1MB. + +# Next Gen IDE + +Because the IDE we're building is so snappy in the browser, it also makes a good candidate +for being a desktop IDE. We will port the IDE to work with Tauri on the desktop. Fully packaged, +I imagine the download size of the desktop IDE might come in at just a few MB. + +# Nix For Infrastructure + +All of our servers are fully managed with Nix from remote deploy, to +re-configuration, to backup, to secret management. + +Our entire stack is fully reproducible(down to the actual hash of all binaries +if built single threaded), and easily scalable. We even have Nix backup configuration +to config files and data, which could be re-deployed at a moments notice on new hardware. + +The only configs nix doesn't backup are router and switch configs(whihc we commit to git +manually).