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.
This uses a new data structure for net.users that allows gaps, so
removing a port from a net is no longer an O(n) operation on the number
of users the net has.
Signed-off-by: gatecat <gatecat@ds0.me>
This makes predictDelay be based on an arbitrary belpin pair rather
than a arc of a net based on cell placement. This way 'what-if'
decisions can be evaluated without actually changing placement;
potentially useful for parallel placement.
A new helper predictArcDelay behaves like the old predictDelay to
minimise the impact on existing passes; only arches need be updated.
Signed-off-by: gatecat <gatecat@ds0.me>
"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 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>
