Updated documentation a bit, added newlines to BENCH, removed wrong comments from L2cache.v

BCC/userBDOS/BENCH.C

@@ -149,11 +149,11 @@ int main()
   BDOS_PrintDecConsole(loopBench());
   BDOS_PrintcConsole('\n');
 
-  BDOS_PrintConsole("CountMillionBench: ");
+  BDOS_PrintConsole("\nCountMillionBench: ");
   BDOS_PrintDecConsole(countMillionBench());
   BDOS_PrintConsole(" frames\n");
 
-  BDOS_PrintConsole("PiBench256:\n");
+  BDOS_PrintConsole("\nPiBench256:\n");
   spigotPiBench();
 
   return 'q';

Documentation/docs/.pages

@@ -0,0 +1,5 @@
+nav:
+    - index.md
+    - Hardware
+    - Software
+    - Build-instructions

Documentation/docs/Build-instructions/.pages

@@ -0,0 +1,7 @@
+nav:
+    - verilog.md
+    - quartus.md
+    - programmer.md
+    - asm.md
+    - bcc.md
+    - wiki.md

Documentation/docs/Build-instructions/wiki.md

@@ -1,18 +1,26 @@
 # Wiki build instructions
+This wiki is built using mkdocs, which runs on Python3
 
-TODO: write this page nicely
-
-- you need mkdocs (pip3 install mkdocs)
-- also you need mkdocs-material from pip3
-- to work on the documentation:
-	- execute ./run.sh to host a local version on localhost:8088
-	- when a file is changed, the website should refresh automatically
-- to deploy the website on the server (notes for self):
-	- execute ./deploy.sh
-	- this will:
-		- build the site to the ./site directory
-		- remove the old fpgc folder on the server
-		- copy the site directory to the server, with fpgc as name
-		- recursively set group to www-data
-	- just make sure you use public key authentication to the server
+## Installation
 
+```bash
+pip3 install mkdocs mkdocs-material mkdocs-awesome-pages-plugin
+```
+
+## Run site (development)
+
+Run `./run.sh` to host a local version on localhost:8088.
+
+When a file is changed, the website should refresh automatically
+
+
+## Deploy site
+
+To deploy the website on my server (only I can do this), run `./deploy.sh`. Just make sure you use public key authentication to the server.
+
+This will:
+
+- build the site to the ./site directory
+- remove the old fpgc folder on the server
+- copy the site directory to the server, with fpgc as name
+- recursively set group to www-data

Documentation/docs/Hardware/.pages

@@ -0,0 +1,5 @@
+nav:
+    - specs.md
+    - Logic
+    - PCB
+    - Addons

Documentation/docs/Hardware/Addons/.pages

@@ -0,0 +1,4 @@
+nav:
+    - case.md
+    - monitor.md
+    - portable-module.md

Documentation/docs/Hardware/Logic/.pages

@@ -0,0 +1,6 @@
+nav:
+    - arch.md
+    - CPU (B32P)
+    - Memory
+    - IO
+    - Graphics

Documentation/docs/Hardware/Logic/CPU (B32P)/.pages

@@ -0,0 +1,7 @@
+nav:
+    - ISA.md
+    - pipeline.md
+    - regbank.md
+    - stack.md
+    - interrupts.md
+    - l1cache.md

Documentation/docs/Hardware/Logic/Graphics/.pages

@@ -0,0 +1,4 @@
+nav:
+    - gpu.md
+    - HDMI.md
+    - ntsc.md

Documentation/docs/Hardware/Logic/IO/.pages

@@ -0,0 +1,9 @@
+nav:
+    - UART.md
+    - SPI.md
+    - USB.md
+    - Ethernet.md
+    - OSTimer.md
+    - PS2.md
+    - GPIO.md
+    - Audio.md

Documentation/docs/Hardware/Logic/Memory/.pages

@@ -0,0 +1,7 @@
+nav:
+    - Map.md
+    - SDRAM.md
+    - Cache.md
+    - SPI-flash.md
+    - ROM.md
+    - VRAM.md

Documentation/docs/Hardware/Logic/Memory/Cache.md

@@ -0,0 +1 @@
+# Cache

Documentation/docs/Hardware/Logic/Memory/1-Map.md → Documentation/docs/Hardware/Logic/Memory/Map.md

@@ -92,9 +92,16 @@ $C02722 +------------------------+
         | Timer3_ctrl    $C0273E |
         | Unused         $C0273F |
         | PS/2 Keyboard  $C02740 |
-        | BOOT_MODE      $C02741 |
-        +------------------------+ $C02741
-
+        | BOOT_MODE      $C02741 | $C02741
+$C02742 +------------------------+
+        |                        |
+        |        Nothing         |
+        |                        | $CFFFFF
+$D00000 +------------------------+
+        |                        |
+        |       Pixel VRAM       |
+        |                        | 
+        +------------------------+ $D12C00
 ```
 
 ## GPU memory map
@@ -136,7 +143,7 @@ $2000 +------------------------+
       +------------------------+
 
 SpriteVRAM
-$000  +------------------------+
+$00   +------------------------+
       |                        | 
       |    %0: X pos           | 
       |    %1: Y pos           | 
@@ -144,4 +151,11 @@ $000  +------------------------+
       |    %3: Palette+flags   | 
       |                        | $FF
       +------------------------+ 
+
+PixelVRAM
+$000  +------------------------+
+      |                        |
+      |   8-bit color value    |
+      |                        | $12C00
+      +------------------------+ 
 ```

Documentation/docs/Hardware/Logic/Memory/SDRAM.md

@@ -1,8 +1,5 @@
 # SDRAM
-The SDRAM is used as the main memory for the FPGC. It has a size of 32MiB. Since it is SDRAM, it requires a controller that handles all access and refreshes. The MU contains such controller to interface with the SDRAM. During initialization, the chip is set to a CAS latency of 2 and a programmable burst length of 2 (since we have 32 bit words, and the chip uses 16 bit data). The controller also handles refreshes. To reduce the amount of latency, the MU sets its busy flag low right after the read data is available or the written data is sent to the SDRAM chip. This way the CPU does not have to wait for row closing operations to be performed. If the MU gets a request from the CPU to read from or write to SDRAM, while the SDRAM controller is busy (for example with a refresh or row closing operations), then the MU will wait until the SDRAM controller is ready. While the SDRAM chip uses 16 bit addresses internally, the controller is addressed by 32 bit words. The data of the SDRAM at power up is undefined, but probably zero. Note that during a reset (soft or hard) of the FPGC, the contents of the SDRAM will stay. To clear the contents of the SDRAM, you can either write all addresses with zeros, or power down the FPGC for several seconds.
-
-## SDRAM controller implementation
-The current SDRAM controller implementation is very basic, and uses a burst of 2 to read/write a 32bit word, after which it shuts down and returns to idle. Because of the huge memory bottleneck of the FPGC, there is a lot to gain here by creating a more complex controller. This will be attempted after upgrading to the Cyclone V board with double the SDRAM bandwidth and capacity. So for now no detailed description of the currently used SDRAM controller.
+The SDRAM is used as the main memory for the FPGC. It has a size of 64MiB (2x32MiB). Since it is SDRAM, it requires a controller that handles all access and refreshes. The SDRAM controller is used to interface with the SDRAM. During initialization, the chip is set to a CAS latency of 2 and a programmable burst length of 1 (since we have 32 bit words, and the SDRAM bus is also 32 bits). The controller also handles refreshes. The controller returns the CPU bus as fast as possible to allow the CPU do other things while the controller is still busy with e.g. writing a word. The data of the SDRAM at power up is undefined, but probably zero. Note that during a reset (soft or hard) of the FPGC, the contents of the SDRAM (but not the cache!) will stay. To clear the contents of the SDRAM, you can either write all addresses with zeros, or power down the FPGC for several seconds.
 
 ## Simulation
-I also added a simulation model of the SDRAM to the project. The currently used SDRAM chip is the Winbond W9825G6KH-6 (an older revision of the FPGA development board uses the Micron MT48LC16M16A2 chip. I originally started with this chip and it also works. The Verilog SDRAM simulation model is a model of the Micron chip).
+I also added a simulation model of the SDRAM to the project. The currently used SDRAM chip is the Winbond W9825G6KH-6, and the FPGA module uses two of these. An older revision of the FPGA development board uses the Micron MT48LC16M16A2 chip. As I originally started with this chip, and since it appears to be a drop-in replacement anyways, I still use the Verilog SDRAM simulation model from the Micron chip.

Documentation/docs/Hardware/Logic/Memory/VRAM.md

@@ -11,4 +11,7 @@ The values of this memory at power up are all zero.
 
 ## SpriteVRAM
 SpriteVRAM is the 9 bit wide dual port dual clock video RAM (SRAM/Block RAM) used by the CPU and the GPU. It contains the sprite table for the GPU. It is implemented using internal SRAM/Block RAM. The memory has room for 64 sprites, where each sprite as a separate address for X position, Y position, tile index and color index+flags.
-The values of this memory at power up are all zero.
+The values of this memory at power up are all zero.
+
+## PixelVRAM
+TODO: add this

Documentation/docs/Hardware/Logic/arch.md

@@ -1,30 +1,34 @@
 # Architecture
-The FPGC consists of three main parts: the CPU, GPU and MU.
+The FPGC consists of three main parts: the CPU, GPU and MU. The SDRAM controller is now separate from the MU.
 
-The CPU, called the B32P, executes the instructions. It reads from and writes to the MU.
- 
+## CPU
+The CPU, called the B32P, executes the instructions. It reads from and writes to the MU or SDRAM controller.
+
+## GPU
 The GPU, called the FSX2, is completely separate from the CPU. It contains the logic for generating a video signal and for creating an image on this signal based on the contents of VRAM. The GPU has its own read port with clock on the dual port VRAM (SRAM/FPGA block RAM), allowing it to run on a completely different clock domain than the rest of the FPGC.
 
-The MU, or memory unit, handles all memory access between the CPU and all the different memories and I/O devices used in the FPGC. The most important memories here are SDRAM, ROM, VRAM and SPI flash. The goal of the MU is to have the CPU access all memories without the CPU having to care about the type or timing of the memory, making an easy memory interface for the CPU. This is achieved a memory map and a bus protocol with a busy/wait signal. However, this currently does cost one cycle of overhead per operation on the MU in most cases.
+## MU & SDRAM controller
+The MU, or memory unit, handles all memory access between the CPU and all the different memories (except SDRAM) and I/O devices used in the FPGC. The most important memories here are ROM, VRAM and SPI flash. The goal of the MU is to have the CPU access all these memories without the CPU having to care about the type or timing of the memory, making an easy memory interface for the CPU. This is achieved a memory map and a bus protocol with a busy/wait signal. However, this currently does cost one cycle of overhead per operation on the MU in most cases. The SDRAM controller, which has a cache layer in between, behaves similar to the MU in terms of the bus protocol. It is made separate to remove the one cycle of overhead.
 
-Block diagram of FPGC:
+## Block diagram
+Simplified block diagram of FPGC:
 
 ``` text
                   +---------------------+
-                  |                     |
-                  |        B32P         |
-                  |         CPU         |
-                  |                     |
-                  |                     |
+                  |                     |       +---------+       +---------+
+                  |        B32P         |       |         |       |         |
+                  |         CPU         |<----->|  Cache  |<----->|  SDRAM  |
+                  |                     |       |         |       |         |
+                  |                     |       +---------+       +---------+
                   +---------------------+
                              ^
                              |
                              v
-+---------+       +---------------------+       +---------+       +---------+
-|         |       |                     |       |         |       |         |
-|  SDRAM  |<----->|                     |       |         |       |         |
-|         |       |                     |       |         |       |         |
-+---------+       |                     |       |         |       |  FSX2   |
+                  +---------------------+       +---------+       +---------+
+                  |                     |       |         |       |         |
+                  |                     |       |         |       |         |
+                  |                     |       |         |       |         |
+                  |                     |       |         |       |  FSX2   |
                   |       Memory        |<----->|  VRAM   |<----->|   GPU   |
 +---------+       |        Unit         |       |         |       |         |
 |         |       |                     |       |         |       |         |

Documentation/docs/Hardware/PCB/.pages

@@ -0,0 +1,4 @@
+nav:
+    - IO-board
+    - module.md
+    - result.md

Documentation/docs/Hardware/PCB/IO-board/.pages

@@ -0,0 +1,4 @@
+nav:
+    - schem.md
+    - layout.md
+    - result.md

Documentation/docs/Hardware/specs.md

@@ -1,7 +1,7 @@
 # Specifications
 These are the current specifications of the FPGC6.
 
-CPU:
+## CPU
 
 - 50MHz 5-stage pipelined CPU with option to add L1 cache
 - 32bit instructions
@@ -9,23 +9,26 @@ CPU:
 - 27bit program counter for a possible address space of 0.5GiB at 32bit
 - Easily extendable amount of hardware interrupts, currently 8 in use
 
-GPU:
+## GPU
 
-- 320x200 at 256 colors Tile-based rendering GPU with selectable HDMI (480P) and NTSC (240P) output
+- 320x200 at 256 colors Tile-based and bitmap (at 320x240) rendering GPU with selectable HDMI (480P) and NTSC (240P) output
 - Two layers of 8x8 Tiles of which one layer (background) has horizontal hardware scrolling support
 - (currently not working anymore) One Sprite layer with support for 64 Sprites. Max 16 Sprites per horizontal line
+- Bitmap rendering layer allowing for access to each of the 230x240 individual pixels supporting 256 colors
 
-Memory:
+## Memory
 
 - 16MiB external SPI flash in two modes:
 	- QSPI with continuous read mode @ 25MHz: 32bit addresses. Read Only!
 	- SPI bus mode @ 25MHz: Accessible as a normal SPI device
-- 32MiB SDRAM @ 100MHz. 32bit addresses. Used as main memory
-- ~16.4KiB VRAM (SRAM). Combination of 32, 8 and 9bit addresses for tile based rendering
+- 64MiB SDRAM @ 100MHz. 32bit addresses. Used as main memory (currently only 32MiB is accessible until memory map is updated)
+- ~16.4KiB VRAM (SRAM) for tile-based rendering. Combination of 32, 8 and 9bit addresses
+- 75 KiB VRAM (SRAM) for bitmap rendering
 - 2KiB internal ROM for the Bootloader. 32bit addresses
-- 4.125KiB Hardware Stack (SRAM). 32bit addresses, internal to CPU
+- 4KiB Hardware Stack (SRAM). 32bit addresses, internal to CPU
+- 4KiB L2 cache (SRAM)
 
-I/O:
+## I/O
 
 - Memory mapped I/O
 - 3 One Shot (OS) timers

Documentation/docs/index.md

@@ -8,21 +8,28 @@
 Use the navigation menu to find the other Wiki pages.
 
 ## What is FPGC?
-FPGC (FPGA Computer) is my big hobby project. It is a computer where practically every part of it is designed and implemented by me, from the 1's and 0's in the ISA to the operating system, and from the PCB to the 3D printed enclosure.
 
-## Version 6
-The largest change in the FPGC6 is the complete redesign of the CPU from the [FPGC5](https://github.com/b4rt-dev/FPGC5) with more advanced techniques and performance in mind. The FPGC6 how has a pipelined CPU including hazard detection/forwarding, with a better architecture for running C code including better signed integer support.
-Eventually it will also have memory cache (L1 data and L1 instruction cache), which should drastically speed up performance because of the SDRAM bottleneck. The new CPU, called B32P, was recreated from scratch. Aside from the CPU, all other parts of the system are almost identical to the FPGC5, and the CPU itself still has all old instructions except for COPY implemented. This way, after updating the Assembler, almost all code will still work.
+FPGC (FPGA Computer) is my big hobby project. It is a computer where almost every part of it is designed and implemented by me, from the 1's and 0's in the ISA to the Operating System, and from the PCB to the 3D printed enclosure.
 
-A lot of inspiration for the CPU is taken from MIPS, because many online resources on more advanced CPU techniques like pipelining and caching use MIPS as example. As for implementation specific inspiration, I looked a lot at [mips-cpu by jmahler](https://github.com/jmahler/mips-cpu), since it is a good example of a simple pipelined CPU.
+TODO: add picture of FPGC running edit on edit.c
+
+## New in version 6
+
+The largest change in the FPGC6 is the complete redesign of the CPU from the [FPGC5](https://github.com/b4rt-dev/FPGC5) with more advanced techniques and performance in mind. The new CPU (built from scratch again) is now a pipelined CPU including hazard detection/forwarding with a better architecture for running C code including better signed integer support. It also allows for L1 cache (although currently not implemented). A lot of inspiration for the CPU is taken from MIPS, because many online resources on more advanced CPU techniques like pipelining and caching use MIPS as example. As for implementation specific inspiration, I looked a lot at [mips-cpu by jmahler](https://github.com/jmahler/mips-cpu), since it is a good example of a simple pipelined CPU.
+
+Version 6 of the FPGC now also contains a better SDRAM controller and cache, which greatly reduces the SDRAM bottleneck.
+Aside from this and the CPU, all other parts of the system are mostly identical to the FPGC5, and the CPU itself still has all old instructions implemented (although using different opcodes and argument placement) except for COPY. Therefore, after updating the Assembler, almost all code will still work meaning I do not have to rewrite most of my code base.
 
 ## Current state
-- Ready to design and add L1 cache
-- All code but the BCC Assembler work with the new CPU
-- Waiting for upgraded FPGA board to arrive (double SDRAM bandwidth and capacity, huge FPGA upgrade with almost 10x more block RAM!)
-- Need to add some folders from FPGC5 back to FPGC6
+
+- All existing FPGC5 code but the BCC Assembler works with the new CPU
+- FPGA module upgraded to Cyclone V (10x more block RAM!) with double the SDRAM bandwith and capacity
+- Added bitmap GPU layer that allows for accessing individual pixels
+- L2 cache working, no need for L1I cache with the current arbiter implementation
+- Ready to design and add L1D cache
 
 ## Project Links
+
 FPGC6:
 
 - [Github Repository](https://www.github.com/b4rt-dev/FPGC6)
@@ -33,4 +40,34 @@ FPGC5:
 
 - [Github Repository](https://github.com/b4rt-dev/FPGC5)
 - [Gogs Mirror](https://www.b4rt.nl/git/bart/FPGC5-mirror)
-- [Documentation](https://www.b4rt.nl/fpgc5)
+- [Documentation](https://www.b4rt.nl/fpgc5)
+
+## Next steps
+
+- Create 3D raycaster using new bitmap GPU layer
+- Update BCC assembler for new ISA
+- Add data memory cache (at 100MHz)
+- Implement true GPIO
+- Implement I2S Audio
+
+## Documentation checklist
+
+- [x] Index page
+- [ ] CPU
+- [ ] GPU
+- [ ] MU
+- [ ] PCB
+- [ ] 3D printed enclosure
+- [ ] NTSC encoder
+- [ ] HDMI encoder
+- [ ] SDRAM controller
+- [ ] SPI flash reader
+- [ ] Assembler
+- [ ] BCC
+- [ ] BDOS (MemoryMap, shell, usb&PS2 keyboard, HID&NetHID, netloader, GFX, syscalls)
+- [ ] userBDOS
+- [ ] Compiling code on BCC (ASM, BDOS, EDIT)
+- [ ] BCC programs (EDIT, WEBSERV, etc.)
+- [ ] All programmers (UART, SPI flasher, BDOS send/upload)
+- [ ] BDOS sync files
+- [ ] Running BCC tests

Documentation/docs/todos.md

@@ -1,31 +0,0 @@
-# TODOs
-Things I want to do or I already have done but did not update this page:
-
-## Next steps:
-- Update documentation
-    - Parts that are worth documentation:
-        - CPU
-        - GPU
-        - MU
-        - PCB
-        - 3D printed enclosure
-        - NTSC encoder
-        - HDMI encoder
-        - SDRAM controller
-        - SPI flash reader
-        - Assembler
-        - BCC
-        - BDOS (MemoryMap, shell, usb&PS2 keyboard, HID&NetHID, netloader, GFX, syscalls)
-        - userBDOS
-        - Compiling code on BCC (ASM, BDOS, EDIT)
-        - BCC programs (EDIT, WEBSERV, etc.)
-        - All programmers (UART, SPI flasher, BDOS send/upload)
-        - BDOS sync files
-        - Running BCC tests
-- Update BCC assembler for new ISA
-- Improve the C compiler with new instructions
-- Add instruction memory and data memory cache
-- Implement true GPIO
-- Implement I2S Audio
-- Add L2 cache (within arbiter or MU)
-    - Make use of SDRAM burst to reduce the open/close costs

Documentation/mkdocs.yml

@@ -7,9 +7,15 @@ theme:
 extra_css:
   - stylesheets/extra.css
 
+plugins:
+    - search
+    - awesome-pages
+
 markdown_extensions:
   - codehilite
   - admonition
+  - pymdownx.tasklist:
+      custom_checkbox: False
 
 repo_name: b4rt-dev/FPGC6
 repo_url: https://github.com/b4rt-dev/fpgc6

Quartus/modules/Memory/L2cache.v

@@ -185,7 +185,7 @@ begin
                 state <= state_check_cache;
             end
 
-            state_writing: // Currently disabled setting valid bit to 0. Otherwise causes crashes after a few seconds in L1D cache.
+            state_writing:
             begin
                 if (sdc_done)
                 begin
@@ -196,7 +196,7 @@ begin
                     sdc_start_reg <= 1'b0;
                     sdc_data_reg <= 32'd0;
 
-                    cache_we <= 1'b1; // as long as valid_d <= 0, this does not matter
+                    cache_we <= 1'b1;
                     valid_d <= 1'b1;
                     valid_we <= 1'b1;
 

Verilog/modules/Memory/L2cache.v

@@ -185,7 +185,7 @@ begin
                 state <= state_check_cache;
             end
 
-            state_writing: // Currently disabled setting valid bit to 0. Otherwise causes crashes after a few seconds in L1D cache.
+            state_writing:
             begin
                 if (sdc_done)
                 begin
@@ -196,7 +196,7 @@ begin
                     sdc_start_reg <= 1'b0;
                     sdc_data_reg <= 32'd0;
 
-                    cache_we <= 1'b1; // as long as valid_d <= 0, this does not matter
+                    cache_we <= 1'b1;
                     valid_d <= 1'b1;
                     valid_we <= 1'b1;