"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 Arch API dates from when we were first working out how to
implement placement validity checking, and in practice is little used by
the core parts of placer1/HeAP and the Arch implementation involves a
lot of duplication with isBelLocationValid.
In the short term; placement validity checking is better served by the
combination of checkBelAvail and isValidBelForCellType before placement;
followed by isBelLocationValid after placement (potentially after
moving/swapping multiple cells).
Longer term, removing this API makes things a bit cleaner for a new
validity checking API.
Signed-off-by: gatecat <gatecat@ds0.me>
This is to decouple the command line flag "--json" and enable other
frontend's.
Signed-off-by: Keith Rothman <537074+litghost@users.noreply.github.com>
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>
This is a basic implementation, without considering "M of N"
arrangements (e.g. for LUT permuation where you only want to route to 1
out of 4/6 sinks) or using a type other than IdString to identify bel
pins.
But this is also enough to start working out where in nextpnr will break
due to removing the 1:1 cell:bel pin cardinality, as a next step.
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>
This splits out the pure-virtual definition of the architecture API into
ArchAPI; leaving BaseArch to only provide default implementations (which
can now be completely opted out of by deriving from ArchAPI instead of
BaseArch).
Signed-off-by: D. Shah <dave@ds0.me>
This makes the Arch API clearer and also allows a base implementation of
functions to reduce the amount of complexity to get a basic Arch up and
running.
Currently this only implements these for functions that don't return a
range. Range-returning functions will require more work in order due to
the current 'duck typing' approach (probably a struct that contains the
range types combined with templating.)
Signed-off-by: D. Shah <dave@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>
In order to make debugging the critical path easier, add an option that
will log the location each net was defined, if known.
If the file that contains the definition is known, and is readable, also
print the part of the source HDL responsible for the signal definition.
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.
