First read/write!

doc/Makefile

@@ -0,0 +1,20 @@
+# Minimal makefile for Sphinx documentation
+#
+
+# You can set these variables from the command line, and also
+# from the environment for the first two.
+SPHINXOPTS    ?=
+SPHINXBUILD   ?= sphinx-build
+SOURCEDIR     = .
+BUILDDIR      = _build
+
+# Put it first so that "make" without argument is like "make help".
+help:
+	@$(SPHINXBUILD) -M help "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
+
+.PHONY: help Makefile
+
+# Catch-all target: route all unknown targets to Sphinx using the new
+# "make mode" option.  $(O) is meant as a shortcut for $(SPHINXOPTS).
+%: Makefile
+	@$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)

doc/conf.py

@@ -0,0 +1,52 @@
+# Configuration file for the Sphinx documentation builder.
+#
+# This file only contains a selection of the most common options. For a full
+# list see the documentation:
+# https://www.sphinx-doc.org/en/master/usage/configuration.html
+
+# -- Path setup --------------------------------------------------------------
+
+# If extensions (or modules to document with autodoc) are in another directory,
+# add these directories to sys.path here. If the directory is relative to the
+# documentation root, use os.path.abspath to make it absolute, like shown here.
+#
+# import os
+# import sys
+# sys.path.insert(0, os.path.abspath('.'))
+
+
+# -- Project information -----------------------------------------------------
+
+project = 'PeakRDL-regblock'
+copyright = '2021, Alex Mykyta'
+author = 'Alex Mykyta'
+
+
+# -- General configuration ---------------------------------------------------
+
+# Add any Sphinx extension module names here, as strings. They can be
+# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
+# ones.
+extensions = [
+]
+
+# Add any paths that contain templates here, relative to this directory.
+templates_path = ['_templates']
+
+# List of patterns, relative to source directory, that match files and
+# directories to ignore when looking for source files.
+# This pattern also affects html_static_path and html_extra_path.
+exclude_patterns = ['_build', 'Thumbs.db', '.DS_Store']
+
+
+# -- Options for HTML output -------------------------------------------------
+
+# The theme to use for HTML and HTML Help pages.  See the documentation for
+# a list of builtin themes.
+#
+html_theme = 'alabaster'
+
+# Add any paths that contain custom static files (such as style sheets) here,
+# relative to this directory. They are copied after the builtin static files,
+# so a file named "default.css" will overwrite the builtin "default.css".
+html_static_path = ['_static']

doc/index.rst

@@ -0,0 +1,20 @@
+.. PeakRDL-regblock documentation master file, created by
+   sphinx-quickstart on Tue Nov 16 23:25:58 2021.
+   You can adapt this file completely to your liking, but it should at least
+   contain the root `toctree` directive.
+
+Welcome to PeakRDL-regblock's documentation!
+============================================
+
+.. toctree::
+   :maxdepth: 2
+   :caption: Contents:
+
+
+
+Indices and tables
+==================
+
+* :ref:`genindex`
+* :ref:`modindex`
+* :ref:`search`

doc/logbooks/000-Main-Logbook

@@ -28,6 +28,54 @@ the template would do something like:
 
 Basically, i'd define a ton of helper functions that return the signal identifier.
 
+================================================================================
+Accesswidth vs Regwidth
+================================================================================
+Reading some old versions of the SystemRDL spec (the old "v1 RDL" spec from Cisco)
+it becomes clear that regwidth is actually what defines the bus width!
+
+Some useful points:
+- Section 8.1.3 defines the bus width to be sized according to the superset
+span of msb:lsb fields.
+
+This means that 'accesswidth' is solely for defining the minimum *granularity* of
+an access. For example - APB3 lacks byte strobes, so the bus imposes an accesswidth == regwidth
+APB4 introduces PSTRB, which implies the ability to support an accesswidth of 8
+
+Changes to this tool this new understanding imposes:
+    - derive the CPU bus width based on the largest regwidth
+        this seems like a reasonable & easy thing to implement
+    - CPUIF should make sure to always present an aligned address!
+        if bus width is 32-bits, decoder logic shall recieve an address with bits [1:0] ALWAYS zeroed
+        Codify this in the internal specification!
+    - address decode may produce multiple strobes if registers are packed.
+        Eg: if bus width is 32, and there is a region of 8-bit registers that are tightly packed,
+        an access will strobe four of them at once
+    - readback stage needs to account for narrower registers, and properly
+        pack read values into the response array
+        Remember - the array width is based on the CPUIF width, NOT the reg width
+        Multiple regs can be packed into a cpuif width
+
+So what on earth do I do with accesswidth?
+    - seems to define if sub-accesses are even allowed.
+      I suppose this would be useful to allow/deny such transactions on a per-register basis
+    - for now, enforce that accesswidth == regwidth. This lets me ignore it.
+    - In the future I can ease up on this if I enforce a uniform accesswidth granularity
+      ie: accesswidth can be used, as long as all registers agree to the same value.
+      (unless the regwidth is narrower. thats ok.)
+      eg - OK if:
+        max regwidth = 32
+        all 32-bit registers use 16-bit accesswidth
+        irrelevant to 16 and 8-bit registers
+
+
+Write about this in the SystemRDL errata?
+    Could there be guidance on the CPUIF bus width?
+    For simple protocols like APB, this is meaningful.
+    Maybe not so much in other protocols...
+    Maybe add some words to the "clarifications" section
+
+
 ================================================================================
 Dev Todo list
 ================================================================================
@@ -38,6 +86,32 @@ Dev Todo list
 
 - readback mux
 
+- Start a sphinx docs thing
+    I need to keep better track of everything!
+    Diagrams of each layer in an architecture overview
+    transcribe logbook into dev notes
+
+- Am i doing msb/lsb correctly?
+    bit ordering:
+        fields are always [msb:lsb]
+        but could be [low:high] or [high:low]
+    But how does this affect bus <-> field mapping though??
+        - [low:high] means that bit order gets swapped from the bus
+        - [high:low] means bit order is sliced naturally
+    DONE
+
+
+endianness controls byte order of the CPU bus
+    controls byteswap at the CPUIF layer
+    Internally, use little endian ordering.
+
+    TODO: Add hooks for this in CPUIF layer
+
+Do something about cpuif byte strobes?
+    Remove for now?
+    Demote to APB3?
+
+
 - Other field output assignments
 
 - HWIF layer

doc/logbooks/Validation Needed

@@ -123,8 +123,6 @@ cpuif_resets
     I have zero interest in implementing resynchronizers
 
 ! regwidth/accesswidth is sane
-    ! accesswidth is the same for all registers in the regblock
-        - accesswidth is what implies the cpuif bus width
     ! accesswidth == regwidth
         Enforce this for now. Dont feel like supporting fancy modes yet
         X regwidth < accesswidth
@@ -132,10 +130,18 @@ cpuif_resets
         ! regwidth > accesswidth
             Need to extend address decode strobes to have multiple bits
             this is where looking at endinaness matters to determine field placement
+            Dont feel like supporting this yet
+    ! constant regwidth?
+        For now, probably limit to only allow the same regwidth everywhere?
 
 
 ! Contents of target are all internal. No external regs
 ! Does not contain any mem components
 
 ! Do not allow unaligned addresses
-    All offsets & strides shall be a multiple of the accesswidth used
+    All offsets & strides shall be a multiple of the regwidth used
+
+    - each reg needs to be aligned to its width
+    - each regfile/addrmap/stride shall be aligned to the largest regwidth it encloses
+        --> Should i promote this check to the compiler? At least as a warnable condition
+            Currently i think I only do the more stringent case of block alignment.