The iCE40 programmers are also moved, since they're board-specific.
(It looks like iceprog isn't, but it only works with Lattice
evaluation kits.)
Fixes#80.
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.
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.
This provides an escape hatch for the case where the nMigen platform
code is not flexible enough, and a IO buffer primitive needs to be
instantiated directly.
This markedly differs from oMigen system, which would request
consecutive resources. The difference is deliberate; most resources
are singular, so it does not matter for them, and for resources where
it does matter, which pins are requested should not depend on order
of execution of `platform.request`.
This is necessary because on some platforms, like iCE40, extras
become parameters on an IO primitive, since the constraint file
format is not expressive enough for all of them.
In the simple cases, a Pin record consisting of exactly one field
is equivalent in every way to this single field. In the more complex
case however, it can be used as a record, making the code more robust
such that it works with both bidirectional and unidirectional pins.
