Intermediate state generation between `map_resolver` & `naked_*` combinators

[JongyCysec]

          @minseongg 

If you don't mind, can I ask some questions related to hazardflow design?

With respect to "fetch" pipeline stage, the 2nd & 3rd modules of fetch stage is filter_map and reg_fwd_with_init.

And each of them consists of two submodules again. For example, "filter_map" is implemented by connecting map_resolver_inner module and naked_fsm_filter_map. And "reg_fwd_with_init" is implemented by connecting map_resolver_inner and naked_reg_fwd_with_opt_init.

And the distinguishable characteristic is that the resolver type of intermediary interface of such two sub-modules is Ready<(R,S)>. However, f : impl Fn(P, S) -> (HOption<EP>, S) argument of map_resolver_inner is |r, _| r in filter_map and reg_fwd_with_init. So, it will not be seen by other modules outside. Furthermore, map_resolver_inner with such f argument does nothing. It just forwards ingress payload to egress payload without changes and it even does not check ready signal of egress resolver.

So I wonder what is the motivation that filter_map or reg_fwd_with_init are divided into two sub-modules where map_resolver_inner seems not necessary.

And I wonder the reason why resolver type of intermediary interface is Ready<(R,S)>.

Thank you.

Originally posted by @JongyCysec in https://github.com/kaist-cp/cs492-uarch/issues/16#issuecomment-2372741948

[minseongg]

Answered in https://github.com/kaist-cp/cs492-uarch/issues/16#issuecomment-2375859903

[minseongg]

Closing, feel free to reopen if you have further questions!