one more docs update

README.md

@@ -1,4 +1,4 @@
-![](assets/manta.png)
+![](doc/assets/manta.png)
 
 ## Manta: An In-Situ Debugging Tool for Programmable Hardware
 ![functional_simulation](https://github.com/fischermoseley/manta/actions/workflows/functional_simulation.yml/badge.svg)

doc/index.md

@@ -1,7 +1,6 @@
+![](assets/manta.png)
+
 ## Manta: An In-Situ Debugging Tool for Programmable Hardware
-![functional_simulation](https://github.com/fischermoseley/manta/actions/workflows/functional_simulation.yml/badge.svg)
-[![License: GPL v3](https://img.shields.io/badge/License-GPLv3-blue.svg)](https://www.gnu.org/licenses/gpl-3.0)
-[![Code style: black](https://img.shields.io/badge/code%20style-black-000000.svg)](https://github.com/psf/black)
 
 Manta is a tool for getting information into and out of FPGAs over an interface like UART or Ethernet. It's primarily intended for debugging, but it's robust enough to be a simple, reliable transport layer between a FPGA and a host machine. It lets you configure a series of cores on a shared bus via a YAML or JSON file, and then provides a Python API to each core, along with vendor-agnostic Verilog HDL to instantiate them on your FPGA. 
 
@@ -26,7 +25,7 @@ Manta includes a few cores, configurable to your liking:
 
 * __LUT RAM__ and __BRAM Cores__: Under the hood, Manta is just a bunch of modules sharing a common address and data bus, so cores that add Block RAM and LUT RAM to said bus are also available. More information on this bus configuration is on the [How it Works](how_it_works) page.
 
-These are more explicity described on the [cores](cores) page.
+These are more explicity described on their individual pages.
 
 ## Design Philosophy
 

doc/io_core.md

@@ -0,0 +1,19 @@
+# IO Core
+
+_More details to follow here as this gets written out, for now this is just a sketch_
+
+This emulates the look and feel of an IO pin, much like what you'd find on a microcontroller. 
+
+Manta provides a Python API to control these - which allows for behavior like:
+
+```python
+>>> import manta.api
+>>> cores = manta.api.generate('manta.yaml')
+>>> io = cores.my_io_core
+>>> io.probe0.set(True)
+>>> io.probe0.set(False)
+>>> io.probe1.read()
+True
+```
+
+The caveat being that Manta is limited by the bandwidth of PySerial, which is limited by your operating system and system hardware. These calls may take significant time to complete, and __they are blocking__. More details can be found in the API reference.

doc/logic_analyzer_core.md

@@ -1,6 +1,4 @@
-# Cores
-
-## Logic Analyzer
+# Logic Analyzer
 
 This emulates the look and feel of a logic analyzer, both benchtop and integrated. These work by continuously sampling a set of digital signals, and then when some condition (the _trigger_) is met, recording these signals to memory, which are then read out to the user. 
 
@@ -32,19 +30,19 @@ uart:
 
 There's a few parameters that get configured here, including:
 
-### Probes
+## Probes
 
 Probes are the signals read by the core. These are meant to be connected to your RTL design when you instantiate your generated copy of Manta. These can be given whatever name and width you like (within reason). You can have up to 256 probes in your design. 
 
-### Sample Depth
+## Sample Depth
 
 Sample depth controls how many samples of the probes get read into the buffer.
 
-### Triggers
+## Triggers
 
 Triggers are things that will cause the logic analyzer core to capture data from the probes. These get specified as a Verilog expression, and are partially reconfigurable on-the-fly. This will get elaborated on more as it's implemented, but if your trigger condition can be represented as a sum-of-products with each product being representable as an operator from the list [`==`, `!=`,`>`, `<`,`>=`, `<=`, `||`,`&&`, `^`]  along with a configurable register and a probe, you won't need to rebuild the bitstream to update the trigger condition. Whew, that was a mouthful.
 
-### Operating Modes
+## Operating Modes
 
 The logic analyzer can operate in a number of modes, which govern what trigger conditions start the capture of data:
 
@@ -52,7 +50,7 @@ The logic analyzer can operate in a number of modes, which govern what trigger c
 * __Incremental__: Only pull values when the trigger condition is met. Ignore values received while the trigger condition is not met,
 * __Immediate__: Read the probe states into memory immediately, regardless of if the trigger condition is met.
 
-### Holdoff
+## Holdoff
 
 The logic analyzer has a programmable _holdoff_, which sets when probe data is captured relative to the trigger condition being met. For instance, setting the holdoff to `100` will cause the logic analyzer to start recording probe data 100 clock cycles after the trigger condition occuring. 
 
@@ -62,27 +60,6 @@ Manta uses a default holdoff value of `-SAMPLE_DEPTH/2`, which positions the dat
 
 Similarly, a holdoff of `-SAMPLE_DEPTH` would place the trigger condition at the right edge of the trigger window. A holdoff of `0` would place the trigger at the left edge of the window. Postive holdoff would look like this:
 
-
-## IO Core
-
-_More details to follow here as this gets written out, for now this is just a sketch_
-
-This emulates the look and feel of an IO pin, much like what you'd find on a microcontroller. 
-
-Manta provides a Python API to control these - which allows for behavior like:
-
-```python
->>> import manta.api
->>> cores = manta.api.generate('manta.yaml')
->>> io = cores.my_io_core
->>> io.probe0.set(True)
->>> io.probe0.set(False)
->>> io.probe1.read()
-True
-```
-
-The caveat being that Manta is limited by the bandwidth of PySerial, which is limited by your operating system and system hardware. These calls may take significant time to complete, and __they are blocking__. More details can be found in the API reference.
-
 ## Everything Else
 
 Manta needs to know what clock frequency you plan on running it at so that it can progperly generate the baudrate you desire. It also needs to know what serial port your FPGA is on, as well as how to configure the interface. Right now only standard 8N1 serial is supported by the FPGA.

doc/roadmap.md

@@ -1,37 +1,34 @@
 ## Planned Work:
 
-- _Verify Manta on non-Xilinx FPGAs_: This is in progress for the Lattice iCE40 on the Icestick, and the Altera Cyclone IV on the DE0 Nano.
+* _Clock Domain Crossing:_ You should be able to put cores in different clock domains - although I'm struggling to figure out where exactly this would be useful. Xilinx's ILA will let you have multiple cores and it doesn't care much which 
+clock domain those are under, so some more investigation will be needed there. 
 
-- _More Examples_, such as
+* _More Examples_, such as
     - SD card controller
     - BRAM controller
     - Pong, with controls via played through python on your machine. 
 
-- _Configurable Trigger Location:_ Instead of always centering the downlink core's waveform around where the trigger condition is met, you might want to grab everything before or after the trigger. Or even things that are some number of clock cycles ahead or behind of the trigger. Being able to specify this 'holdoff' or 'position' in the downlink core configuration would be nice. Especially if it's something as simple as `beginning`, `middle`, `end`, or just a number of clock cycles.
+* _Configurable Trigger Location:_ Instead of always centering the downlink core's waveform around where the trigger condition is met, you might want to grab everything before or after the trigger. Or even things that are some number of clock cycles ahead or behind of the trigger. Being able to specify this 'holdoff' or 'position' in the downlink core configuration would be nice. Especially if it's something as simple as `beginning`, `middle`, `end`, or just a number of clock cycles.
 
-- _Incremental Triggering_: Only add things to the buffer when the trigger condition is met. Going to be super useful for audio applications.
+* _Reconfigurable Trigger Modes_: Being able to switch between an incremental trigger and a single-shot trigger while the HDL's on the board might be useful. 
 
-- _Python API_: You should be able to run manta and scrape waveforms from the command line - but let's say you're working on a project that loads audio from an SD card, and you want to have a downlink core in incremental mode to pull your audio samples, but you want to export that as a .wav file. Or you want to do some filtering of the data with numpy. You should have a python API that lets you do that.
+* _Incremental Triggering_: Only add things to the buffer when the trigger condition is met. Going to be super useful for audio applications.
 
-- _OpenCores Listing_: Might want to chuck this up on [https://opencores.org/projects](https://opencores.org/projects), just for kicks. 
-
-- _FuseSoC integration_: This will probably exist in some headless-ish mode that separates manta's core generation and operation, but it'd be kinda nice for folks who package their projects with FuseSoC.
 
 ## Potential Future Work:
 
 The guiding principle behind adding features here is to just do a bunch of projects, run into annoying bugs, and see what'd be useful to have as a tool, and then implement that. That said, there's a few ideas I've been kicking around at the moment:
 
-* _Reconfigurable Trigger Modes_: Being able to switch between an incremental trigger and a single-shot trigger while the HDL's on the board might be useful. 
-
 * _Configurable Clock Edge:_ Right now when we add a waveform to a VCD file, we assume that all the values change on the rising edge of the ILA clock. And that's true - we sample them on the rising edge of the input clock. I don't know if we'd want to add an option for clocking in things on the falling edge - I think that's going to make timing hard and students confused.
 
-* _Uplink Cores_: Similar to how a donwlink core receives a trigger condition and dumps it to UART, an uplink core would be loaded with some values the host machine, and then dump them onto a set of probes - one after another on every clock cycle. I don't know how useful this would be though.
+* _OpenCores Listing_: Might want to chuck this up on [https://opencores.org/projects](https://opencores.org/projects), just for kicks. 
 
-* _Reconfigurable uplink cores:_ Instead of loading a BRAM with some fixed content and calling it a day, we should be able to load new data into that memory, and then dump it to the system when needed.
+* _FuseSoC integration_: This will probably exist in some headless-ish mode that separates manta's core generation and operation, but it'd be kinda nice for folks who package their projects with FuseSoC.
 
-* _Clock Domain Crossing:_ You should be able to put cores in different clock domains - although I'm struggling to figure out where exactly this would be useful. Xilinx's ILA will let you have multiple cores and it doesn't care much which 
-clock domain those are under, so some more investigation will be needed there. 
+* _Test Manta on non-Xilinx FPGAs_: This is in progress for the Lattice iCE40 on the Icestick, and the Altera Cyclone IV on the DE0 Nano.
 
 ## Completed Features:
 
-* _Packaging_: Manta should fundamentally be out of the way of the hardware developer, so it needs to live on the system, not as source code in the project repo. We learned this with `lab-bc` last semester - we couldn't update it easily and it ended up living in people's git repos. Which shouldn't be necessary since they're not responsible for versioning it - we are. Same mentality here.
+* _Packaging_: Manta should fundamentally be out of the way of the hardware developer, so it needs to live on the system, not as source code in the project repo. We learned this with `lab-bc` last semester - we couldn't update it easily and it ended up living in people's git repos. Which shouldn't be necessary since they're not responsible for versioning it - we are. Same mentality here.
+
+* _Python API_: You should be able to run manta and scrape waveforms from the command line - but let's say you're working on a project that loads audio from an SD card, and you want to have a downlink core in incremental mode to pull your audio samples, but you want to export that as a .wav file. Or you want to do some filtering of the data with numpy. You should have a python API that lets you do that.

doc/stylesheets/extra.css

@@ -0,0 +1,3 @@
+:root {
+    --md-primary-fg-color:        #3499f3;
+  }

mkdocs.yml

@@ -8,6 +8,8 @@ docs_dir: 'doc'
 
 theme:
   name: material
+  logo: assets/manta_minimal_border.png
+  favicon: assets/manta_with_shadow.png
   features:
     - content.code.copy
     - content.code.annotate
@@ -29,6 +31,9 @@ theme:
         icon: material/brightness-4
         name: Switch to light mode
 
+extra_css:
+  - stylesheets/extra.css
+
 markdown_extensions:
   - pymdownx.highlight:
       anchor_linenums: true
@@ -42,5 +47,6 @@ nav:
     - Home: index.md
     - Getting Started: getting_started.md
     - How it Works: how_it_works.md
-    - Cores: cores.md
+    - Logic Analyzer Core: logic_analyzer_core.md
+    - IO Core: io_core.md
     - Roadmap: roadmap.md