PhaseLockk

It's not that there is zero applicable knowledge transfer, but there are definitely some fundamental differences between digital components and analog power devices, in particular.

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.

That's what all those citations are for.

He was saying that the III of C major is the V of A minor, and so if you are planning to play in A minor using a set of chords pulled from C major, you may want to add a III alongside the iii.

The skills needed to create a chip and the skills needed to create chip design software are fundamentally different. Of all the engineers I've met who work on the physical implementation and timing closure of digital chips, only a very limited number would have any hope of creating some sort of place and route tool, and it would be rudimentary and inefficient. They are not expert programmers.

Mario Kart on Wii was released in 2008, when the oldest of Gen-Z would have been 11 years old. I'm pretty sure that's too young to be setting design trends.

I have no idea if there are systems on a submarine that might experience extreme temperatures. But for the hull, since it is constantly surrounded by liquid water, I would expect that it does not regularly experience temperatures less than ~0C. Maybe there's a concern when surfacing in the arctic? That said she obviously shouldn't have faked data whether it was stupid or not.

Maybe I can try to explain the parent comment's point a different way. When saying that rust works on types and not on arbitrary specifications, I think he is saying that rust is more limited than languages that support arbitrary specifications. However, by making this tradeoff it achieves a reasonable degree of safety without incurring a ton of overhead.

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.

In the original naming scheme, 2nm would be the length of the transistor gate, which is the smallest feature on the device, not a dimension of the whole transistor. It's not meaningful to compare 2nm to the area numbers given above.

Exactly this. It may be useful for OP to consider what the hypothetical opposite of significant digits would be: insignificant digits, ie. digits that tell you nothing. A leading zero can be omitted from a number without any loss of information. A trailing zero, when correctly used in a position that is not below the tolerance, gives you significant information. On the other hand, if you start combine numbers with different tolerances, but do not truncate the result, you will have a bunch of trailing digits that are meaningless in practice because they are below the combined tolerance.

Conceptually HDL is actually very similar to those cases, but with an important difference: simulated time. In an HDL simulator, the simulator starts executing by running code designated to run at time 0 (in Verilog, this is specified using an "initial" block).

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!

Yes. A typical SoC is assembled using thousands of lines of TCL to drive the various EDA tools that are involved in the design process.

A typical way to handle this in a functional language would be to create a datatype with a name like "PositiveInt", which just contains an Int inside it. However, in a language like OCaml, you can make it so that users of this type cannot directly create it, and instead must use a function like "makePosInt", which would check that its argument is positive, then give you back a value of type PositiveInt containing your data.

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

"Is there any evidence that tweets have meaning? I could easily imagine a world where posters fool themselves into thinking the words they wrote contained their intentions, while readers fooled themselves into thinking they had uncovered those intentions."

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.