Circt in Production

Andrew Lenharth

3/29/22

INTERNAL ONLY © 2020 SiFive. All Rights Reserved.

1

SiFive Circt Interest

SiFive is driven by state-of-the-art tooling and languages.

Imperative that productivity, agility, reusability, and quality be top notch.

Investments in languages and tools achieve business goals.

Current State

Circt-based FIRRTL to verilog compiler is in beta.

On track to be default toolchain for the next product release.

​

Performance

Approaching 10x old flow. Even so, some designs are 5 minutes or more.

No longer limiting factor – Amdahl’s law.

• Chisel execution and simulation speed are the main culprits

Memory usage about 10x lower, which turns out to be more critical then runtime!

• CI was memory limited, not cpu limited

Overall faster simulation time and simulation compilation time.

• But not enough. Tension supporting different tools and suboptimal emission.

Retrospective in 3 parts

Initial release goals

Philosophy failure

Issues of semantics

​

Goals as Presented 16 months ago

1. ✅Fast end-to-end FIRRTL compilation
1. Fast verilog emission
2. Fast FIRRTL transformations
2. ✅Improved verilog readability and style
3. ✅Vendor, tool, and language feature selection
• End-use specific optimizations and verilog dialect (per tool, per user)
4. ✅Shared RTL optimization and Verilog generation platform (industry + OSS)
• Already seeing collaborations from Microsoft, Xilinx, Universities, and others
5. ✅Clean model to isolate internal passes without forking

Verilog Emission Goals as Presented 16 months ago

• ✅Case statements
• ✅Grouping of similar statements
• ✅Improved IFs (condition rather than destination based grouping)
• 😞Structs and/or interfaces
• Can compile small cores and simulate them. High priority item for the next quarter.
• ✅Stable signal names for documentation and debug
• ✅EDA Tool specific dialect emission
• *Shakes fist in the air at yosys and verilator’s system verilog support* 😠😠😠
• ✅Mux lowering

Deployment Philosophy

Was:

Implement FIRRTL bottom-up (low FIRRTL -> high FIRRTL), integrate with chisel flow as soon as possible, progressively replace existing implementation

​

Reality:

Too much of chisel use in practice was tightly bound up in annotations (ad-hoc IR extensions).

Implementing the high FIRRTL spec was significantly less work than support all the annotations used in designs.

Semantics: What is Chisel?

Not: A verilog generator.

Closer: “Chisel is a library of special class definitions, predefined objects, and usage conventions within Scala, so when you write Chisel you are actually writing a Scala program that constructs a hardware graph.”

Let’s tweak that: “Chisel is a library of special class definitions, predefined objects, and usage conventions within Scala, so when you write Chisel you are actually writing a Scala program that constructs a hardware graph and instructions to later aspect-oriented transformations.”

​

Semantics: Consequences of Chisel Confusion

Verilog engineers expect a verilog generator.

• Perennial issues related to scala temporary object names and verilog entities.
• How much work should a Chisel compiler be doing? How much responsibility is on Chisel to Verilog transformation to ensure good synthesis or simulation?

Verification engineers expect to be able to use verilog verification constructs.

• Tension with “hardware graph”

Scala engineers expect to be able to wield the full power of Scala to do arbitrarily complex stuff.

• Moves complexity into the generator program rather than improve the expressivity of the generated target language.

Semantic Consequences for Circt deployment

Chisel in practice treats the compiler as an extension of the generator program.

• Design-supporting functionality was arbitrarily split between scala-time and compile-time.
• Lots of ad-hoc extensions to the target language (firrtl annotations).

Required output language constructs poorly (if at all) represented.

• Magic pattern match + ad-hoc extensions to get desired output.
• Direct-to-verilog emission by inspection of the chisel rather than IR emission.

Semantics: What else is in Scala but not Chisel, per-se?

System description language (or 2 or 3) built in Scala, related to Chisel.

• Implemented mostly though firrtl extensions.
• Critical information (e.g. create a device tree for a design) and needs to be directly expressible in the language and IR.

Generator Generators

• Turtles all the way down.
• Stems from a mismatch between host language parameterization and object model mismatch to target language parameterization and object model, and from execution semantics of generators.
• Host Type v.s. HW description data-structure

Circt Consequences

Could be nothing.

Not satisfying.

Improve the expressivity of the underlying target language.

SiFive Directions and Priorities

Quality - structs and array from chisel, finally. Wire density, formatting, etc.

Debugging - Investing in chisel debug flows through circt. Readability of waveforms.

Performance - not just parallelize all the things, but make sure the representations are efficient.

Representational improvements - Drop weird firrtl things early, simplify passes, better NLAs, direct representation of several ad-hoc constructs

Chisel/FIRRTL expressivity improvements - Chisel is a firrtl generator and we have years of experience with it. Turn that experience into a better generator language.

Simulation - Simulation is a bottleneck. Simulation also is a multi-faceted, multi-sourced process; we can’t just write circt-sim, though we need that too.

Modeling - SystemC models and circt-integrated representation and simulation is an increasingly important customer-ask.

Non-logic design elements - So much of a system, including parts relevant to simulation, is not expressible in verilog or the existing circt dialects. Internally, we have extensions to Chisel to specify some things, but we need a comprehensive solution.