Fun fact: his original concept needed 9 pins and therefore was going be forced to have a 14 pin package. A late epiphany got it down to the 8 pin version we know today.

For digital, the transistor are CMOS, optimized to be as tiny as possible, running at < 1V, and with individual devices mostly driving microamps, going up to milliamps in some particular areas of the chip.

For power, we're talking about IGBTs, optimized to handle as much power as possible with maximum efficiency, at hundreds of volts.

They are both semiconductor devices, but they are about as similar as the engine for a sports car vs. for a panamax cargo ship.

Ultimately, I think using synthesizers does entail a lot of exploratory knob turning, even if understanding the effect of different components can help guide you to the sound you are looking for.

I believe the comment that types are aligned with the syntax is meant as a contrast to other languages which include specifications written in a format substantially different from or fully removed from the implementation. This can reduce the friction of using type-based verification when compared to formal verification capable of describing an arbitrarily complicated spec.

When discussing the scalability of types, I think he is saying that because types are coupled to the implementation, and don't support non-local reasoning, it is less likely that you will run into issues with type checking as you try to compose many small components into a larger program. In contrast, my impression is that with full formal verification, it can become extremely difficult to properly verify a large system.

Regarding your comparison to C and python, I think it's clear that the parent was comparing the specific type system and borrow checker that Rust provides vs. formal verification, not making a statement about the general concept of a type system. In particular, I don't think it's reasonable to assume he was saying the existence of types provides any sort of safety. Rather, it's clear he was saying the use of a powerful type system (such as that found in Rust or Haskell) to implement a limited specification of the program functionality can provide a degree of safety.

Looking first at combinational logic: As the simulator goes through the "initial" code, it will set variables to new values. These value changes will activate event listeners throughout the code ("always @ *" or "assign" in Verilog), which represent combinational logic. So if variable "myvar" is updated, and it is an input to an adder in some other module, the always statement which updates the adder output will be triggered. Whenever a combinational event is triggered here at time 0, it is "scheduled" to be resolved at time 0 + delta, where delta just represents a time after time 0, but before time 0.000...01.

Alternatively, you can schedule events with a specific delay, such as setting up a clock signal to wait 0.5ns and then toggle. You can then setup event listeners to react to the rising edge of this clock signal ("always @ posedge" in Verilog), giving you synchronous logic.

Typically, a simulation will involve a bunch of setup a time 0, combinationally getting every variable to its initial condition. Then there will be no more events scheduled at the current simulator time, so the simulator advances until the next time it has an event scheduled (such as the clock edge at 0.5ns). That value changes from that event will likely trigger many more combinational events that will be resolved before moving onto the next clock edge.

So, all of the scheduling basically works the same as event driven javascript, the big difference from what I can tell is that events are scheduled relative to simulator time, rather than real world time, and the time doesn't advance until everything scheduled for the current time has resolved. This lets us simulate the massively concurrent nature of hardware even using a single simulator thread.

When considering how this looks in actual hardware, you can still consider clocked elements as being event driven, but it's not obvious that it makes sense to think of combinational gates that way. Still, the tools are designed to construct a circuit that gives you the same result as the event driven semantics, as long as you meet timing constraints.

I'm not a simulator expert, so I may be slightly off in my explanation, but hopefully that gives you the general idea!

I'm not too experienced with this though, so this is pretty much the extent of my knowledge on this topic.

As with all natural language, production and interpretation of poems is subjective. Poetry is just an attempt to use natural language without the constraints of prose, in order to accomplish things that are not possible with prose.

Some poets may have a goal to convey a particular idea or emotion. Others may just want to create something moves the reader. Still others may not care about the reader at all. All of these things are okay.

  report_timing -from ... -to ...

However, the problem is that it has been pushed to its absolute limit. Massive automated design flows consisting of tens to hundreds of thousands of lines of often highly unstructured tcl are present at most semiconductor companies. All of this code is written by VLSI engineers who have not much software training. These engineers take advantage of the highly dynamic nature of tcl to solve their problems quickly... and the result is often an unmaintainable mess of code. As an example, I've almost never seen anyone use tcls module system, instead its just scripts using the `source` function to load other scripts.

Since the language is not mainstream among software engineers, there is very little material on best practices, and semiconductor companies are extremely locked down meaning there is no open source tooling to speak of. So VLSI engineers continue producing spaghetti code to handle all of the implementation.

Obviously I am speaking in very broad strokes, so there may be companies out there that do it right.

https://spectrum.ieee.org/semiconductors/processors/transist...

I was taught that part of being an engineer taking a moral responsibility for the safety of your creations. I know that the field has changed quite a bit, and that people in open source come from many different backgrounds. But I think it's reasonable to hold as an ideal that there is a moral responsibility to at least make sure people using your stuff understand what they are getting into. And that such a moral responsibility would require more than disclaiming liability.

[0] https://en.wikipedia.org/wiki/Uncertainty_principle#Signal_p...