Files
PeakRDL-regblock/doc/logbooks/000-Main-Logbook
2021-12-11 20:41:49 -08:00

101 lines
4.2 KiB
Plaintext

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