```{_ex5_submission}
```

# Ex. 5: Hierarchical buses and cascaded interrupts

Group:

{% include 'group.md' %}

## 1. Questions

### 1. of 2: How big (in kB) is the address range for each of the 16 TL-UL devices inside your student module ?

The `student_device_peri` is in the address range `0x10000000` to `0x10FFFFFF`.
Therefore, 24 bits are available for addressing.
Splitting that into 16 equal parts, we have 4 bits of device number and 20 bits left for the device address.
This equates to 2^21 = **2048 KiB** of address space per device.

It should be mentioned that in the default testbench configuration, this would be 4 bits and therefore 2^5 = 16 Bytes of address space per device.

### 2. of 2: Which address bits did your 1:N bus multiplexer decode ?

Of the full 32 bit address, the first 8 bits are the area our mux covers, the next 4 bits are the device address to be decoded, and the last 20 bits are for device internal addressing. The Mux therefore decodes the bits `[23:20]`.

### 3. of 6: How many cycles pass after one of the outermost gray LEDs light up until the application writes to the mode register ?

During that time, 3560ns or 178 cycles pass.

### 4. of 6: Which problems occur in the specified implementation when the change frequency of the running light is too high ? How would a more robust (maybe even elegant?) solution would look like ? Of course the running light itself may be modified as well.

When the running light is set too fast, the interrupt routine is too slow to change the direction in time before the outermost LED is lit. The screenshot below shows that preparing for the actual interrupt routine (saving all registers to the stack) adds quite a big reaction delay. After that, the 4 register/TL transactions to the `rlight` to change the mode (shown at the second cursor) add an additional delay.

![Too fast rlight](res/Ex5_too_fast_rlight.png)

Possible solutions include:

- Writing an optimised assembly irq function could increase the performance on the software side. Maybe even a custom IRQ handler that doesn't require saving all registers.
- Adding addional functionality to the `rlight` module to support a ping pong animation within a given mask, would be the most performant and a more elegant solution.
- Lowering the amount of rergister/TL transactions required to change the direction of the `rlight` within the irq handler would also improve the maximum speed.

Once one would get into the speeds that would cause irqs to be triggered during an execution of a previous irq, one would also need to think about ways to handle that. Even though the current irq implementation is a bit slower than the software polling method, both are well suited for a simple running light.

### 5. Adding IRQ support to the memcpy bus master. How would the IRQ signal be generated ? Which basic steps would the IRQ handler perform ?

The IRQ should be fired once the `memcpy` is completed, so the signal would be determinated by comparing the number of open writes to the memory area to 0. A handler might then provide a callback to the software for proceeding to work with the generated copy, such that the software does not need to run idly while awaiting the `memcpy` to complete.

## 2. Source texts

See appendix

### 2.2 IRQ-Ctrl register interface

```{reggen} student_irq_ctrl
```

### 2.6 Updated interrupt controlled running light register interface

```{reggen} student_rlight
```

## 3. Wave Views

In the following screenshot, the desired signals are displayed in yellow and the start/end trigger signals (`led_o[6]`, `mode.qe`) are displayed in magenta. The cursors mark the relevant rising edges.

![Wave View of rlight IRQ](res/rlight_irq.png)

{% include 'appendix.md' %}