search

pulp-platform / chimera

Other
10 stars 2 forks source link

Cleaner/clearer simulation flow #9

Open FrancescoConti opened 4 months ago

FrancescoConti commented 4 months ago

imho a bit (a lot) more clarity would be nice in how the simulation platform is built. Disclaimer: I did not check anything in depth (no time unfortunately), so feel free to correct me!

right now i see:

  1. bender checkout
  2. make chs-hw-init "initialize" all cheshire simulation platform (which I guess means generate register maps with reggen, but maybe also other Cheshire-specific stuff, rather obscure to me)
  3. make snitch-hw-init "initializes" the snitch cluster but it also checks out bender deps and then it actually also builds and optimizes it, is that then linked later with the rest of the platform? If Bender is called multiple times, how do we avoid issues with incompatible versions of deps?
  4. make chs-sim-all script generation for cheshire postponed here?
  5. make chim-sim script generation for the top-level chimera?
  6. then we go directly inside the sim target and call scripts for setup, compile, and simulation manually from QuestaSim...

IMHO it's a bit all mixed up (Chimera->Cheshire->Snitch->Cheshire->Chimera...) and clearly a lot of clutter will eventually be removed, but it makes sense to me to start a discussion on this pretty early. Personally I see two strategies:

Full-dependency Bender flow:

  1. initial configuration check (e.g., which kind of clusters/accelerators are included)
  2. deps resolution and checkout for all IPs in a single Bender flow.
  3. "initialization" (template gen) of the top, Cheshire, and various clusters/accelerators that need this. [1]
  4. script generation for the full platform (per-target)
  5. usual target flow

The main limitation here is that we can (will) run into dependency problems if one of the clusters and the top want to use different versions of an IP (I think this already happens with PULP clusters and the top with the iDMA version). As an alternative (more complicated):

Vendorized flow:

  1. need to fork the main chimera repo
  2. initial configuration check (e.g., which kind of clusters/accelerators are included).
  3. deps resolution and checkout for each IP separately (with Bender or even other flows).
  4. vendorization inside the chimera repo (see e.g. https://github.com/esl-epfl/x-heep), possibly also automatically prepending IP names/versions to modules/packages/etc (e.g., module cluster_peripherals in pulp_cluster becomes module pulp_cluster_v1.2.3_cluster_peripherals)
  5. "initialization" (template gen) of the top, Cheshire, and various clusters/accelerators that need this.
  6. script generation for the full platform (per-target)
  7. usual target flow

Personally, I very much prefer the former, keeping in mind that in some cases (e.g., projects with external partners) the latter strategy might also be used, at least for some IPs. I think particularly of the case of a cluster/accelerator provided by a partner that uses an older version of our own IPs... What do you think?

Scheremo commented 4 months ago

Ciao Francesco, thanks for your comment.

I agree that currently things are not entirely coherent in the build flow. I think your suggestions make sense, and I believe what is implemented currently is fairly close (if less streamlined) to what your first suggestion entails. Maybe we can have a chat about the top-down view of the build flow we would like, and converge to that vision.

Scheremo commented 1 month ago

I would like to bump this issue back to relevance. Having a single make target for the entire setup process would be very good!