Unless exact_depth=True is specified.
The logic introduced in this commit is idempotent: that is, if one
uses the depth of one AsyncFIFOBuffered in the constructor of another
AsyncFIFOBuffered, they will end up with the same depth. More naive
logic would result in an unbounded, quadratic growth with each such
step.
Fixes#219.
These functions were originally changed in 3ed51938, in an attempt
to make them take one cycle instead of two. However, this does not
actually work because of drawbacks of the simulator interface.
Avoid committing to any specific implementation for now, and instead
make them compat-only extensions.
Because of YosysHQ/yosys#1390, using a transparent port in AsyncFIFO,
instead of being a no-op (as the semantics of \TRANSPARENT would
require it to be in this case), results in a failure to infer BRAM.
This can be easily avoided by using a non-transparent port instead,
which produces the desirable result with Yosys. It does not affect
the semantics on Xilinx platforms, since the interaction between
the two ports in case of address collision is undefined in either
transparent (WRITE_FIRST) or non-transparent (READ_FIRST) case, and
the data out of the write port is not used at all.
Fixes#172.
This obscure functionality was likely only ever used in old MiSoC
code, and doesn't justify the added complexity. It was also not
provided (and could not be reasonably provided) in SyncFIFOBuffered,
which made its utility extremely marginal.
Such clock domains will "leak" into the enclosing scope, which is
generally undesirable. Also, this is instructive for a platform
overriding the behavior, since it provides guidance on how to
correctly instantiate platform-specific flops.
I've considered also doing this for MultiReg(), but it is very
challenging in presence of non-reset-less CDC FFs, since Yosys'
$dffsr primitive has separate set and clear inputs, and reshuffling
the reset value for those results in quite a bit of additional logic.
(That said, it might have to be done anyway, precisely because
letting Yosys generate this additional logic might prove too much
for the toolchain to cope with, and again, platform-independent
code should provide guidance to platform-specific code.)
This commit:
* moves lists of universally useful imports from `nmigen` to
`nmigen.hdl` and `nmigen.lib`, reimporting them in `nmigen`;
* replaces lots of imports from individual parts of `nmigen.hdl`
with a star import from `nmigen.hdl`;
* replaces imports in tests with what we expect downstream code
to use;
* adds some missing imports in `nmigen.formal`.
Although a dir="oe" pin is generally equivalent to dir="io" pin with
the i* signal(s) disconnected, they are not equivalent, because some
pins may not be able to support input buffers at all, either because
there are no input buffers, or because the input buffers are consumed
by some other resource.
E.g. this can happen on iCE40 when the input buffer is consumed by
a PLL.
Without this register, static hazards in the encoder could cause
multiple encoder output bits to toggle, which would be incorrectly
sampled by the 2FF synchronizer.
Reported by @Wren6991.
The current behavior was introduced in 65702719, which was a wrong
fix for an issue that was actually fixed in 12e04e4e. This commit
effectively reverts 65702719 and 1782b841.
