Right now an array is expected in any _opts overrides, and if it is
actually a string (because it is passed via an environment variable,
usually), awkwardness results as each character is joined with ` `.
Fixes#130.
This is useful for two reasons:
1. nMigen can provide better error messages than the platform and
do it earlier in the build pipeline.
2. Many platforms handle diffpairs by only constraining the P pin;
the N pin is completely ignored. If this is undetected,
downstream users (human or software) can rely on this
information assuming it is correct and introduce more errors.
(Of course, this will not catch every mistake, but the most
common is a copy-paste issue, and that will handle it.)
Fixes#124.
This adds the Clock() build DSL element, and adds a resource manager
function add_clock_constraint() that takes a Pin or a Signal.
Note that not all platforms, in particular not any nextpnr platforms
at the moment, can add constraints on arbitrary signals.
Fixes#86.
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.
