If the chipdb is not found, the Setup() call throws, but GTest still calls
TearDown, which then stumbles over the uninitialized pointer.
This makes the tests fail without valgrind errors or segfaults at least.
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.