PhaseLockk

You can learn about the origin of the 555 timer from its creator in his free book here: http://www.designinganalogchips.com/

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.

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.

This may not be the level of detail you are looking for, but I found this short tutorial to be effective at explaining the basics: https://learningsynths.ableton.com/

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.

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.

I'm not that guy, but here's my interpretation: tcl is used as the embedded scripting language in the vast majority of EDA tools. In some ways it performs this job quite well, with tool companies providing functions which parse their arguments like inputs to a shell script. For example, you can call

  report_timing -from ... -to ...

When the commands have 50 optional parameters, this method of calling is convenient.

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.

There are many effects that contribute to semiconductor aging. Thermal stress and diffusion, as you and the child comment suggested, are definitely part of it. There is also electromigration, which can cause the interconnect to fail. In advanced nodes there are effects related to the magnitude of the electric field and the various material interfaceds, such as hot-carrier injection (HCI). Here's an article which gives explanation of a few aging effects:

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

Following this logic, if a popular rust crate doesn't prioritize security, it can potentially change people's risk assessment of the rust ecosystem as a whole. So this maintainer's actions could have negative effects on other rust projects with no relation to his. He may not have an obligation to do anything about it, but it's kind of "not cool".

> You could (and perhaps should) take the opinion that one should care about security, but there is no obligation (legal, financial, or moral) that requires an open source maintainer to care about anything.

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.

I'm pretty sure the effect you are discussing has to do with the uncertainty relationship inherent to the Fourier Transform [0]. This is very closely related to the Heisenberg uncertainty principle, and states you cannot simultaneously constrain time and frequency, which are the values you need to measure for position and velocity, respectively. In the context of signal processing applications, I don't think the particle nature of light is typically considered, which is why it may not be exactly correct to refer to it as the Heisenberg uncertainty principle in this context. This is a bit outside my domain though, so take it with a grain of salt.

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

If you click through to the datasheet, you can see the frequency response of each of the 5 probes. Each probe is capable of picking up signals down to low frequency, but they only have good gain around a particular frequency band. So it's not as if this is one probe that is equally good at detecting all frequencies.

To me, that appeared to simply be effective communication. Raising a potentially serious issue early rather than waiting until all options have been exhausted and giving the security lead no time to react. Had they not been able to succeed, the advance notice could help in getting other resources moving in advance of the internal or external deadline.

It seems the concern is that if a foreign power is suspicious that someone might be a spy, they can collect their DNA and run it against this database. If the spy's relatives are in the database, they will be flagged, and likely make it easy to deduce the true identity of the spy. This could then leave the spy in a compromised situation.

FancyZones looks like a godsend for those with ultrawide monitors. Not being able to effectively divide up the space was always a drawback compared with just having two normal sized monitors, this could solve that issue.

What is the problem with companies offering sales?

I can't see the image you're referring to at the moment, but I imagine the fuzziness you are seeing is due to this fact: chips perform better if the features are smaller. Because of this, manufacturers want to make chip features as small as they can without causing failures, which means that you are manufacturing things at the scale that your manufacturing precision is barely sufficient, which means that the components look ugly, but they (mostly) work.

> The company already has cut emissions substantially, at the cost of $1 billion so far. And it has an intermediate goal to cut emissions by 60% (relative to 2008 levels) by 2030.

> While 2050 might sound a long way away, ships are built to last for 20 to 30 years. That means container ships that will be in service in 2050 will be hitting the oceans in just a few years.

These quotes from the article make it seem like there needs to be some fairly drastic action in the short term which would demonstrate how serious they are. The main suggestion for "how" seems to be biofuels.

My understanding is that the original commits will eventually be cleaned up during garbage collection if there is nothing else pointing to them. Is that correct?

I had the video issue, but I disabled by selecting this option: Settings ~> Video ~> Turn off my video when joining meeting. I can still manually enable video if it's needed.

> "to sell" is most often understood to be completed transaction.

That is certainly the understanding of laymen. However, if you talk to people who work in sales, and look at their "pipelines" for creating sales leads, followup, closing, and whatever else they do, you get the sense that "selling" is actually an extensive, multi-part process. At least I think that's the view most sales professionals would have.