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.
In some cases, nMigen uses type() instead of isinstance() to dispatch
on types. Make sure all such uses of type() are robust; in addition,
make it clear that nMigen AST classes are not meant to be subclassed.
(Record is an exception.)
Fixes#65.
The main purpose of this rework is cleanup, to avoid specifying
the direction of input ports in an implicit, ad-hoc way using
the named ports and ports dictionaries.
While working on this I realized that output ports can be connected
to anything that is valid on LHS, so this is now supported too.