first commit
This commit is contained in:
commit
b50a6640de
55
Architecture.md
Normal file
55
Architecture.md
Normal file
|
|
@ -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.
|
||||
|
||||
---
|
||||
101
Vision.md
Normal file
101
Vision.md
Normal file
|
|
@ -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.
|
||||
|
||||
<!-- Add link to `default.nix` from https://git.joyofhardware.com/Tutorials/bluespec-joh-template-->
|
||||
|
||||
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).
|
||||
Loading…
Reference in a new issue