project:ledum:start
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| project:ledum:start [2025/07/03 22:08] – [ISA Description] memory allocatro description + channel has been added to terminology yokotashi | project:ledum:start [2026/07/11 21:50] (current) – Fixed naming "dzoe" -> "joe", added note about "BB68" bluebear | ||
|---|---|---|---|
| Line 4: | Line 4: | ||
| name=Ledum| | name=Ledum| | ||
| image=ledum: | image=ledum: | ||
| - | sw=FIXME| | + | sw=to be determined but open| |
| - | hw=FIXME| | + | hw=to be determined but open| |
| founder=[[user: | founder=[[user: | ||
| interested=[[user: | interested=[[user: | ||
| Line 12: | Line 12: | ||
| }} | }} | ||
| - | This project | + | ---- dataentry |
| + | name: Ledum | ||
| + | status: active | ||
| + | image: {{: | ||
| + | ---- | ||
| + | //Traveling at night is neither faster, nor safer. That's why we do it. (Christopher Illopoly, Cultist Simulator)// | ||
| - | ===== Project Objectives ===== | + | This project aims to design and develop a **central processing unit** (CPU) from the ground up, with all circuitry, instruction set, and ways of communication with peripherals devised completely by us. Ideally, at least one of the resulting designs should be so simple that it could be produced in silicon with primitive, 1980-style lithography. If this succeeds, we can advance to more sophisticated designs. |
| - | - **Achieve High Correctness in Design:** | + | ===== Project goals and timeline (very approximate) ===== |
| - | * Use formal methods, simulation, | + | |
| - | * Ensure that the CPU meets or exceeds industry standards for reliability and precision. | + | |
| - | - **Implement Object Capabilities Model:** | + | |
| - | * Integrate an object capabilities model into the CPU’s architecture to allow fine-grained, | + | |
| - | * Ensure that resource access control is embedded at the hardware level to improve security by default. | + | |
| - | - **Enable Scalable Security Mechanisms: | + | |
| - | * Design the CPU with scalable security features, leveraging capabilities to prevent unauthorized access and misuse of system resources. | + | |
| - | * Provide users with the flexibility to define and manage their own access control policies through object capabilities. | + | |
| - | - **Optimize Performance: | + | |
| - | * Ensure that the CPU achieves optimal performance in terms of throughput, latency, and power consumption, | + | |
| - | * Ensure, that the CPU architecture can be parallelized to achieve IPC>1 including OoO execution, although to do so isn't primary objective. | + | |
| - | * Balance hardware features for high-performance tasks with robust security measures for sensitive operations. | + | |
| - | - **Establish Robust Ecosystem Support: | + | |
| - | * Develop comprehensive software toolchains and drivers to support the object capability model. | + | |
| - | * Collaborate with industry partners to ensure broad compatibility with existing operating systems and applications. | + | |
| + | ==== 2024-2027(? | ||
| - | ===== Project Scope ===== | + | * a simple, but functional, 100% open source 16-bit CPU with an original instruction set |
| + | * here we want to learn all the needed technology for designing a complex circuitry needed for a (still simple) CPU | ||
| + | * the CPU itself, if successful, should also be a teaching tool for showing how to do these things | ||
| + | * technically inspired by the most famous old CPUs: 6502, Z80, Motorola 68000 | ||
| + | * status: | ||
| + | * tooling for building an instruction set (by [[user: | ||
| + | * generator of instruction structure and bit layout | ||
| + | * assembler and disassembler | ||
| + | * emulator | ||
| + | * instruction set is complete (by [[user: | ||
| + | * hardware capabilities and high-level schematics are complete (by [[user: | ||
| + | * Verilog sources for the detailed hardware are in progress (by [[user: | ||
| + | * basic BIOS-like (KERNAL for C64 afficionados) is in progress (by [[user: | ||
| + | * compiler for higher but still low-level C-language is being prepared (by [[user: | ||
| - | ==== In-Scope | + | ==== 2028(?): second phase ==== |
| - | * **CPU Architecture Design:** Define instruction sets, pipeline architecture, | + | |
| - | * **Formal Verification: | + | |
| - | * **Security & Resource Management:** Implement object capabilities as a mechanism to control access to system resources. | + | * features for comfortable coding in assembly for speed sensitive routines (to be fleshed out later - [[user:yokotashi]]' |
| - | * **Prototyping | + | * about 64 registers with support for tagging |
| - | * **Performance Evaluation: | + | |
| - | * **Software Toolchain Development: | + | * in-CPU circuitry for more sophisticated calculations, like divisor, hasher... |
| - | + | * fast calls to the kernel | |
| - | ==== Out of Scope ==== | + | * performance optimizations known in modern CPUs |
| - | + | * parallelizability, | |
| - | | + | * configurable balance between throughput, latency, and power consumption |
| - | * Manufacturing of physical CPU chips (to be handled post-design phase). | + | |
| - | * Integration into mass-market consumer devices | + | |
| ===== Workshops ===== | ===== Workshops ===== | ||
| - | As a part of our efforts, we have realized that different members of the team have different experience with various scientific and engineering fields and it would be very helpful to ensure that everyone has some basic understanding of all required topics. The workshops typically take place during the working group' | + | As a part of our efforts, we have realized that different members of the team have different experience with various scientific and engineering fields and it would be very helpful to ensure that everyone has some basic understanding of all required topics. The workshops typically take place during the working group' |
| If there is enough interest, we are streaming the workshops online using [[https:// | If there is enough interest, we are streaming the workshops online using [[https:// | ||
| - | |||
| - | ==== Streaming Setup in Brmlab ==== | ||
| - | |||
| - | The public laptop available in the social room, clearly labeled " | ||
| - | |||
| - | - Locate the aforementioned laptop. | ||
| - | - Find its power supply adapter. | ||
| - | - Put the laptop on a table near the pack of cables hanging down from the ceiling roughly in the middle of the room. | ||
| - | - Connect the power supply adapter to 230V socket and to the laptop. | ||
| - | - Power up the laptop by pressing the power button located just left of the delete key which is in the top right corner of the keyboard and double-check it is not running only on the battery. | ||
| - | - Connect a mouse to the laptop - it is really needed for any actual directing of the session. | ||
| - | - Go to the audio mixing table - by the time of this writing, it is located by the 3rd window pair counting from the entrance | ||
| - | - At the table, search for and pick up: | ||
| - | * red/black USB device for capturing HDMI output | ||
| - | * blue USB-A to USB-A USB 3.0 cable | ||
| - | * (probably black) HDMI cable of sufficient length (2m should be OK) | ||
| - | - Get back to the laptop and connect the HDMI capture device to the remaining USB-A port of the laptop. | ||
| - | - Start the Chromium browser and load the meeting URL (see above). | ||
| - | - Grab the HDMI cable going from the projector just under the ceiling and connect it to the integrated HDMI port on the right hand side of the laptop (next to the power supply connector). | ||
| - | - Power up the projector using the " | ||
| - | - Ensure the system is configured to use the external projector as secondary / separate screen. | ||
| - | - Move the Chromium browser window to the secondary screen and put it in the full-screen mode. Beware - without Fn-Lock, the F11 key puts the laptop in the Airplane Mode. | ||
| - | - Start OBS Studio (it is installed). | ||
| - | - If it asks for the permission to share a screen window, check it is the Chromium browser window you have just opened and allow sharing. | ||
| - | - In the "Scene Collections" | ||
| - | - Select the " | ||
| - | - Ensure the laptop' | ||
| - | - In the sources list right to the scene selection of the previous step, check and ensure: | ||
| - | * The " | ||
| - | * The " | ||
| - | * The " | ||
| - | - Now that everything is ready, click the "Start Virtual Camera" | ||
| - | - Go back to Chromium browser window and select the newly created "OBS Camera" | ||
| - | - Go back to OBS Studio and select the " | ||
| ==== Past Workshops ==== | ==== Past Workshops ==== | ||
| Line 105: | Line 73: | ||
| * 2025-01-09 17:00 [[user: | * 2025-01-09 17:00 [[user: | ||
| - | ==== Planned ==== | ||
| - | |||
| - | |||
| - | ===== Design Topics ===== | ||
| - | ==== ISA Description ==== | ||
| - | Warning: This part may change wildly at this stage. | ||
| - | |||
| - | === Registers === | ||
| - | * 64 GPR | ||
| - | * upto 64 PTR (Pointer registers) | ||
| - | * special registers (CS:IP and several configuration registers probably) | ||
| - | * No flag register (flags are going either to another GPR or to a special 4-bits adjacent to every GPR), this should help future with parallelization | ||
| - | |||
| - | === Pointers === | ||
| - | * Fat Pointers supported and tested by HW | ||
| - | * Ultra Fat Pointers supported and tested by HW, can't be dereferenced outside the CS stored inside them | ||
| - | |||
| - | === Tagging === | ||
| - | * All RAM and registers is tagged, so ALU knows which type it's operating on and pointer cannot be created freely | ||
| - | * Types: int, uint, float in 4, 8 ... 64 bit lengths fit in vector 64-bit long; Fat pointer, Ultra fat pointer | ||
| - | |||
| - | === SW-implemented services === | ||
| - | * scheduler | ||
| - | * memory allocator | ||
| - | * IO allocator | ||
| - | * message broker | ||
| - | * garbage collector | ||
| - | * process creator | ||
| - | |||
| - | Terminology | ||
| - | * thread - X has asked scheduler to create it. X is it's parent and can see it's whole memory. | ||
| - | * process - X has asked process creator to create it. Process creator is it' parent and can see it's whole memory. X is it's parent process in process creator' | ||
| - | * fiber - any thread or process | ||
| - | * There may be more process creators. Therefore the same fiber may be viewed as thread (from it's process creator and it's parent threads) and as process (from another process under the same process creator). | ||
| - | * Channel - some way of communicate which is using a tagged handle normal fiber can't create from integer (similar restriction like a FP has) | ||
| - | |||
| - | == scheduler == | ||
| - | * has HW capability to change settings of the HW scheduler in the CPU | ||
| - | * shouldn' | ||
| - | * works on fibers (doesn' | ||
| - | * must know CS:IP and time-quota of every fiber | ||
| - | * contains fiber hierarchy | ||
| - | * fiber can push to it (via message containing FP) what childs it wants and how to divide it's time between them. Those information must be converted to absolute values by the scheduler, therefore they can't be used directly from fiber' | ||
| - | |||
| - | == memory allocator == | ||
| - | * starts with FP to almost all memory (except memory given to other SW services) | ||
| - | * has information about what memory is empty and used | ||
| - | * has information about memory quotas | ||
| - | * when asked through some channel if can either allocate memory and return a FP or " | ||
| - | * it manages similar hierarchic structure as scheduler or process creator, but there are channels and their associated quotas in the tree | ||
| - | |||
| - | #1 message handler will do the creation itself, but the channel will be between allocator and anyone who has the complementary handler given to the original caller | ||
| - | ==== Electronic Circuit Design ==== | ||
| - | |||
| - | ==== Integrated Circuit Design ==== | ||
| - | |||
| - | ==== Tooling ==== | ||
| - | |||
| - | ==== Miscellaneous ==== | ||
| === Things to read === | === Things to read === | ||
| - | == Optimizations == | ||
| - | - Compressed pointers: https:// | ||
| - | |||
| - | - Read barriers pro concurent scavenger: https:// | ||
| - | - Chinual: https:// | + | ==== Optimizations ==== |
| - | - https:// | + | * Compressed pointers: https:// |
| - | ===== Current Progress ===== | + | * Read barriers pro concurent scavenger: https:// |
| + | * Chinual: https:// | ||
| + | * https:// | ||
| - | ==== Tooling | + | ===== Past milestones ===== |
| {{ : | {{ : | ||
project/ledum/start.1751580486.txt.gz · Last modified: 2025/07/03 22:08 by yokotashi