6489f49873
* Initial plan * Update documentation to use correct repository name PeakRDL-BusDecoder Co-authored-by: arnavsacheti <36746504+arnavsacheti@users.noreply.github.com> * Update CONTRIBUTING.md and GitHub templates with correct repository name Co-authored-by: arnavsacheti <36746504+arnavsacheti@users.noreply.github.com> * Update author to arnavsacheti and clarify bus decoder purpose in documentation Co-authored-by: arnavsacheti <36746504+arnavsacheti@users.noreply.github.com> * Update author to 'Arnav Sacheti' and revise UDP documentation to reflect no current UDP support Co-authored-by: arnavsacheti <36746504+arnavsacheti@users.noreply.github.com> --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: arnavsacheti <36746504+arnavsacheti@users.noreply.github.com>
65 lines
2.7 KiB
ReStructuredText
65 lines
2.7 KiB
ReStructuredText
Register Block Architecture
|
|
===========================
|
|
|
|
The generated bus decoder RTL is organized into several sections.
|
|
Each section is automatically generated based on the source register model and
|
|
is rendered into the output SystemVerilog RTL module. The bus decoder serves as
|
|
an address decode and routing layer that splits a single CPU interface into
|
|
multiple sub-address spaces corresponding to child addrmaps in your SystemRDL design.
|
|
|
|
.. figure:: diagrams/arch.png
|
|
|
|
Although it is not completely necessary to know the inner workings of the
|
|
generated RTL, it can be helpful to understand the implications of various
|
|
exporter configuration options.
|
|
|
|
|
|
CPU Interface
|
|
-------------
|
|
The CPU interface logic layer provides an abstraction between the
|
|
application-specific bus protocol and the internal register file logic.
|
|
This logic layer normalizes external CPU read & write transactions into a common
|
|
:ref:`cpuif_protocol` that is used to interact with the register file. When the
|
|
design contains multiple child addrmaps, the CPU interface handles fanout of
|
|
transactions to the appropriate sub-address space.
|
|
|
|
|
|
Address Decode
|
|
--------------
|
|
A common address decode operation is generated which computes individual access
|
|
strobes for each software-accessible register or child addrmap in the design.
|
|
This operation is performed completely combinationally. The decoder determines
|
|
which sub-address space should handle each transaction based on the address range.
|
|
|
|
|
|
Field Logic
|
|
-----------
|
|
This layer of the register block implements the storage elements and state-change
|
|
logic for every field in the design. Field state is updated based on address
|
|
decode strobes from software read/write actions, as well as events from the
|
|
hardware interface input struct.
|
|
This section also assigns any hardware interface outputs.
|
|
|
|
|
|
Readback
|
|
--------
|
|
The readback layer aggregates and reduces all readable registers into a single
|
|
read response. During a read operation, the same address decode strobes are used
|
|
to select the active register that is being accessed.
|
|
This allows for a simple OR-reduction operation to be used to compute the read
|
|
data response.
|
|
|
|
For designs with a large number of software-readable registers, an optional
|
|
fanin re-timing stage can be enabled. This stage is automatically inserted at a
|
|
balanced point in the read-data reduction so that fanin and logic-levels are
|
|
optimally reduced.
|
|
|
|
.. figure:: diagrams/readback.png
|
|
:width: 65%
|
|
:align: center
|
|
|
|
A second optional read response retiming register can be enabled in-line with the
|
|
path back to the CPU interface layer. This can be useful if the CPU interface protocol
|
|
used has a fully combinational response path, and the design's complexity requires
|
|
this path to be retimed further.
|