See #790.
This commit adds an entirely private API for describing formatting of
values that is used in the standard library, in departure from our
standing policy of not using private APIs in the standard library.
This is a temporary measure intended to get the version 0.4 released
faster, as it has been years in the making. It is expected that this
API will be made public in the version 0.5 after going through the usual
RFC process.
This commit only adds VCD lines for fields defined in `lib.data.Layout`
when using `sim.pysim`. The emitted RTLIL and Verilog remain the same.
It is expected that when `sim.cxxsim` lands, RTLIL/Verilog output will
include aliases for layout fields as well.
The value representation API also handles formatting of enumerations,
with no changes visible to the designer. The implementation of
`Signal(decoder=)` is changed as well to use the new API, with full
backwards compatibility and no public API changes.
Co-authored-by: Wanda <wanda@phinode.net>
Although `@property` is the most common case, any descriptors are now
properly supported.
The special casing of methods goes away as they work by having functions
implement the descriptor protocol. (`__get__` has some special behavior
to make this possible.)
This is some of the most cursed code I have ever written, yet it is
obviously necessary.
On Python <3.10, classes without annotations do not get an
`__annotations__` member at all, so the `getattr` on a subclass falls
back to the parent class `__annotations__`, attempting to create
signature members twice. Fix that by looking at the `__dict__` instead.
While the capability of providing signatures for components that are not
parametric is useful, most Amaranth gateware is heavily parameterized,
and the capability is not worth making most subclasses Liskov-incompatible
with the base class (where the derived class would not provide `signature`
as a class method anymore).
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 main purpose of this change is migrating glasgow from the compat
`TSTriple` (which allows 0 width) to `Pin`. This sort of change would
normally require a RFC, but `Pin` is already slated for
removal/replacement, so that was deemed to be unnecessary.
There's an actual `py_enum.member` (which we briefly overwrite our loop
index with (!)). We delete our `member`, but it's still in the
`__all__` that came from `py_enum`, so `import *` fails.
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)`.
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)`.
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".
* Reject union initialization with more than one reset value.
* Replace the reset value specified in the class definition with
the one provided during initalization instead of merging.
* Annotations like `s: unsigned(4) = 1` are recognized and
the assigned value is used as the reset value for the implicitly
created `Signal`.
* Base classes inheriting from `Struct` and `Union` without
specifying a layout are recognized.
* Classes that both inherit from a base class with a layout and
specify a layout are rejected.
Mutability of Field isn't specified by the RFC and can cause issues
if the objects stored in Layout subclasses are mutated. There isn't
any reason to do that (the subclasses themselves are mutable and
handle that correctly), so disallow it.
