================================================================================
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 receive 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
================================================================================

- Signals - clean them up and add proper support
    Generate these in the hwif_in struct? I forget what I decided
    - FIXME: cpuif reset inside top-level addrmap results in two input signals:
        - one popped out to top
        - another inside the input struct

- Interrupt properties
    i think my docs are missing a property or something...

- Rework TB CPUIF driver a bit
    Split test API into a class
    class receives a vif to the driver
    make this more proper w.r.t extending stuff.

- Add more CPUIF protocols
    - AXI-Lite
    - cpuif interface passthrough?

- Add synthesis tests
    Create a new testcase base class
    Similar concept as before with testcases & parameterization.
    Launch Vivado and do out-of-context synthesis
    Override message severities to highlight:
        - undriven nets
        - multi-driven nets
        - combo loops
    Figure out a way to test these separately from other testcases
    maybe rearrange folders so:
        test/test_behav/...
        test/test_synth/...

- break out 'next' and singlepulse into a separate section of their own.
    these should always be lowest priority regardless of precedence
    and always end up as the "else" clause in the conditional list.

- Link more functions to the dereferencer
    I shouldn't have to go to the hwif or whatever
    dereferencer should have all the query functions

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?