Rational Crossing Reset Bug

[moniriki]

There is a bug in the Chipyard SystemBus when it is coupled with a rational crossing type with different core and uncore reset domains. The rational crossing is between the core and uncore side of the system bus, and there exists per-core resets and one uncore reset.

An assertion is thrown whenever I place one core in reset, after that core has been running for some time. The problem is that the uncore side of the rational crossing, which exists in the SystemBus, does not get reset. This puts the TLRationalCrossingSink, instantiated inside the TLInterconnectCoupler_sbus_from_rockettile, out of sync with the now reseted source side. This happens because the TLRationalCrossingSource side got reset (driven by core reset), but the TLRationalCrossingSink side did not (driven by uncore reset), which puts the counts of each module out of sync. This throws an assertion error.

A simple fix would be to logical OR the reset of both domains (core + uncore) at the TLInterconnectCoupler_sbus_from_rockettile reset port, which would allow the TLRationalCrossingSink module to also get reset at the same time as the TLRationalCrossingSource module. This would keep both sides of the RationalCrossing in sync, and remove the assertion error. I've tested this and it seems to work.

My only trouble is implementing this fix in the scala code, as I don't know where to place this OR gate logic. @jerryz123 do you have any thoughts on where I can fix this problem in the chipyard files? I've only tested this fix by hacking the generated RTL. Fix shown below:

  TLInterconnectCoupler_sbus_from_rockettile coupler_from_rockettile (	// @[generators/diplomacy/diplomacy/src/diplomacy/lazymodule/LazyScope.scala:98:27]
    .clock                                                          (_fixedClockNode_auto_anon_out_0_clock),	// @[generators/rocket-chip/src/main/scala/prci/ClockGroup.scala:115:114]
    .reset                                                          (_fixedClockNode_auto_anon_out_0_reset || auto_sbus_clock_groups_in_member_sbus_rockettile_0_reset),	// @[generators/rocket-chip/src/main/scala/prci/ClockGroup.scala:115:114]
    .auto_tl_master_clock_xing_in_a_bits0_opcode                    (auto_coupler_from_rockettile_tl_master_clock_xing_in_0_a_bits0_opcode),
    .auto_tl_master_clock_xing_in_a_bits0_param                     (auto_coupler_from_rockettile_tl_master_clock_xing_in_0_a_bits0_param),

[moniriki]

Apologies @jerryz123, I posted this issue in the incorrect project. Please let me know if you know where I can place a fix for this, unfortunately I can't seem to find a good spot. Thanks!