feat(cli): select a gateware target profile for peripheral build/deploy - #192
Open
namthor9 wants to merge 1 commit into
Open
feat(cli): select a gateware target profile for peripheral build/deploy#192namthor9 wants to merge 1 commit into
namthor9 wants to merge 1 commit into
Conversation
A peripheral repo can now ship one SDK gateware project per target profile at src/gateware/<profile>/, instead of a single src/gateware/. This is forced by the SDK: peripheral.yaml's target_profile is a single scalar, and a profile's generated top wrapper, Radiant seed and encrypted transport bundle collide by filename with any other profile's while differing in content, so two profiles cannot share a directory. resolve_gateware_project() becomes the one place that decides which project a command acts on: 1. explicit --profile, else $SYNAPSE_GATEWARE_PROFILE 2. a single-project repo (src/gateware/peripheral.yaml) -- unchanged 3. exactly one per-profile project Two or more profiles with no selection is an error, not a guess. The choice also reaches CMake as -DAXON_TARGET_PROFILE, which is what picks the driver's compiled-in clock rate (via-devkit clkmc is 40 MHz, nerv512u-devkit 80 MHz), so picking arbitrarily would ship a driver whose sample rates are off by the ratio of the two clocks with nothing failing until it is on hardware. --profile rides on every build/deploy leaf. The `gateware <verb>` pass-through cannot take it -- argparse.REMAINDER captures the whole tail for the SDK, so a synapsectl-side flag would be forwarded rather than read -- so it honours the env var, and falls back to running the SDK from the repo root (where the user's own --project reaches it verbatim) when nothing resolves. The bare-src/gateware/ redirect is preserved so `gateware new <profile> --target <profile>` still scaffolds into src/gateware/. Single-project repos are unaffected: they resolve to "src/gateware" and pass no -DAXON_TARGET_PROFILE, exactly as before.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Lets a peripheral repo ship one SDK gateware project per target profile at
src/gateware/<profile>/instead of a singlesrc/gateware/. Needed by sciencecorp/axon-peripheral-example#14, which now builds for bothvia-devkitandnerv512u-devkit.Why the layout has to change
peripheral.yaml'starget_profileis a single scalar, and each profile's generated top wrapper, Radiant seed project and encryptedtransport.enc.vbundle collide by filename while differing in content. Two profiles cannot share a directory, so a repo that supports both needs two projects — and the CLI needs to know which one to act on.What's new
resolve_gateware_project()ingateware.pyis the single place that decides:--profile, else$SYNAPSE_GATEWARE_PROFILEsrc/gateware/peripheral.yaml) — the original layoutTwo or more profiles with no selection is an error, not a guess. The selection also reaches CMake as
-DAXON_TARGET_PROFILE, which is what picks the driver's compiled-in clock rate (via-devkit clkmc 40 MHz, nerv512u-devkit 80 MHz). Guessing would produce a driver whose sample rates are off by the ratio of the two clocks, with nothing failing until it's on hardware.--profileis wired onto everybuild/deployleaf, and threads through to the gateware build (--project), the bitstream glob, and the per-project clean (so cleaning one profile leaves the other's build intact).The pass-through
peripherals gateware <verb>can't take--profile:argparse.REMAINDERcaptures the whole tail for the SDK, so a synapsectl-side flag would be forwarded rather than read. It honours$SYNAPSE_GATEWARE_PROFILE, and when nothing resolves it runs the SDK from the repo root and says so — the user's own--project src/gateware/<profile>still reaches the SDK verbatim. The existing bare-src/gateware/redirect is preserved sogateware new <profile> --target <profile>still scaffolds intosrc/gateware/.Compatibility
Single-project repos are unaffected: they resolve to
"src/gateware"and pass no-DAXON_TARGET_PROFILE, exactly as before.Testing
113 pass (99 existing + 14 new in
test_gateware_profiles.py), covering discovery, each resolution branch, precedence, the refusal to guess, and that the SDK--projectargument and the bitstream glob stay in agreement — a mismatch there would build one profile and package the other's stale.bit.