olo_base_arb_wrr¶
Status Information¶
VHDL Source: olo_base_arb_wrr
Description¶
This entity implements a weighted round-robin arbiter. Each input in the In_Req vector is assigned a configurable weight via the Weights vector. The weight specifies how many identical grants on the Out_Grant vector can be issued consecutively before the arbiter moves to the next grant.
When In_Valid is asserted, the arbiter checks active requests and produces a grant.
- If Latency_g = 0: Out_Valid is asserted in the same clock cycle.
- If Latency_g = 1: Out_Valid is asserted one clock cycle later. In return this option can run at higher clock frequencies.
Out_Valid indicates that Out_Grant holds a valid result. Out_Grant may be one-hot or all-zero if no grant is possible, such as when all weights are zero, there are no active requests or a combination of both.
Example¶
The following waveforms show scenarios with No Latency_g=0 and with Latency_g=1, highlighting signal behavior in each case. Note that for all figures, WeightWidth_g=4 is assumed, so every weight maps to a single hex-digit, which is easy to read.
In the first cycle, the first requester gets a grant.
In the second cycle the grant is switched to the next entitled requester because the Weights for the first requester is only 1 and it already got that one grant. The second requester did not request a grant (In_Req='0').
Hence the third requester gets the grant for two cycles (becaust the corresponding Weight is 2).
In the last cycle, the last requester gets the grant. The second last requester does not get a grant although In_Req='1' because the corresponding Weight is zero.
Important Note on Input Timing¶
Weights is treated as a static control signal. Changes are reflected in the behavior of the arbiter within less than 5 clock cycles or one input sample.
Normally this does not play a role becaus Weights in most applications is static. However, if Weights changes dynamically this must be kept in mind.
This is an implementation tradeoff chosen to limit the lenght of combinatorial paths (i.e. to allow higher clock frequencies).
Changes in In_Req are applied immediately.
Requests Change:
Generics¶
| Name | Type | Default | Description |
|---|---|---|---|
| GrantWidth_g | positive | - | Number of requesters (number of bits in In_Req and Out_Grant vectors) |
| WeightWidth_g | positive | - | Number of bits in single weight |
| Latency_g | natural | 0 | Allowed values: 0 - for combinatorial operation, 1 - for registered operation |
Interfaces¶
Control¶
| Name | In/Out | Length | Default | Description |
|---|---|---|---|---|
| Clk | in | 1 | - | Clock |
| Rst | in | 1 | - | Reset input (high-active, synchronous to Clk) |
Static Configuration¶
| Name | In/Out | Length | Default | Description |
|---|---|---|---|---|
| Weights | in | GrantWidth_g*WeightWidth_g | - | Weights for each requestor, static control signal |
Request Interface¶
| Name | In/Out | Length | Default | Description |
|---|---|---|---|---|
| In_Valid | in | 1 | - | AXI4-Stream handshaking signal for In_Weights and In_Req |
| In_Req | in | GrantWidth_g | - | Request vector. The highest (left-most) bit has highest priority |
Grant Interface¶
| Name | In/Out | Length | Default | Description |
|---|---|---|---|---|
| Out_Valid | out | 1 | N/A | AXI4-Stream handshaking signal for Out_Grant |
| Out_Grant | out | GrantWidth_g | N/A | Grant output signal |
Architecture¶
Not described in detail. Refer to the code for details.