Taking a step back with the memory-mapped control-status interfaces. Previously, the thought was to provide a simplified interface to define control and status registers that would be accessible from a memory-mapped bus. This approach is not general enough, in some designs a memory-mapped bus is not included and the control-status of the peripheral is either statically configured or interfaces with other logic.
A base class ControlStatus was added (currently empty) and each peripheral will define the control and status signals for the peripheral in a specific object (cso) for the peripheral-block. The long-term goal is that the control-status-objects will automatically be compiled into a register-file and automatically mapped. This is very desirable are removes the laborious task of managing large register spaces.
This has some ramifications, the automatic adding of the CSO will take some time to be developed, the previous peripherals that added registers-files to a MemoryMapped bus will not be available (the feature temporarily removed). The documentation has been updated but needs more work to outline the new direction and design approach.
This will provide a faster path to defining the peripherals, defining the control and status signals in a ControlStatus object is straightforward. In the near-term if the CSO signals are desired on a memory-mapped bus they will need to be manually added until the register-file builder and MemoryMapped.add() are implemented.
Taking a step back with the memory-mapped control-status interfaces. Previously, the thought was to provide a simplified interface to define control and status registers that would be accessible from a memory-mapped bus. This approach is not general enough, in some designs a memory-mapped bus is not included and the control-status of the peripheral is either statically configured or interfaces with other logic.
A base class
ControlStatuswas added (currently empty) and each peripheral will define the control and status signals for the peripheral in a specific object (cso) for the peripheral-block. The long-term goal is that the control-status-objects will automatically be compiled into a register-file and automatically mapped. This is very desirable are removes the laborious task of managing large register spaces.This has some ramifications, the automatic adding of the CSO will take some time to be developed, the previous peripherals that added registers-files to a
MemoryMappedbus will not be available (the feature temporarily removed). The documentation has been updated but needs more work to outline the new direction and design approach.This will provide a faster path to defining the peripherals, defining the control and status signals in a
ControlStatusobject is straightforward. In the near-term if the CSO signals are desired on a memory-mapped bus they will need to be manually added until the register-file builder andMemoryMapped.add()are implemented.