Closed BrendenPage closed 8 months ago
@dpetrisko
Probably should update these files to .sv as well? If you do it in a single commit git should migrate the histories correctly
I think file renaming should be done separately from the other changes? I guess the question is, how will the final changes be made? Will it be a squash and merge or a true merge?
On Thu, Nov 9, 2023 at 12:51 AM Dan Petrisko @.***> wrote:
Probably should update these files to .sv as well? If you do it in a single commit git should migrate the histories correctly
— Reply to this email directly, view it on GitHub https://github.com/bespoke-silicon-group/bsg_manycore/pull/708#issuecomment-1803396119, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEFG5AB55TMHP7273AMP2GTYDSKSZAVCNFSM6AAAAAA7D4XLHKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBTGM4TMMJRHE . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Yeah we can squash this one and do the renaming in a second PR. You are right that we don't want to squash the rename with the functional changes
@tommydcjung let me know if there's any breakage, but I tested master base jump with this PR and it's working for basic SPMD regression!
Basejump 2.0 is a new branch of basejump_stl that updates the handshake interface to be more consistent with our style guide (mainly replacing many ready_i/o signals with ready_and_i/o or ready_then_i/o etc). Additionally, the testing infrastructure has been updated to ensure the correctness of the components.
This PR would set manycore to the 2.0 standard and make the repo compatible with the new I/O list changes.