Removing mxpic_forge from dependency

This commit is contained in:
=
2026-06-01 13:19:27 +08:00
parent d0b6ac018a
commit 1d603dffad
8 changed files with 164 additions and 18 deletions
+24 -17
View File
@@ -4,8 +4,8 @@
The EDA repo owns canvas editing, YAML export, login, and API routing. This
repo owns the Nazca-based GDS build flow: it reads saved cell YAML files,
loads the selected technology manifest, loads PDK GDS assets, registers
routable pins, connects bundle links through `mxpic_forge.Route`, and exports
the final GDS.
routable pins, connects bundle links through `mxpic_forge.Route` when available
or Nazca `interconnects.Interconnect` as a fallback, and exports the final GDS.
## High Level Flow
@@ -34,10 +34,12 @@ Canvas Build GDS
-> downloadable <project>.gds
```
If `mxpic_router`, `mxpic_forge`, Nazca, or optional `gdstk` are absent, the
If `mxpic_router`, Nazca, or optional `gdstk` are absent, the
EDA server can still run canvas and login pages. Build actions are where the
router stack is required. For Build Layout, the YAML is still saved and SVG
preview is skipped when the router stack is missing.
router stack is required. `mxpic_forge` improves routing when present, but is
not required because the router falls back to Nazca Interconnect. For Build
Layout, the YAML is still saved and SVG preview is skipped when the required
router stack is missing.
## Runtime Stack
@@ -51,18 +53,21 @@ require_router_stack()
-> import mxpic_router
-> import nazca
-> optionally import gdstk for SVG preview
-> import mxpic_router.builder._import_mxpic_forge_route()
-> adds sibling ../mxpic_forge to sys.path
-> removes any already-loaded non-forge mxpic modules
-> from mxpic import Route
-> import mxpic_router.builder._import_route_backend()
-> first tries mxpic_router.builder._import_mxpic_forge_route()
-> adds sibling ../mxpic_forge to sys.path
-> removes any already-loaded non-forge mxpic modules
-> from mxpic import Route
-> if mxpic_forge is absent:
-> uses nazca.interconnects.Interconnect through a Route-compatible adapter
```
Important package naming:
- `mxpic_router` is this active router package.
- `mxpic_router_legacy` is the old internal legacy package.
- `mxpic` should resolve to `mxpic_forge`, because `mxpic_forge` provides
`Route`.
- `mxpic` should resolve to `mxpic_forge` when that checkout is present,
because `mxpic_forge` provides the preferred `Route` backend.
## Inputs To mxpic_router
@@ -415,7 +420,7 @@ bundles:
For each link:
```text
builder._route_link(link, pin_map, Route, warnings)
builder._route_link(link, pin_map, RouteBackend, warnings)
-> route = Route(
radius=link.radius or 10,
width=link.width,
@@ -455,7 +460,7 @@ otherwise -> bend_p2p
missing method -> fallback to sbend_p2p
```
Then it calls the selected `mxpic_forge.Route` method:
Then it calls the selected route backend method:
```python
route_method(
@@ -492,7 +497,7 @@ mxpic_router/eda_loader.py
mxpic_router/builder.py
-> import Nazca
-> import mxpic_forge Route
-> import mxpic_forge Route or Nazca Interconnect fallback
-> apply technology manifest
-> load all project YAML specs
-> build basic, project, and PDK instances
@@ -510,9 +515,11 @@ mxpic_router_legacy/
definitions. The frontend route editor and Nazca build path both consume it.
- Keep PDK component metadata YAML beside its GDS files. The router needs that
metadata to recreate pins after `nd.load_gds`.
- Avoid reintroducing an internal `mxpic` package inside this repo. The name
`mxpic` must continue to resolve to `mxpic_forge`.
- Avoid reintroducing an internal `mxpic` package inside this repo. When the
forge checkout is present, the name `mxpic` must continue to resolve to
`mxpic_forge`.
- When adding a new routing family or xsection, update `technology.yml` first,
then verify that `mxpic_forge.Route` supports the required route method.
then verify that the selected route backend supports the required route
method.
- When adding a new component source, make sure it eventually contributes pins
to `pin_map`; otherwise bundle links can load but cannot route.