Tracking #879.
The directions of signals in `Pin` make it convenient to use a pin
signature in a component, such as in:
class LEDDriver(Component):
pins: Out(Signature({"o": Out(1)}))
led_driver = LEDDriver()
connect(led_driver.pins, platform.request("led"))
The `platform.request` call, correspondingly, returns a flipped `Pin`
object.
The design decision of using split memory ports in the internal
representation (copied from Yosys) was misguided and caused no end
of misery. Remove any uses of `$memrd`/`$memwr` and lower memories
directly to a combined memory cell, currently the RTLIL one.
Amaranth bitwise negation `~` compiles to Python bitwise negation `~` in
simulation; the same holds for comparison operators such as `==`. Thus
an expression such as `~(a == b)` in simulation will compile to Python
that takes the bitwise negation of the comparison result, which will be
an actual bool.
On 3.12, the result is a `DeprecationWarning` emitted only at simulation
run-time.
When negating in simulation, coerce the value to an int. `mask` is
sufficient as we do no further arithmetic here.
This fixes the following issues:
- on Python 3.10 and earlier, storing to free variables is now handled
correctly
- on Python 3.11, `_varname_from_oparg` is now used, fixing problems
with cell variables that are also arguments
- on all supported versions, EXTENDED_ARG is now parsed, ensuring proper
handling for long functions
Fixes#792.
This is actually an existing correctness requirement (for the similar
reasons that ValueCastable.as_value() must always return the same
value every time) that for some reason wasn't respected.
See amaranth-lang/rfcs#15 and #784.
Note that this RFC breaks the existing syntax for initializing a view
with a new signal. Instances of `View(layout)` *must* be changed to
`Signal(layout)`.
The __init_subclass__ method fires on class definition rather than use.
It also has the bonus impact that no __new__ method is defined, so the
classes can be correctly detected as mix-in classes by modules such as
enum.
See amaranth-lang/rfcs#4.
This functionality was not explicitly specified in the RFC but it
falls under "anywhere an integer or an enumeration is accepted".
