Fabian Schuiki

> @sequencer I think chirrtl can be the input to llhd, or with few firrtl transform to keep the hardware same as it original design in chisel. Maybe I can...

> I am also very impressed by your project. I think making Rust itself as LLDH frontend is too heavy.But alternatively, is it possible LLDH support import Rust func to...

> And furthermore, is it possible to use LLDH simulator as Rust lib? Not yet, but there is nothing preventing that. It's just a few tweaks in the `llhd-sim` crate.

> my understanding is llhd mainly is for hardware desciprtion, instead of simulation. It targets both. For one, it can describe the hardware itself. But also, it allows for the...

Yes this is definitely part of the goals of the CIRCT project. `circt-sim` (extension of `llhd-sim`) is what you are probably interested in (LLVM-based translation of LLHD/other CIRCT dialects to...

Indeed this would be a nice short-hand operation. Something like ` = pack as ` and ` = unpack as `. Until now I have tried to hold off with...

> Would it make sense to just define two latencies as opposed to having a bool choose between two interpretations of the same parameter? Yeah that would definitely be nice....

Sounds great! Marking this PR as a draft until this is reworked :+1:

Reworked this PR to use 100% fewer `OpaqueType`s. It now extends `FModuleLike`, `InstanceOp`, and `StrictConnectOp` to support foreign, non-FIRRTL types and just pass those values through when lowering to HW....

With #3362 landed, this PR should now be a lot simpler and more streamlined. For FIRRTL types this should be an NFC, but for non-FIRRTL types this should enable a...