rose/devlog/2025-06-06-SPI-Ready.md

Fabric's Basic Logic Done

Date: 2025-06-06

Goals and expectations

Complete the fabric's code.

Results

Done.

And also revised the directory layout (swapped fabric/ and src/).

As a bonus, I also modularized the interfaces' code, making it cleaner and easier to maintain.

And as a second bonus, I completed the drop logic.

Packet dropping

Packet dropping can be caused by two issues:

1. The packet memory is full, in which case the hub will notify all interfaces to drop their packets.
2. The destination's packet queue is full, in which case the hub will drop the packet by immediately reclaiming the slot via the reuse logic.

There are a few scenarios for which this can play out. Notably, if both the packet memory and the destination's packet queue is full, and the destination was full before the packet memory, then the hub will drop the packet instead of the source interface.

Reflections

1. Keep the momentum alive. I kept the momentum I gained yesterday alive by actively coding today, this helped me pick up my previous thoughts.
2. Small rewards go a long way. I recently showed some people the ROSE repo, they didn't read much code, but they were obsessed with the devlogs and the README and how organized the entire project is. This boosted my confidence in thinking that ROSE could be a game changer for me - I wanted it to become something that people can appreciate, even if they're not devs, even if they don't read the code. I enjoyed their praise, and I'm preparing myself to uphold that.
3. Simplify the logic. Much of today's code was linking different modules together and having internal states within the modules to manage the operations. Most of the time, the data is already available, and there's no reason to stall it for an additional cycle to buffer it.
4. HDL is better for design meant for hardware. This isn't ROSE-specific, but rather a thought that I came across while implementing the new ARCANE load balancing algorithm for an ns-3 sim. It would've been much cleaner to implement a hardware-targeting algorithm in HDL than in a language like C++. For example, the three states of ARCANE (explore, normal and freeze) would be perfectly implemented by an FSM. While the C++ sim would have to schedule timeouts using very explicit (and seemingly unnecessarily complex) code, SystemVerilog would embrace that by design.

Final thoughts

Finally! After more than a month of intermittent coding, I'm close to completing an implementation for the fabric. Just some sim tests and I can begin working on the Linux code for the hosts.

I love coding, I love writing my thoughts down, in code or in plain words. It's the proof of my existence. I'm here to leave a mark, for those who'd like to see how I do it.

C'est cela l'amour, tout donner, tout sacrifier sans espoir de retour.

What is such a thing as love that doesn't hope for anything in return?

It's that the love is for a bigger picture. We'd always hope for something in return, whether that's tangible or intangible, whether that's spontaneous or given to by someone else. But the scale of the hope changes when we have love. With it, we see a bigger picture - how that love is impulsive, how that love drives us forward, and how in the broader view, it makes us better.

Next steps

Testing. I'm sure when I throw real traffic at my code, it will go wrong in ways.

Notably, I should test the drop logic with different scenarios: bursts, incast, and heavy background flows. Simulating congestion is my thing (but, of course, we won't be running something as complex as an AllReduce workload).