This module allows to map N inputs from the SoC in to M counters without restrictions.
All SoC signals can be routed to each counter of the PMU.\\
\\
Note that even if the amount of inputs is smaller than the amount of counters it is still interesting to have the crossbar since it allows to map any event to counters that support advanced capabilities such as the MCCU and RDC. At the moment to identify if a counter has MCCU or RDC support is required to check the source code of PMU\_raw.sv in order to see the assignments. By default the quad-core configuration with two events for each core maps this features to events 0 to 7.\\
This modules is meant to be instantiated by the interface agnostic PMU (PMU\_raw.sv). Only one instance of this module is required.
%This module is meant to be a blackbox inside the chisel code. It belongs to the Drac class in the \emph{rocket.scala} file. We can have as many instances of this module as cores are instantiated in the SoC. Currently only single core operation has been tested.
This module requires two integer parameters. \textbf{N\_IN} defines the number of inputs provided by the SoC.
\textbf{N\_OUT} defines the number of outputs of the Crossbar and matches the amount of counters in the PMU.\\
The amount of bits required for each configuration field of each output is stored in the local parameter \textbf{N\_BITS\_CFG} and its value is the ceiling of the base 2 logarithm of N\_IN.
Interface signals of the module are listed in table \ref{port:crossbar}. Default parameter values are used for width and Index fields but they may change for each implementation.
%TODO
%\begin{table}[H]
% \centering
% \begin{tabular}{lllll}
% \hline
% Port\_Name & Direction & Width & Index & Description \\
% \hline
% CLK & INPUT & 1 & - & Main clock, up to 200MHz \\
When reset is active (LOW), internal registers are set to 0. In the next cycle outputs of the crossbar will become 0.\\
When reset is not active (HIGH) input signals selected by the configuration fields are routed to the output. Since outputs are registered, we see one cycle of latency.
The number of inputs (N\_IN), shall be larger than the outputs (N\_OUT). If this is not the case padding signals can be added in the SoC side, but the unit will take more resources than strictly needed and it is not recommended for final applications or resource evaluation.
The unit allows to route N input signals in to M output signals. Unused inputs are unconnected.\\
\\
The crossbar routes the signals based on the values of cfg\_i. Each output has one configuration field that indicates the input that is routing. The value for the configuration field of each output matches the the position in vector\_i of the signal that you want to route through.\\
Each configuration field takes\textit{\$clog2(N)} bits. In the default integration with PMU\_raw the fields are\textbf{ contiguous and consecutive} to each other. Due to this arrangement it may be the case for \textbf{configuration fields to not be aligned with data words} of the target processor or cross address boundaries. It is up to the software developers to provide function calls to handle this scenarios.\\
\\
Outputs of the crossbar are registered.
\subsection{Packages and structures}
No packages and structures are used in this module.
After reset of a top module (PMU\_raw for instance) you may experience that all the outputs route the event in the first position of vector\_i. This is intended behavior and happens due to the reset of the configuration registers (cfg\_i).\\
\\
In the default integration with PMU\_raw.sv there is a self-test capability that bypasses the crossbar with certain test patterns. This \textbf{self-test capability} is configured in the main configuration register of PMU\_raw.sv. Be sure to have this function disabled if you plan to use the crossbar.
