"nextpnr.h" is no longer the god header. Important improvements:
- Functions in log.h can be used without including
BaseCtx/Arch/Context. This means that log_X functions can be called
without included "nextpnr.h"
- NPNR_ASSERT can be used without including "nextpnr.h" by including
"nextpnr_assertions.h". This allows NPNR_ASSERT to be used safely in
any header file.
- Types defined in "archdefs.h" are now available without including
BaseCtx/Arch/Context. This means that utility classes that will be
used inside of BaseCtx/Arch/Context can be defined safely in a
self-contained header.
Signed-off-by: Keith Rothman <537074+litghost@users.noreply.github.com>
This API was simply an attractive nuisance as no code was ever developed
to actually process timing constraints (other than clock constraints
which use a different API).
While I do want to consider basic false path support, among other
things, in the near future; I plan for this to use a new API that
doesn't add complexity to the BaseCtx/Context monstrosity and that is
easier to use on the timing analysis side.
Signed-off-by: gatecat <gatecat@ds0.me>
This replaces the arch-specific DelayInfo structure with new DelayPair
(min/max only) and DelayQuad (min/max for both rise and fall) structures
that form part of common code.
This further reduces the amount of arch-specific code; and also provides
useful data structures for timing analysis which will need to delay
with pairs/quads of delays as it is improved.
While there may be a small performance cost to arches that didn't
separate the rise/fall cases (arches that aren't currently separating
the min/max cases just need to be fixed...) in DelayInfo, my expectation
is that inlining will mean this doesn't make much difference.
Signed-off-by: gatecat <gatecat@ds0.me>
This replaces getNetinfoSinkWire with 3 new functions for different use
cases.
At the moment all existing code has been moved to getNetinfoSinkWire
with phys_idx=0 so the build doesn't break; but this won't yet function
properly with more than one sink. But it provides a base on which to
work on refactoring the routers to support this case.
Signed-off-by: gatecat <gatecat@ds0.me>
No arches ever actually used this to implement a Cell->Bel pin mapping,
and in practice if any did try they would inevitably hit bitrot.
This field had limited use in practice as it is necessary to also
support cases where one cell pin maps to more than one bel pin. Removing
this old field is the first step towards developing a new API for this.
Signed-off-by: gatecat <gatecat@ds0.me>
Single argument constructors will silently convert to that type. This
is typically not the right thing to do. For example, the nexus and
ice40 arch_pybindings.h files were incorrectly parsing bel name strings,
etc.
Signed-off-by: Keith Rothman <537074+litghost@users.noreply.github.com>
This is a complete implementation of IdStringList for ECP5; excluding
the GUI (which you will have to disable for it to build).
Signed-off-by: D. Shah <dave@ds0.me>
This uses the new IdStringList API to store bel names for the ECP5. Note
that other arches and the GUI do not yet build with this
proof-of-concept patch.
getBelByName still uses the old implementation and could be more
efficiently implemented with further development.
Signed-off-by: D. Shah <dave@ds0.me>
This involves very few changes, all typical to WASM ports:
* WASM doesn't currently support threads or atomics so those are
disabled.
* WASM doesn't currently support exceptions so the exception
machinery is stubbed out.
* WASM doesn't (and can't) have mmap(), so an emulation library is
used. That library currently doesn't support MAP_SHARED flags,
so MAP_PRIVATE is used instead.
There is also an update to bring ECP5 bbasm CMake rules to parity
with iCE40 ones, since although it is possible to embed chipdb into
nextpnr on WASM, a 200 MB WASM file has very few practical uses.
The README is not updated and there is no included toolchain file
because at the moment it's not possible to build nextpnr with
upstream boost and wasi-libc. Boost requires a patch (merged, will
be available in boost 1.74.0), wasi-libc requires a few unmerged
patches.
