[Moore] Add proper conversions between time and integer values #8900

fabianschuiki · 2025-08-29T01:05:10Z

Time values in Verilog are basically just plain 64 bit integers. This is an infinite source of frustration when trying to send time values between units with different timescales. The Moore dialect has a separate !moore.time type for this reason, allowing time values to be captured more precisely and converted to the equivalent !llhd.time.

To allow users to write #5, basically delaying execution for 5 times the local time scale value, add a moore.time_to_int and complementary moore.int_to_time operation. These allow time values to be cast from and to their equivalent integer number of femtoseconds.

Make type conversions in ImportVerilog more conservative by refusing any conversion between packed and simple bit vector types if the packed type has any nested time value. For trivial casts between an integer and a time value, use the new moore.time_to_int and moore.int_to_time operations together with a moore.mul or moore.divu of the integer value by the local timescale value.

Add unsigned and signed division operators to FVInt.

Add a bunch of constant folders to the Moore dialect and switch over to createOrFold in most conversion functions to produce already-folded IR where possible.

This now allows circt-verilog to process statements like #5 or time t = 42.

uenoku

LGTM for conversion operation stuff except for one nit about naming of time_to_int. I think canonicalization and FVInt changes are orthogonal to conversion changes and I have a few question regarding behavior of div-by-zero.

uenoku · 2025-08-29T10:53:51Z

lib/Conversion/ImportVerilog/Expressions.cpp

+  assert(exp <= 5);
+  exp = 5 - exp;
+  auto scale = static_cast<uint64_t>(context.timeScale.base.magnitude);
+  while (exp-- > 0)


TIL there is no integer version of std::pow 😄 Does slang warn if there is time literal that is out-of-range (and causes overflow here)?

Yeah 😅. I think this here is always safe, because scale is 1, 10, or 100, and exp is between 0 and 5. So this produces 1000^5 in the worst case, which fits into 52 bits.

lib/Dialect/Moore/MooreTypes.cpp

uenoku · 2025-08-29T11:09:07Z

include/circt/Dialect/Moore/MooreOps.td

  }];
 }

+def TimeToIntOp : MooreOp<"time_to_int", [Pure]> {


nit: maye time_to_logic is better name? I thought it must produce a two state value because of _int suffix.

Why is it four valued here? (e.g., I'd have assumed time would be two state valued)

Excellent point, let me rename these to contain logic. I hate that Verilog makes time values four-state, but then also tells you that any X or Z bits are treated as 0 for the purpose of delay control or delayed assignments 🤦.

From IEEE 1800-2017 § 6.11 Integer data types:

uenoku · 2025-08-29T11:11:43Z

lib/Conversion/ImportVerilog/Expressions.cpp

        value.getContext(), dstInt.getWidth(), srcPacked.getDomain());
    if (dstInt.getWidth() < srcInt.getWidth()) {
-      value = moore::TruncOp::create(builder, loc, resizedType, value);
+      value = builder.createOrFold<moore::TruncOp>(loc, resizedType, value);


Unfortunate that TruncOp::createOrFold doesn't exist yet

Yeah this does change the uniformity a bit ... I'll see about adding.

That would be very neat 💯

uenoku · 2025-08-29T11:17:55Z

include/circt/Support/FVInt.h

    return v;
  }

+  /// Compute an unsigned division.


Do you have references for these semantics? Should div-by-zero return X value?

I've added a reference to the SV spec. Good point about the div-by-zero producing X. I forgot about that. Added a test for it 👍

Cool, thanks!

jpienaar · 2025-08-29T13:15:22Z

include/circt/Dialect/Moore/MooreOps.td

  }];
 }

+def TimeToIntOp : MooreOp<"time_to_int", [Pure]> {


Why is it four valued here? (e.g., I'd have assumed time would be two state valued)

jpienaar · 2025-08-29T13:18:44Z

lib/Conversion/ImportVerilog/Expressions.cpp

        value.getContext(), dstInt.getWidth(), srcPacked.getDomain());
    if (dstInt.getWidth() < srcInt.getWidth()) {
-      value = moore::TruncOp::create(builder, loc, resizedType, value);
+      value = builder.createOrFold<moore::TruncOp>(loc, resizedType, value);


Yeah this does change the uniformity a bit ... I'll see about adding.

jpienaar · 2025-08-29T13:20:02Z

include/circt/Dialect/Moore/MooreOps.td

+  let hasFolder = 1;
+}
+
+def IntToTimeOp : MooreOp<"int_to_time", [Pure]> {


Can either of these either fail or are all inputs valid?

All inputs are valid. Sadly, time values are just unit-less integers in Verilog, so any conversion issues or unit mismatches are basically mandated by the standard 🤦‍♂️

Time values in Verilog are basically just plain 64 bit integers. This is an infinite source of frustration when trying to send time values between units with different timescales. The Moore dialect has a separate `!moore.time` type for this reason, allowing time values to be captured more precisely and converted to the equivalent `!llhd.time`. To allow users to write `#5`, basically delaying execution for 5 times the local time scale value, add a `moore.time_to_int` and complementary `moore.int_to_time` operation. These allow time values to be cast from and to their equivalent integer number of femtoseconds. Make type conversions in ImportVerilog more conservative by refusing any conversion between packed and simple bit vector types if the packed type has any nested time value. For trivial casts between an integer and a time value, use the new `moore.time_to_int` and `moore.int_to_time` operations together with a `moore.mul` or `moore.divu` of the integer value by the local timescale value. Add unsigned and signed division operators to `FVInt`. Add a bunch of constant folders to the Moore dialect and switch over to `createOrFold` in most conversion functions to produce already-folded IR where possible. This now allows circt-verilog to process statements like `#5` or `time t = 42`.

fabianschuiki requested review from jpienaar, maerhart and uenoku August 29, 2025 01:05

fabianschuiki added Moore ImportVerilog labels Aug 29, 2025

uenoku approved these changes Aug 29, 2025

View reviewed changes

jpienaar approved these changes Aug 29, 2025

View reviewed changes

fabianschuiki force-pushed the fschuiki/time-int-conversion branch from 3b63902 to f38c6fa Compare August 29, 2025 22:21

fabianschuiki merged commit f0ccbd5 into main Aug 30, 2025
7 checks passed

fabianschuiki deleted the fschuiki/time-int-conversion branch August 30, 2025 01:45

[Moore] Add proper conversions between time and integer values #8900

[Moore] Add proper conversions between time and integer values #8900

Uh oh!

Conversation

fabianschuiki commented Aug 29, 2025

Uh oh!

uenoku left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

uenoku left a comment •

edited

Loading