* Gowin. Add I3C io buffer.
A buffer is added that can operate as a normal IOBUF in PUSH-PULL mode
or switch to open-drain IOBUF mode.
Signed-off-by: YRabbit <rabbit@yrabbit.cyou>
* Gowin. Turn a variable into a set of flags
Signed-off-by: YRabbit <rabbit@yrabbit.cyou>
---------
Signed-off-by: YRabbit <rabbit@yrabbit.cyou>
Adds output (MIPI_OBUF and MIPI_OBUF_A) and input (MIPI_IBUF) primitives
to allow the use of “real” MIPI (not emulation) ports capable of
operating in both HS and LP modes.
Signed-off-by: YRabbit <rabbit@yrabbit.cyou>
Due to the way CMake-generated Makefiles evaluate dependencies, this
calls the `.bba` generation custom command twice, which then fails as
they both use the same `.bba.new` file as an output and one of them
moves it first.
This broke builds using `make -j` but not builds using
`make -j nextpnr-himbaechel-example`.
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
Primarily, this commit makes both of them use the `BBAsm` functions
to build and compile `.bba` files.
In addition, Himbaechel targets are now aligned with the rest in
how they are configured: instead of having all uarches enabled with
all of the devices disabled (the opposite of the rest of nextpnr),
uarches must be enabled explicitly but they come with all devices
enabled (except for Xilinx, which does not have a list of devices).
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.
