This is useful for certain cross-compilation workloads, and to cache
rarely changing build products.
To use this functionality, build e.g. as follows:
cmake . -B build-export -DEXPORT_BBA_FILES=../bba-files -DARCH=all
cmake --build build-export -t nextpnr-all-bba
cmake . -B build-import -DIMPORT_BBA_FILES=../bba-files -DARCH=all
cmake --build build-import
Two user-visible changes were made:
* `-DUSE_RUST` is replaced with `-DBUILD_RUST`, by analogy with
`-DBUILD_PYTHON`
* `-DCOVERAGE` was removed as it doesn't work with either modern GCC
or Clang
This removes the atomic rename for bbasm outputs because it embeds
the resulting paths into the `.cc` files in embed mode. In any case
the write should be fast enough to not be a big risk for interrupted
builds.
This was tested with Clang 19 only (gcc hasn't had a release that
supports `#embed` yet).
While it served a purpose (granting the ability to build `.bba` files
separately from the rest of nextpnr), it made things excessively
convoluted, especially around paths.
This commit removes the ability to pre-generate chip databases. As far
as I know, I was the primary user of that feature. It can be added back
if there is demand for it.
In exchange the per-family `CMakeLists.txt` files are now much easier
to understand.
Bits are 0 by default anyway, so if they are unknown (because icestorm
is too od) but we want them at 0 ... it's not much of an issue.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Technically you can enable it independently on CORE and GLOBAL
output, but this is not exposed in the classic primitive, so
we do the same as icecube2 and enable/disable it for both output
path depending on the argument
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
If a port specified as output (and thus had a $nextpnr_obuf inserted)
is undriven (const `z` or const `x`), we make sure to not enable
the output driver. Also enable pull-ups if it was requested by the user.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
We try to copy the attribute only when there is a chance for
the output driver to not be active.
Note that this can _also_ happen when a port is specified as
output but has a TBUF, which the previous code wasn't handling.
We could copy the attribute "all-the-time" but this would
mean if a user specified a `-pullup yes` in the PCF for a
permanently driven output pin, we'd be burning power for
nothing.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
When there is a constraint conflict while placing IOs, the user gets an
error message such as
ERROR: Bel 'X0/Y27/io1' of type 'SB_IO' is not valid for cell 'my_pin' of type 'SB_IO'
While this identifies the problematic cell, it does not explain why
there is a problem. Add some verbose messages to allow users to
determine where the problem is. This can result in something like
Info: Net '$PACKER_VCC_NET' for cell 'my_pin' conflicts with net 'ce' for 'ce_pin'
which provides something actionable.
Signed-off-by: Sean Anderson <seanga2@gmail.com>
I noticed this during my work reimplementing nextpnr, and it seems to be dead and wrong, or at least dead. Either way I think this is what was intended unless anyone can correct me.
