> For my example in circuitry, signal based synchronization uses a clock, or a ready signal.
But clock is not a ready signal. The clock is just a periodical signal that keeps firing. If you squint your eyes, it is almost like an event loop performing a time.sleep(ns) before deciding to check the state. In the case of chips, the circuitry performs the next state transition after the very short delay decided by the periodical clock signal. The assumption that every pin would acquire a stable binary state before the next clock tick is a fundamental part of a chip design. Without that we'll have non-deterministic and ill-defined chip behavior.
> Oh, yeah, the simple times before everybody learned that time is a local and observer-dependent measure. Modern computers do almost none time-based at-distance synchronization.
This is a very odd response. Nothing you write here directly contradicts the parent comment and yet you seem to imply that you have a point that is the opposite of the parent comment.
You seem to be going off on a tangent without addressing the main point that chips do depend on a clock firing periodically and that clock interval determining how long the circuitry waits for its pins to achieve a stable binary state before the next state transition. That was the original point of the parent comment and that point is still valid.
> Physical events are not in fact limited to occurring at clock transitions.
You seem to be talking about "events". We are not talking about events. We are talking about the clock component of CPU chips that keeps emitting a periodical signal.
> The passage of 150ms of time is not what makes thing B clear to proceed.
It absolutely does. Except that in modern chips the time interval is in nanoseconds. Two decades ago, it used to be in microseconds.
Not trying to be snarky but a genuine question: Do you have any background in chip design and fab? What @kazinator and I are saying is not exactly surprising. These things are taught in undergrad or grad-level integrated circuit courses.
If the circuitry didn't wait those nanoseconds before the next state change, it would be making the state change based on intermediate and possibly garbage values which would make the chip behave in a non-deterministic manner.
Again, we are not talking about events or cause-and-effect. We are talking about something that is more fundamental and is baked into the design of CPU chips at the very lowest level.
> You do at least get rid of the Lovecraftian clock distribution tree that's getting problematic for current synchronous logic.
No, you don't. You make it even bigger and far more complex.
You can take any synchronous design, and refine the clock gating further and further, to the point where no part of it gets a clock transition unless it actually needs it on that cycle.
And then when you're finished, congratulations, you've made an asynchronous circuit.
Fully asynchronous design and perfect clock gating are one and the same thing.
The clock distribution and gating approaches we already have are actually a sign of progress towards asynchronous design; they're just quite coarse-grained.
Of course, it's probably not the case that a clock-gating transform of an conventional synchronous design is also the best possible solution to a problem, so there's clearly still scope for improvement. But a lot of the possible improvements are probably equally applicable, or have equivalents in, optimising clock distribution and gating in synchronous design - because that's ultimately the same thing as moving towards asynchronicity.
So talking about clock distribution issues as a problem that will just go away with asynchronous design is misleading.
> I think it has to do with distance electricity has to travel.
Correct. The chip has to be small enough that the clock can propagate everywhere within the chip within a single cycle, or problems will occur.
> If a chip is physically bigger, it takes longer to move bits inside of it.
Yes, so either you would need to delay for some cycles to ensure that the information has propagated (which will basically nullify the performance gains from cranking up your clock) or clock parts of the chip differently, but you're pretty much always limited by the slowest part of the chip (which is why every modern chip has a cache, because otherwise it would stall waiting for data).
> circuits would be more likely to work on the first try because a whole class of hardware bugs wouldn't be a thing anymore
This reminds me of 4GL hype.
I'd say it's the other way round. People have trouble learning synchronous logic design because everything happens in parallel, but it's a set of well-understood building blocks. Whereas asynchronous design is just entirely free of familiar reference points and there isn't quite the same set of standard idioms.
Yes, you get rid of setup/hold violations, but you're going to get a whole new class of problems with the addition that "timing closure" is now a moving target.
Async design in simulation is not some great hidden secret, it's just a trackless jungle. People are welcome to play with it; if you find a great way of teaching async design I'm sure we'd all like to hear about it.
> but they get exponentially more complicated as you add more signals and the logic gets deeper
Clockless designs usually use some other mechanism for marking ready signals. Many of those mechanisms compose linearly and can even interconnect better than clocked designs, because they don't need to care about clock domains.
> What is this even supposed to mean? Digital hardware design hardly takes clock speeds into consideration
You purport to correct him and then you drop this phrase, which is questionable at best and wrong at worse.
You do design something that has different clock speeds differently. (Pipelining, power consumption, delays across different parts of the circuit). This is not anything too fancy, this is digital design/IC design 101.
> Have you participated much in the overclocking community? The whole point is that every CPU chip is different and can be overclocked by different amounts, some almost not at all.
On the other hand, there is no way that you can actually determine how far a CPU can be overclocked and still maintain full functionality, so it might be best to limit overclocking to systems that will not be used for something of high financial or safety value.
The problem is that fundamentally the hardware is still analog. Digital is an abstraction on top of the underlying analog system. In the digital abstraction, a signal changes instantaneously from 1 to 0 or from 0 to 1. In the underlying analog system, the components carrying the signal have capacitance and resistance. Changing the high voltage that represents 1 to the low voltage that represents 0, or vice versa, involves discharging or charging that capacitance through that resistance, and that takes time.
This sets an upper limit on how quickly that signal at that particular point in the circuit can change digital state.
There are also other ways the analog nature of the underlying circuit leaks into the digital realm. Neighboring components that are in the digital abstraction completely isolated from each other (except through intentional connections) might be coupled by stray capacitances and inductances. This can let signals on one cause noise on the other, or the state of one could change how fast the other can change state.
When a chip is designed the designers can figure out what areas are the most vulnerable to potential analog problems. They can incorporate into their tests checks to make sure that these areas are OK when the chip is operated in spec.
The ideal scenario is that if you clock a chip fast enough to break something, the chip blatantly fails and so you find out right away, and can slow it down a bit.
The frightening scenario is a data dependent glitch, where you end up with something like if the ALU has just completed a division with a negative numerator and an odd denominator and there has just been a branch prediction miss, then the zero flag will be set incorrectly.
> A refresh rate in a digital system is global: the clock is the source of truth
I suspect you're already aware of this, but nonetheless - asynchronous digital logic (ie no clock) does exist! I've never had the chance to play with it though.
> When I told my Arduino to sleep for 51 microseconds, it was generally sleeping for either 56.2 or 61.3 microseconds. That seemed to easily be bad enough to cause lots of problems.
This is why I've never quite liked the Arduino ecosystem, the way it exists. Sure, it works and it's accessible to newcomers... but it doesn't encourage understanding the inner workings of the platform enough, which is something that is extremely valuable and accessible when you're working with simple 8-bit microcontrollers. Learning about hardware registers and clocks and cycle accuracy really isn't that scary, that's the point of using a tiny (and frankly obsolete) 8-bit platform!
But when you give people an API that takes an integer number of microseconds, and then approximates it, people are going to think they can bit bang an async serial protocol in C using it, and they will be very confused when it doesn't work (as happened here), and you end up in cargo cultish land of trying to work with bad data instead of developing an actual understanding of the hardware you're working with.
I've seen so many people thinking they need to design their bespoke board around an Arduino shield connector because the thought of just throwing on the ATMega directly scares them, even though the thing only needs 5V, GND, and crystal (if that), because what would they do outside the comfortable ecosystem? And it just makes me sad. If you're at the point you're designing your own semi complex boards and you haven't graduated from Arduino yet, you're not letting yourself grow.
(Or maybe I'm just an old millennial and I think these zoomers should be learning microcontrollers by programming in assembly like I did when I was 10 and using the PIClist delay routine generator and counting my cycles before Arduino existed, now get off my lawn? You decide :-) )
> this looks to be how almost every new tech begins
On second thought, do you think this is true? The level of detail shown in this post is fairly extraordinary for event loops just getting started.
> how can one be sure that this 20% gap is a guaranteed design advantage
I would say because the design is solid and recognizes principles of mechanical sympathy that are fundamental and unlikely to change for quite some time.
>> Exactly in the same way that nobody understand in detail how a complex modern SoC works. Again, there is no magic.
That's absolute BS. Every part of a SoC was designed by a person for a specific function. It's possible for an individual to understand - in detail - large portions of SoC circuitry. How any function of it works could be described in detail down to the transistor level by the design team if needed - without monitoring its behavior.
Why do you say that? Of course there is. It would be more accurate to say all circuitry is built out of function applications, both analog and digital. If you can write an equation for the voltage on a given trace, the circuit applies a function. If you can write a truth table for a given component, that’s a function applicator. The whole reason we can build software functions is because we build them on top of circuit functions. Saying feedback doesn’t exist because it’s just electrons is like saying people are just atoms; it ignores the structure of the system. While all electric circuits pump electrons, signal feedback is a physical reality, one that you can even see & hear first-hand in some circuits. The OP maybe forgot momentarily to think about capacitors and time-varying inputs when they claimed analog circuits don’t have a time component.
> The main point of verilog is to simulate digital logic
I disagree. A HDL, which verilog is an instance of, provides a precise description of a digital machine.
Once you have that description, many things can be done with it. For example you can simulate the machine which is to be produced.
The problem is HDL looks like an algorithm, because it is. But it’s not a precise description of a computation, it’s a description of an object.
Most people who I’ve observed program verilog badly do so because they confuse the two. Kinda like confusing giving directions with giving instructions to make a map. Directions and maps are highly related, but they’re not the same thing.
>> If bounded by the speed of light, could a planet-sized computer ever make any sense?
> No, because even at the speed of light, a trip around the earth is 133ms.
Sure you could. End-to-end latency isn't necessarily a deal breaker. There would be big design problems for sure, but there are already CPUs that have nearby circuits running at higher rates than further away circuits, with async communication in between. And there have been clock-skew tolerant designs for decades to get around speed of light problems even at ~1cm distances. It's common to use the H-tree to ensure that all clock paths are the same length from the clock source, in other words the latency is factored out by making it uniform across the die.
> I want to build a simple circuit with a few LEDs and understand completely how it works and why it was designed that way.
Once you get bored by "battery plus LED" circuits, I recommend Nibbler 4 bit CPU [1] and transistor clock [2]. They are sufficiently complex to be impressive and hone your EE skills, yet simple enough to still finish even if you're not really an EE. They also can be understood completely, there are no secrets and all design decisions are explained in the documentation.
>Perhaps you have to find a spare IO pin attached to an LED
I made a write-only UART on an ST7. Clocking worked out to 500kbit because that was the first configuration I found where I could make the mark and space bits take an equals number of cycles. I still remember thinking: why in the world is the timing for each of these instructions so different?
> I think a similar digital-vs-analog split happens in computers.
Does it? In computers, digital computation is the ideal that we try to mimic via analog circuits (or vacuum tubes, relays, or whatever). We are actually glad that we can chain two CMOS inverters and the result is that anything close to Vcc becomes Vcc, and anything close to GND becomes GND.
As far as I understand, in biology "improving signal quality" like that actually disturbs the system because you are removing an "error" that actually has a useful function somewhere else.
Or for a software analogy: Consider a program that breaks memory safety, but you can't fix it because some other part relies on that "bug". Now consider a program that doesn't just contain lots of weird quirks like that, but has grown around them and makes them an integral part.
At least that is how I imagine chemistry inside a cell as a layman.
But clock is not a ready signal. The clock is just a periodical signal that keeps firing. If you squint your eyes, it is almost like an event loop performing a time.sleep(ns) before deciding to check the state. In the case of chips, the circuitry performs the next state transition after the very short delay decided by the periodical clock signal. The assumption that every pin would acquire a stable binary state before the next clock tick is a fundamental part of a chip design. Without that we'll have non-deterministic and ill-defined chip behavior.
reply