dau_core.config

dau-core’s hydra config tree — the core registry.

Hydra composition + the ccflow ModelRegistry ARE the registry: every HDL building block is a CoreDefinition entry in dau-core/cores.yaml, loaded at registry path /dau-core/<core-name>. This package is exposed on the shared hydra searchpath via the hydra.lernaplugins entry point, so dau-build / dau-sim compose it without importing dau-core code.

Attributes

CONTRIB_GROUP

Functions

contributed_options([config_dir, version_base]) → tuple[str, ...]	Contributed tile options installed on the searchpath, discovered.
compose_config([overrides, config_dir, version_base]) → ccflow.utils.hydra.ConfigLoadResult	Compose dau-core's own config tree (group dau-core, option
load_config([overrides, overwrite, config_dir, ...]) → ccflow.ModelRegistry	Compose and load the core registry into the root ModelRegistry.

Package Contents

dau_core.config.CONTRIB_GROUP = 'dau-core-contrib'

dau_core.config.contributed_options(config_dir: str | None = None, *, version_base: str | None = None) → tuple[str, ...]

Contributed tile options installed on the searchpath, discovered.

A consumer should not have to name the vendors it happens to have installed – that is the difference between a package being installable and a package being usable. Hydra can enumerate a group’s options across the whole searchpath, so ask it.

dau_core.config.compose_config(overrides: collections.abc.Sequence[str] | None = None, *, config_dir: str | None = None, version_base: str | None = None) → ccflow.utils.hydra.ConfigLoadResult

Compose dau-core’s own config tree (group dau-core, option cores) with raw overrides.

Contributed tiles are composed too, without the caller naming them: the options of CONTRIB_GROUP are discovered across the searchpath and selected together as a list, which is the form that admits more than one (a bare +group=option selects exactly one, so two installed vendors would silently mean one). A contributor therefore never edits cores.yaml, which is the whole point of contribution.

Two-phase – initialize to discover, then compose – because a group’s options cannot be listed without a searchpath, and the searchpath is what the composition is about to be built from.

dau_core.config.load_config(overrides: collections.abc.Sequence[str] | None = None, *, overwrite: bool = False, config_dir: str | None = None, version_base: str | None = None) → ccflow.ModelRegistry

Compose and load the core registry into the root ModelRegistry.

The composed groups are loaded as ccflow LazyRegistry children, so a CoreDefinition is built when something asks for that core rather than all 59 at load. Loading the palette eagerly cost 164 ms and every consumer paid it to reach one tile; lazily it is 10 ms plus about 4 ms per core actually used (dau_core.registry.core()). A consumer that does need the whole palette – the guards, source staging – asks for it through dau_core.registry.loaded_cores() and pays for it there.