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>
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 makes the difference clearer between the general arch API that
everyone must implement; and helper functions specific to one arch.
Signed-off-by: D. Shah <dave@ds0.me>
This replaces RelPtrs and a separate length field with a Rust-style
slice containing both a pointer and a length; with bounds checking
always enforced.
Thus iterating over these structures is both cleaner and safer.
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.
