Their docs explain it. It’s sorta like “implicit this”. https://www.chisel-lang.org/docs/explanations/multi-clock

Thanks, so a single clock and reset is implicit, but clock2 (or more) is explicit.

Yes. There's two common types of modules with different behavior here: `Module` and `RawModule`. The former has implicit clock and reset ports. The latter has no implicit clock and reset. All design can be done with the latter, just a bit more verbosely---all clock and reset ports need to be defined and anytime a construct that needs a clock or reset is used (e.g., a register), it would need to be wrapped in a `withClock`/`withReset`/`withClockAndReset`.

There's potentially a steep learning for Chisel especially if you're not coming from a Computer Science or programming language theory background.

It feels like Chisel is the result of functional programmers looking at the state of hardware design languages and being aghast at how archaic it is. Which is probably true but the value here will be helping experienced designers with no interest in learning CS theory build better chips faster. If Chisel can do that then it will win.

In my opinion the best languages have an extremely low barrier to entry. For example, C is very simple. The JavaScript development environment and tons of examples are readily available to everyone with a web browser. Python is cross-platform, has libraries for almost anything and relatively painless interoperability.

I think this comes from the idea that running the EDA flow is like compiling software and that’s the problem, it’s not.

The EDA flow, the software that goes from verilog to manufacturable files, is electrical engineering. Sure, it’s heavily automated, but it’s not fully automated. And if you want a semi decent chip, the tools need a ton of hand holding. And if you want a great chip, get prepared to dig into all the intermediate files…

If you just want a chip, any chip, they can kinda give you that in a fully automated way.

Maybe it's like not labelling the GND net next to every gnd symbol in a schematic, or even omitting both vcc and gnd pins from ic symbols entirely, except where they are not all the same.

Implicit hidden magic is bad, but then again a schematic full of individual traces instead of busses, and 400 vcc and gnd labels can actually clutter and hide the essense of the design more than convey it.

Maybe it's like that. You can spell it all out if you want to, but if it's always the same and everyone knows it, then maybe it's just obfuscating clutter to show it if there isn't some reason to.

(btw I have no opinion on the language itself. is OO a good fit for hardware? maybe but I personally don't like it for software so I go in skeptical)

I've used SpinalHDL extensively for hobby projects, which is a close cousin of Chisel. The way it works there is by defining ClockDomain "areas" that contains logic for a particular clock/reset.

Signals can freely travel between different such areas, but unless you explicitly mark those signals as asynchronous, the Verilog code generator will fail with cross-domain clock violations. It's amazing.

Here's an example of a clock domain crossing APB bridge: https://github.com/tomverbeure/panologic-g2/blob/ulpi/spinal....

The module object takes the 2 domains as instantiation parameters: https://github.com/tomverbeure/panologic-g2/blob/9225b86011a...

Here's the area with the logic that lives in the source APB clock domain: https://github.com/tomverbeure/panologic-g2/blob/9225b86011a...

Here is the destination APB clock domain logic: https://github.com/tomverbeure/panologic-g2/blob/9225b86011a...

And this is the pulse synchronizer between them: https://github.com/tomverbeure/panologic-g2/blob/9225b86011a...

ROHD (https://intel.github.io/rohd-website/) is sort of similar to Chisel on the design side (Dart instead of Scala), plus a big focus on verification. It has explicit clock and reset (though nothing precludes automating connectivity of clocks and reset via your generation software).