Chisel 3.6 roadmap, BoringUtils and LLVM CIRCT

[Øyvind Harboe]

Will BoringUtils be supported by LLVM CIRCT by 3.6?

I think this is the missing feature, before I can test out LLVM CIRCT on my biggest project.

Cheers,

[Schuyler Eldridge]

This won't break in 3.6 (though it is currently slated to be deprecated and require use of the SFC).

That said, I just added some support to CIRCT to solve general, single-source, single-sink "wiring problems" (see: https://github.com/llvm/circt/pull/4286). This could be pretty trivially extended to support the existing `BoringUtils.bore` API.

Are you using `BoringUtils.bore` or `BoringUtils.{addSource, addSink}`?

The former is a fine API. The latter is not so great. I think I'd be fine with supporting just the former going forward.

Also, any interest in helping get this into CIRCT? 😉

Schuyler

> --
> You received this message because you are subscribed to the Google Groups "chisel-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to chisel-users...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/chisel-users/493e03dd-f461-4202-ba17-279e8519efb8n%40googlegroups.com.

[Øyvind Harboe]

On Friday, November 18, 2022 at 6:05:53 PM UTC+1 schuyler...@gmail.com wrote:

This won't break in 3.6 (though it is currently slated to be deprecated and require use of the SFC).

Good!

What is SFC?

 

That said, I just added some support to CIRCT to solve general, single-source, single-sink "wiring problems" (see: https://github.com/llvm/circt/pull/4286). This could be pretty trivially extended to support the existing `BoringUtils.bore` API.

Are you using `BoringUtils.bore` or `BoringUtils.{addSource, addSink}`?

BoringUtils.bore() exclusively.

 

The former is a fine API. The latter is not so great. I think I'd be fine with supporting just the former going forward.

Also, any interest in helping get this into CIRCT? 😉

How can I help?

Test?

[Schuyler Eldridge]

> On Nov 18, 2022, at 12:47, Øyvind Harboe <oyvind...@gmail.com> wrote:
>
> On Friday, November 18, 2022 at 6:05:53 PM UTC+1 schuyler...@gmail.com wrote:
> This won't break in 3.6 (though it is currently slated to be deprecated and require use of the SFC).
>
> Good!
>
> What is SFC?

Sorry for the jargon. "Scala-based FIRRTL Compiler" (SFC) to be contrasted with the "MLIR-based FIRRTL Compiler" (MFC) which is part of the CIRCT project.

> On Nov 18, 2022, at 12:47, Øyvind Harboe <oyvind...@gmail.com> wrote:
>
> That said, I just added some support to CIRCT to solve general, single-source, single-sink "wiring problems" (see: https://github.com/llvm/circt/pull/4286). This could be pretty trivially extended to support the existing `BoringUtils.bore` API.
>
> Are you using `BoringUtils.bore` or `BoringUtils.{addSource, addSink}`?
>
> BoringUtils.bore() exclusively.

Great!

> On Nov 18, 2022, at 12:47, Øyvind Harboe <oyvind...@gmail.com> wrote:
>
> Also, any interest in helping get this into CIRCT? 😉
>
> How can I help?
>
> Test?
>

A PR would be awesome. 😅

I've thought a bit about how this should work. The MFC does not maintain a separate annotations data structure, like the SFC. (There is no AnnotationSeq, there is no RenameMap.). All Annotations are either converted to other operations or "scattered" out as MLIR attributes during a pass, LowerAnnotations, that runs right after a FIRRTL circuit is parsed.

I just added the ability for Annotations to create "Wiring Problems" that the LowerAnnotations pass will solve as soon after it processes all Annotations. We currently use this for a SiFive-internal feature called "Grand Central" which is implicitly public as it is supported by CIRCT even though it has no Chisel API. This is used to create SystemVerilog cross-module (or hierarchical) references (XMRs) in output Verilog. To do this we do not use Annotations, but convert the source/sink pairs that the Grand Central Annotations describe to:

1. RefSendOp: the source of an XMR
2. RefResolveOp: the sink of an XMR and the location where the XMR should be placed
3. Any number of RefType ports that are drilled through the design.

We use a special RefType to box these to indicate that they are port-like and have dataflow, but are not real ports.

BoringUtils, and its SourceAnnotation and SinkAnnotation, are really just a variation of this problem.

Instead of drilling RefType ports, it drills actual ports. Additionally, BoringUtils supports single-source, multi-sink problems which the WiringProblem cannot currently handle.

There's a couple of things that need to be added:

- A change that adds information to the WiringProblem struct (https://github.com/llvm/circt/blob/1b8e612bde42950499fae4930fdce726c54cc4a8/include/circt/Dialect/FIRRTL/FIRRTLAnnotationHelper.h#L195) indicating that something is a "real port" as opposed to a "ref port" is one piece.
- A change that makes SourceAnnotation/SinkAnnotation known to CIRCT and adds resolvers to create WiringProblems from them (see: https://github.com/llvm/circt/blob/2f7ad73e385c4a0b646fca3d47912d768a26eadb/lib/Dialect/FIRRTL/Transforms/LowerAnnotations.cpp#L309).
- Updates to the Wiring Problem solver function to drill real ports.
- If multi-sink is expected to work, then the way wiring problems are constructed would need to include a key to link them together.

If you don't have bandwidth, I think this will get done eventually, i.e., BoringUtils will never be deprecated. I just can't prioritize support for it right now.

Also, if anybody else is interested in getting their feet wet with CIRCT, this is a pretty compartmentalized issue.

Schuyler

[Øyvind Harboe]

I don't have enough relevant experience to articulate such a PR in a reasonable amount of time...