functionalRead in Ruby garnet

[amoghsgk]

I am running splash2 SE workloads with 4 RISC-V cores using a garnet based meshXY network.

I get a fatal call from Network.hh which doesn't implement functionalRead. The RubySystem.cc directly links to Network.hh and never uses the functionalread in garnetNetwork.hh am i doing something wrong or is this a known issue

[powerjg]

Functional reads in Ruby are not always possible, particularly when using Garnet. This is a known limitation stemming from how Garnet handles data in transit. In Ruby, a functional access must be able to determine the current coherence state and find the most up-to-date data. When data is encapsulated in flits within the Garnet network, it becomes difficult to verify its coherence state, which is why Garnet does not currently implement this functionality.

The coordination of these accesses happens in RubySystem, where the functionalRead method first iterates through all registered controllers in m_abs_cntrl_vec (such as L1, L2, and Directory controllers) to see if the data can be found in a readable state (e.g., AccessPermission_Read_Only or AccessPermission_Read_Write). After checking the controllers, it calls functionalRead on the network pointer (m_network_ptr).

If you look at the SimpleNetwork implementation in src/mem/ruby/network/simple/SimpleNetwork.cc, you can see that it actually does provide a functionalRead implementation. It iterates through its m_switches and calls functionalRead on each switch, which in turn checks its internal MessageBuffers. This is possible because the simple network abstracts the flit-level details that Garnet models.

In theory, Garnet could be updated to follow a similar pattern—traversing its routers, links, and buffers to search for flits containing the requested address. However, even if Garnet were updated this way, a functional read could still fail if the most recent data is currently mid-transit and doesn't have a clearly defined coherence state that the system can rely on. If the data is found elsewhere in the hierarchy (like a cache or the directory) in a readable state, the logic in RubySystem should already be able to retrieve it before even reaching the network-level check.

[amoghsgk]

Hi,

Thanks for the response. I think the masked functional reads are already implemented in garnet too i will follow the same pattern to implement the functional reads

[amoghsgk]

I implemented the changes like you suggested. MI _example cache gets live locked. i also tried using backing store with similar results.

when i traced the rubyrequest all functionalreads in ruby just return false as changes are made only in write phase i have tried just sending false in the rubysystem that leds to fatal error in rubyport as the functional read fails this is avoided by supressfuncerror in memtest would you recommend such a change in rubysystem too by somehow forcing the busy lines to be re read in the next cycle within rubysystem or timing cpu

[amoghsgk]

Update for anyone using this discussion later... I have solved the issue as suggested by @powerjg. The functional reads work as intended my previous livelocking issue has nothing to do with the functional reads fixing the functional reads allowed me to run ruby garnet fs linux boot thankyou.