Mesh configurations deprecated?

[dpetrisko]

The mesh configuration needs significant work to get back to compiling, let alone supporting features (subarray, etc) that are currently in the ruche configuration. For instance, this instantiation doesn't exist, and also doesn't fit into the updated bsg_manycore_hetero_socket:

bsg_manycore/v/bsg_manycore_tile_compute_array_mesh.v

Line 133 in f534118

bsg_manycore_tile_mesh #(

Are we planning on supporting mesh configurations, or is our future entirely ruched? If ruched, should we delete bsg_manycore_tile_compute_array_mesh and bsg_manycore_tile_compute_mesh?

[taylor-bsg]

I think we will see. We have not run ruching through FPGA yet.

…

On Wed, Jan 5, 2022 at 12:10 AM Dan Petrisko ***@***.***> wrote: Assigned #613 <#613> to @taylor-bsg <https://github.com/taylor-bsg>. — Reply to this email directly, view it on GitHub <#613 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEFG5AE24EA462S7FLVOIM3UUP4GFANCNFSM5LJJB46Q> . You are receiving this because you were assigned.Message ID: <bespoke-silicon-group/bsg_manycore/issue/613/issue_event/5844817789@ github.com>

[drichmond]

Do we want to do some ruche vs mesh experiments in the future?

Just a thought. I realize we're pretty tied to the ruche network at this (it is better in general), and we're all quite busy.

[dpetrisko]

If it's just for FPGA, maybe a path would be to support ruche_factor_p == 0 (stub the links and let it synthesize out)? Not super ideal, but would be a lower code overhead than maintaining two similar toplevels