From 52efa4d9825d347afc1e2a0a27c8ee58ff43702a Mon Sep 17 00:00:00 2001 From: Vegard Storheil Eriksen Date: Wed, 17 Apr 2024 01:08:41 +0200 Subject: [PATCH 01/10] RFC #66: Simulation time --- text/0066-simulation-time.md | 119 +++++++++++++++++++++++++++++++++++ 1 file changed, 119 insertions(+) create mode 100644 text/0066-simulation-time.md diff --git a/text/0066-simulation-time.md b/text/0066-simulation-time.md new file mode 100644 index 0000000..e675277 --- /dev/null +++ b/text/0066-simulation-time.md @@ -0,0 +1,119 @@ +- Start Date: (fill in with date at which the RFC is merged, YYYY-MM-DD) +- RFC PR: [amaranth-lang/rfcs#66](https://github.com/amaranth-lang/rfcs/pull/66) +- Amaranth Issue: [amaranth-lang/amaranth#0000](https://github.com/amaranth-lang/amaranth/issues/0000) + +# Simulation time + +## Summary +[summary]: #summary + +Add a type for representing time durations and simulator methods to query the elapsed time. + +## Motivation +[motivation]: #motivation + +In [RFC #36](0036-async-testbench-functions.md), there were a plan to introduce a `.time()` method to query the current simulation time, but it got deferred due to the lack of a suitable return type. + +Internally simulation time is an integer number of femtoseconds, but exposing that directly is not ergonomic and making it a `float` of seconds sacrifices precision the longer a simulation runs. + +Also, to quote @whitequark: Time is not a number. + +## Guide- and reference-level explanation +[guide-level-explanation]: #guide-level-explanation + +A new type `amaranth.sim.Period` is introduced. +It is immutable, has no public constructor and is instead constructed through the following classmethods: +- `.s(duration: numbers.Real)` +- `.ms(duration: numbers.Real)` +- `.us(duration: numbers.Real)` +- `.ns(duration: numbers.Real)` +- `.ps(duration: numbers.Real)` +- `.fs(duration: numbers.Real)` +- `.Hz(frequency: numbers.Real)` +- `.kHz(frequency: numbers.Real)` +- `.MHz(frequency: numbers.Real)` +- `.GHz(frequency: numbers.Real)` + - The argument will be scaled according to the SI prefix on the method and the `duration` or reciprocal of `frequency` then used to calculate the closest integer femtosecond representation. + +To convert it back to a number, the following properties are available: +- `.seconds -> fractions.Fraction` +- `.milliseconds -> fractions.Fraction` +- `.microseconds -> fractions.Fraction` +- `.nanoseconds -> fractions.Fraction` +- `.picoseconds -> fractions.Fraction` +- `.femtoseconds -> int` + +The following operators are defined: +- `.__lt__(other: Period) -> bool` +- `.__le__(other: Period) -> bool` +- `.__eq__(other: Period) -> bool` +- `.__ne__(other: Period) -> bool` +- `.__gt__(other: Period) -> bool` +- `.__ge__(other: Period) -> bool` +- `.__hash__() -> int` +- `.__bool__() -> bool` +- `.__neg__() -> Period` +- `.__pos__() -> Period` +- `.__abs__() -> Period` +- `.__add__(other: Period) -> Period` +- `.__sub__(other: Period) -> Period` +- `.__mul__(other: numbers.Real) -> Period` +- `.__rmul__(other: numbers.Real) -> Period` +- `.__truediv__(other: numbers.Real) -> Period` +- `.__truediv__(other: Period) -> fractions.Fraction` +- `.__floordiv__(other: Period) -> int` +- `.__mod__(other: Period) -> Period` + - Operators on `Period`s are performed on the underlying femtosecond values. + - Operators involving `numbers.Real` operands have the result rounded back to the closest integer femtosecond representation. + - Operators given unsupported operand combinations will return `NotImplemented`. + +`Simulator` and `SimulatorContext` both have a `.time() -> Period` method added that returns the elapsed time since start of simulation. + +The methods that currently take seconds as a `float` are updated to take a `Period`: +- `.add_clock()` +- `.delay()` + +The ability to pass seconds as a `float` is deprecated and removed in a future Amaranth version. + +## Drawbacks +[drawbacks]: #drawbacks + +- Deprecating being able to pass seconds as a `float` creates churn. + +## Rationale and alternatives +[rationale-and-alternatives]: #rationale-and-alternatives + +- `.add_clock()` is usually passed the reciprocal of a frequency, so being able to construct a `Period` from a frequency instead of a duration is useful. + - We could add a separate `Frequency` type, but in practice it would likely almost exclusively be used to calculate the reciprocal `Period`. + +- Accepting a `numbers.Real` when we're converting from a number lets us pass in any standard suitable number type. + +- When converting to a number, `fractions.Fraction` is a standard `numbers.Real` type that is guaranteed to represent any possible value exactly, and is convertible to `int` or `float`. + - Returning `int` would force a potentially undesirable truncation/rounding upon the user. + - Returning `float` would lose precision when the number of femtoseconds are larger than the significand. + - `decimal.Decimal` is decimal floating point and thus has the same issue as `float`. + - `.femtoseconds` returns `int` because that's a perfect representation and returning a fraction with a denominator of 1 adds no value. + +- The supported set of operators are the ones that have meaningful and useful semantics: + - Comparing, adding and subtracting time periods makes sense. + - Multiplying a time period with or dividing it by a real number scales the time period. + - Dividing time periods gives the ratio between them. + - Modulo of time periods is the remainder and thus still a time period. + Potentially useful to calculate the phase offset between a timestamp and a clock period. + - Reflected operators that only accept `Period` operands are redundant and omitted. + +## Prior art +[prior-art]: #prior-art + +None. + +## Unresolved questions +[unresolved-questions]: #unresolved-questions + +- The usual bikeshedding. + - Case, e.g. `.MHz` vs `.mhz`. + +## Future possibilities +[future-possibilities]: #future-possibilities + +None. From dbb347fa251ea526c25b06e59a50b6fb84bfad03 Mon Sep 17 00:00:00 2001 From: Vegard Storheil Eriksen Date: Fri, 31 May 2024 15:49:24 +0900 Subject: [PATCH 02/10] RFC #66: Expand scope to also cover platform code dealing with clock constraints. --- text/0066-simulation-time.md | 27 ++++++++++++++++++++------- 1 file changed, 20 insertions(+), 7 deletions(-) diff --git a/text/0066-simulation-time.md b/text/0066-simulation-time.md index e675277..3ca048f 100644 --- a/text/0066-simulation-time.md +++ b/text/0066-simulation-time.md @@ -7,7 +7,7 @@ ## Summary [summary]: #summary -Add a type for representing time durations and simulator methods to query the elapsed time. +Add a type for representing time durations (including clock periods) and simulator methods to query the elapsed time. ## Motivation [motivation]: #motivation @@ -21,7 +21,7 @@ Also, to quote @whitequark: Time is not a number. ## Guide- and reference-level explanation [guide-level-explanation]: #guide-level-explanation -A new type `amaranth.sim.Period` is introduced. +A new type `Period` is introduced. It is immutable, has no public constructor and is instead constructed through the following classmethods: - `.s(duration: numbers.Real)` - `.ms(duration: numbers.Real)` @@ -69,16 +69,25 @@ The following operators are defined: `Simulator` and `SimulatorContext` both have a `.time() -> Period` method added that returns the elapsed time since start of simulation. -The methods that currently take seconds as a `float` are updated to take a `Period`: -- `.add_clock()` -- `.delay()` +These methods that has a `period` argument currently taking seconds as a `float` are updated to take a `Period`: +- `Simulator.add_clock()` +- `SimulatorContext.delay()` + +These methods that has a `frequency` argument currently taking Hz as a `float` are updated to take a `Period`: +- `ResourceManager.add_clock_constraint()` +- `Clock.__init__()` + +The ability to pass seconds or Hz directly as a `float` is deprecated and removed in a future Amaranth version. + +The `Clock.period` property is updated to return a `Period` and the `Clock.frequency` property is deprecated. + +Consequently, `Platform.default_clk_frequency()` is also deprecated and replaced with a new method `Platform.default_clk_period() -> Period`. -The ability to pass seconds as a `float` is deprecated and removed in a future Amaranth version. ## Drawbacks [drawbacks]: #drawbacks -- Deprecating being able to pass seconds as a `float` creates churn. +- Deprecating being able to pass seconds or Hz directly as a `float` creates churn. ## Rationale and alternatives [rationale-and-alternatives]: #rationale-and-alternatives @@ -110,9 +119,13 @@ None. ## Unresolved questions [unresolved-questions]: #unresolved-questions +- With the scope of `Period` extended beyond simulation, where do we put it? + - The usual bikeshedding. - Case, e.g. `.MHz` vs `.mhz`. +- Should `Period` also have properties to return the reciprocal frequency? + ## Future possibilities [future-possibilities]: #future-possibilities From eac6b9f6bb54e331c86280905782da5fc24344f7 Mon Sep 17 00:00:00 2001 From: Vegard Storheil Eriksen Date: Mon, 8 Jul 2024 10:24:29 +0200 Subject: [PATCH 03/10] RFC #66: Update according to feedback --- text/0066-simulation-time.md | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/text/0066-simulation-time.md b/text/0066-simulation-time.md index 3ca048f..13b04c1 100644 --- a/text/0066-simulation-time.md +++ b/text/0066-simulation-time.md @@ -43,6 +43,13 @@ To convert it back to a number, the following properties are available: - `.picoseconds -> fractions.Fraction` - `.femtoseconds -> int` +To calculate the reciprocal frequency, the following properties are available: +- `.hertz -> fractions.Fraction` +- `.kilohertz -> fractions.Fraction` +- `.megahertz -> fractions.Fraction` +- `.gigahertz -> fractions.Fraction` + - Accessing these properties when the period is zero will raise `ZeroDivisionError`. + The following operators are defined: - `.__lt__(other: Period) -> bool` - `.__le__(other: Period) -> bool` @@ -67,7 +74,7 @@ The following operators are defined: - Operators involving `numbers.Real` operands have the result rounded back to the closest integer femtosecond representation. - Operators given unsupported operand combinations will return `NotImplemented`. -`Simulator` and `SimulatorContext` both have a `.time() -> Period` method added that returns the elapsed time since start of simulation. +`SimulatorContext` have an `.elapsed_time() -> Period` method added that returns the elapsed time since start of simulation. These methods that has a `period` argument currently taking seconds as a `float` are updated to take a `Period`: - `Simulator.add_clock()` @@ -111,6 +118,8 @@ Consequently, `Platform.default_clk_frequency()` is also deprecated and replaced Potentially useful to calculate the phase offset between a timestamp and a clock period. - Reflected operators that only accept `Period` operands are redundant and omitted. +- `.elapsed_time()` is only available from within a testbench/process, where it is well defined. + ## Prior art [prior-art]: #prior-art From e0321e0681b37b69ea66a91dcb46704b4f46740b Mon Sep 17 00:00:00 2001 From: Vegard Storheil Eriksen Date: Mon, 22 Jul 2024 16:49:00 +0200 Subject: [PATCH 04/10] RFC #66: Change way of construction --- text/0066-simulation-time.md | 39 ++++++++++++++++++++++-------------- 1 file changed, 24 insertions(+), 15 deletions(-) diff --git a/text/0066-simulation-time.md b/text/0066-simulation-time.md index 13b04c1..6c91024 100644 --- a/text/0066-simulation-time.md +++ b/text/0066-simulation-time.md @@ -22,18 +22,22 @@ Also, to quote @whitequark: Time is not a number. [guide-level-explanation]: #guide-level-explanation A new type `Period` is introduced. -It is immutable, has no public constructor and is instead constructed through the following classmethods: -- `.s(duration: numbers.Real)` -- `.ms(duration: numbers.Real)` -- `.us(duration: numbers.Real)` -- `.ns(duration: numbers.Real)` -- `.ps(duration: numbers.Real)` -- `.fs(duration: numbers.Real)` -- `.Hz(frequency: numbers.Real)` -- `.kHz(frequency: numbers.Real)` -- `.MHz(frequency: numbers.Real)` -- `.GHz(frequency: numbers.Real)` - - The argument will be scaled according to the SI prefix on the method and the `duration` or reciprocal of `frequency` then used to calculate the closest integer femtosecond representation. +It is immutable and has a constructor accepting at most one named argument, giving the following valid forms of construction: +- `Period()` + - Constructs a zero period. +- `Period(seconds: numbers.Real)` +- `Period(milliseconds: numbers.Real)` +- `Period(microseconds: numbers.Real)` +- `Period(nanoseconds: numbers.Real)` +- `Period(picoseconds: numbers.Real)` +- `Period(femtoseconds: numbers.Real)` + - The argument will be scaled according to its SI prefix and used to calculate the closest integer femtosecond representation. +- `Period(hertz: numbers.Real)` +- `Period(kilohertz: numbers.Real)` +- `Period(megahertz: numbers.Real)` +- `Period(gigahertz: numbers.Real)` + - The argument will be scaled according to its SI prefix and its reciprocal used to calculate the closest integer femtosecond representation. + A value of zero will raise `ZeroDivisionError`. To convert it back to a number, the following properties are available: - `.seconds -> fractions.Fraction` @@ -120,6 +124,9 @@ Consequently, `Platform.default_clk_frequency()` is also deprecated and replaced - `.elapsed_time()` is only available from within a testbench/process, where it is well defined. +- Instead of named constructor arguments, we could use a classmethod for each SI prefix. + This was proposed in an earlier revision of this RFC. + ## Prior art [prior-art]: #prior-art @@ -130,10 +137,12 @@ None. - With the scope of `Period` extended beyond simulation, where do we put it? -- The usual bikeshedding. - - Case, e.g. `.MHz` vs `.mhz`. +- Should we use shorter argument/property names like `MHz` instead of (or an alias in addition to) `megahertz`? + +- Should we disallow passing a negative frequency or accessing a frequency property on a negative period? -- Should `Period` also have properties to return the reciprocal frequency? +- We could allow passing multiple constructor arguments and add them together -- should we? + - Probably not. Limited usefulness for durations and nonsensical for frequencies. ## Future possibilities [future-possibilities]: #future-possibilities From 6f287a19d7cc351f8a27f25c62a5c44c2f785940 Mon Sep 17 00:00:00 2001 From: Vegard Storheil Eriksen Date: Tue, 23 Jul 2024 23:00:59 +0200 Subject: [PATCH 05/10] RFC #66: Get rid of fractions. --- text/0066-simulation-time.md | 31 +++++++++++++++---------------- 1 file changed, 15 insertions(+), 16 deletions(-) diff --git a/text/0066-simulation-time.md b/text/0066-simulation-time.md index 6c91024..061e7e1 100644 --- a/text/0066-simulation-time.md +++ b/text/0066-simulation-time.md @@ -40,18 +40,18 @@ It is immutable and has a constructor accepting at most one named argument, givi A value of zero will raise `ZeroDivisionError`. To convert it back to a number, the following properties are available: -- `.seconds -> fractions.Fraction` -- `.milliseconds -> fractions.Fraction` -- `.microseconds -> fractions.Fraction` -- `.nanoseconds -> fractions.Fraction` -- `.picoseconds -> fractions.Fraction` +- `.seconds -> float` +- `.milliseconds -> float` +- `.microseconds -> float` +- `.nanoseconds -> float` +- `.picoseconds -> float` - `.femtoseconds -> int` To calculate the reciprocal frequency, the following properties are available: -- `.hertz -> fractions.Fraction` -- `.kilohertz -> fractions.Fraction` -- `.megahertz -> fractions.Fraction` -- `.gigahertz -> fractions.Fraction` +- `.hertz -> float` +- `.kilohertz -> float` +- `.megahertz -> float` +- `.gigahertz -> float` - Accessing these properties when the period is zero will raise `ZeroDivisionError`. The following operators are defined: @@ -71,7 +71,7 @@ The following operators are defined: - `.__mul__(other: numbers.Real) -> Period` - `.__rmul__(other: numbers.Real) -> Period` - `.__truediv__(other: numbers.Real) -> Period` -- `.__truediv__(other: Period) -> fractions.Fraction` +- `.__truediv__(other: Period) -> float` - `.__floordiv__(other: Period) -> int` - `.__mod__(other: Period) -> Period` - Operators on `Period`s are performed on the underlying femtosecond values. @@ -108,12 +108,6 @@ Consequently, `Platform.default_clk_frequency()` is also deprecated and replaced - Accepting a `numbers.Real` when we're converting from a number lets us pass in any standard suitable number type. -- When converting to a number, `fractions.Fraction` is a standard `numbers.Real` type that is guaranteed to represent any possible value exactly, and is convertible to `int` or `float`. - - Returning `int` would force a potentially undesirable truncation/rounding upon the user. - - Returning `float` would lose precision when the number of femtoseconds are larger than the significand. - - `decimal.Decimal` is decimal floating point and thus has the same issue as `float`. - - `.femtoseconds` returns `int` because that's a perfect representation and returning a fraction with a denominator of 1 adds no value. - - The supported set of operators are the ones that have meaningful and useful semantics: - Comparing, adding and subtracting time periods makes sense. - Multiplying a time period with or dividing it by a real number scales the time period. @@ -127,6 +121,11 @@ Consequently, `Platform.default_clk_frequency()` is also deprecated and replaced - Instead of named constructor arguments, we could use a classmethod for each SI prefix. This was proposed in an earlier revision of this RFC. +- Instead of returning `float`, we could return `fractions.Fraction` to ensure no precision loss when the number of femtoseconds is larger than the `float` significand. + This was proposed in an earlier revision of this RFC. + - Rounding to integer femtoseconds is already lossy and a further precision loss from converting to a `float` is negligible in most real world use cases. + For any applications requiring an exact conversion of a `Period`, the `.femtoseconds` property is always exact. + ## Prior art [prior-art]: #prior-art From eab5e1f10be94a24d452520c988c5169789bc0e6 Mon Sep 17 00:00:00 2001 From: Vegard Storheil Eriksen Date: Tue, 23 Jul 2024 23:09:01 +0200 Subject: [PATCH 06/10] RFC #66: Use short argument names. --- text/0066-simulation-time.md | 25 ++++++++++--------------- 1 file changed, 10 insertions(+), 15 deletions(-) diff --git a/text/0066-simulation-time.md b/text/0066-simulation-time.md index 061e7e1..a42315a 100644 --- a/text/0066-simulation-time.md +++ b/text/0066-simulation-time.md @@ -25,17 +25,17 @@ A new type `Period` is introduced. It is immutable and has a constructor accepting at most one named argument, giving the following valid forms of construction: - `Period()` - Constructs a zero period. -- `Period(seconds: numbers.Real)` -- `Period(milliseconds: numbers.Real)` -- `Period(microseconds: numbers.Real)` -- `Period(nanoseconds: numbers.Real)` -- `Period(picoseconds: numbers.Real)` -- `Period(femtoseconds: numbers.Real)` +- `Period(s: numbers.Real)` +- `Period(ms: numbers.Real)` +- `Period(us: numbers.Real)` +- `Period(ns: numbers.Real)` +- `Period(ps: numbers.Real)` +- `Period(fs: numbers.Real)` - The argument will be scaled according to its SI prefix and used to calculate the closest integer femtosecond representation. -- `Period(hertz: numbers.Real)` -- `Period(kilohertz: numbers.Real)` -- `Period(megahertz: numbers.Real)` -- `Period(gigahertz: numbers.Real)` +- `Period(Hz: numbers.Real)` +- `Period(kHz: numbers.Real)` +- `Period(MHz: numbers.Real)` +- `Period(GHz: numbers.Real)` - The argument will be scaled according to its SI prefix and its reciprocal used to calculate the closest integer femtosecond representation. A value of zero will raise `ZeroDivisionError`. @@ -136,13 +136,8 @@ None. - With the scope of `Period` extended beyond simulation, where do we put it? -- Should we use shorter argument/property names like `MHz` instead of (or an alias in addition to) `megahertz`? - - Should we disallow passing a negative frequency or accessing a frequency property on a negative period? -- We could allow passing multiple constructor arguments and add them together -- should we? - - Probably not. Limited usefulness for durations and nonsensical for frequencies. - ## Future possibilities [future-possibilities]: #future-possibilities From 1b66446a125e46c0330ee6acd481f41ca24bc187 Mon Sep 17 00:00:00 2001 From: Vegard Storheil Eriksen Date: Tue, 23 Jul 2024 23:09:31 +0200 Subject: [PATCH 07/10] RFC #66: Namespace decided. --- text/0066-simulation-time.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/text/0066-simulation-time.md b/text/0066-simulation-time.md index a42315a..550a874 100644 --- a/text/0066-simulation-time.md +++ b/text/0066-simulation-time.md @@ -22,6 +22,7 @@ Also, to quote @whitequark: Time is not a number. [guide-level-explanation]: #guide-level-explanation A new type `Period` is introduced. +It is exported from `amaranth.hdl` and also re-exported from `amaranth.sim`. It is immutable and has a constructor accepting at most one named argument, giving the following valid forms of construction: - `Period()` - Constructs a zero period. @@ -134,8 +135,6 @@ None. ## Unresolved questions [unresolved-questions]: #unresolved-questions -- With the scope of `Period` extended beyond simulation, where do we put it? - - Should we disallow passing a negative frequency or accessing a frequency property on a negative period? ## Future possibilities From 5b05fe893b0397ae4a6e6f1615302271c3f43757 Mon Sep 17 00:00:00 2001 From: Vegard Storheil Eriksen Date: Tue, 23 Jul 2024 23:13:09 +0200 Subject: [PATCH 08/10] RFC #66: Disallow negative frequencies. --- text/0066-simulation-time.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/text/0066-simulation-time.md b/text/0066-simulation-time.md index 550a874..0ebc146 100644 --- a/text/0066-simulation-time.md +++ b/text/0066-simulation-time.md @@ -38,7 +38,8 @@ It is immutable and has a constructor accepting at most one named argument, givi - `Period(MHz: numbers.Real)` - `Period(GHz: numbers.Real)` - The argument will be scaled according to its SI prefix and its reciprocal used to calculate the closest integer femtosecond representation. - A value of zero will raise `ZeroDivisionError`. + - A value of zero will raise `ZeroDivisionError`. + - A negative value will raise `ValueError`. To convert it back to a number, the following properties are available: - `.seconds -> float` @@ -54,6 +55,7 @@ To calculate the reciprocal frequency, the following properties are available: - `.megahertz -> float` - `.gigahertz -> float` - Accessing these properties when the period is zero will raise `ZeroDivisionError`. + - Accessing these properties when the period is negative will raise `ValueError`. The following operators are defined: - `.__lt__(other: Period) -> bool` @@ -135,7 +137,7 @@ None. ## Unresolved questions [unresolved-questions]: #unresolved-questions -- Should we disallow passing a negative frequency or accessing a frequency property on a negative period? +None. ## Future possibilities [future-possibilities]: #future-possibilities From d6bf093ff120f03b1ec7a5c6d9f0d35198afeb52 Mon Sep 17 00:00:00 2001 From: Vegard Storheil Eriksen Date: Tue, 23 Jul 2024 23:35:07 +0200 Subject: [PATCH 09/10] RFC #66: Add string formatting. --- text/0066-simulation-time.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/text/0066-simulation-time.md b/text/0066-simulation-time.md index 0ebc146..7a765f3 100644 --- a/text/0066-simulation-time.md +++ b/text/0066-simulation-time.md @@ -80,6 +80,18 @@ The following operators are defined: - Operators on `Period`s are performed on the underlying femtosecond values. - Operators involving `numbers.Real` operands have the result rounded back to the closest integer femtosecond representation. - Operators given unsupported operand combinations will return `NotImplemented`. +- `.__str__() -> str` + - Equivalent to `.__format__("")` +- `.__format__(format_spec: str) -> str` + - The format specifier format is `[width][.precision][ ][unit]`. + - An invalid format specifier raises `ValueError`. + - If `width` is specified, the string is left-padded with space to at least the requested width. + - If `precision` is specified, the requested number of decimal digits will be emitted. + Otherwise, duration units will emit as many digits required for an exact result, while frequency units will defer to default `float` formatting. + - If a space is present in the format specifier, the formatted string will have a space between the number and the unit. + - `unit` can be specified as any of the argument names accepted by the constructor. + If a unit is not specified, the largest duration unit that has a nonzero integer part is used. + Formatting frequency units have the same restrictions and exception behavior as accessing frequency properties. `SimulatorContext` have an `.elapsed_time() -> Period` method added that returns the elapsed time since start of simulation. From 708951251e378fce2eebbeee955bb248d83fa81c Mon Sep 17 00:00:00 2001 From: Vegard Storheil Eriksen Date: Mon, 29 Jul 2024 21:29:35 +0200 Subject: [PATCH 10/10] RFC #66: Final touches. --- text/0066-simulation-time.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/text/0066-simulation-time.md b/text/0066-simulation-time.md index 7a765f3..c61dd13 100644 --- a/text/0066-simulation-time.md +++ b/text/0066-simulation-time.md @@ -1,6 +1,6 @@ -- Start Date: (fill in with date at which the RFC is merged, YYYY-MM-DD) +- Start Date: 2024-07-29 - RFC PR: [amaranth-lang/rfcs#66](https://github.com/amaranth-lang/rfcs/pull/66) -- Amaranth Issue: [amaranth-lang/amaranth#0000](https://github.com/amaranth-lang/amaranth/issues/0000) +- Amaranth Issue: [amaranth-lang/amaranth#0000](https://github.com/amaranth-lang/amaranth/issues/1469) # Simulation time