5.5 mm in 1.25 nanoseconds(randomascii.wordpress.com)
randomascii.wordpress.com
5.5 mm in 1.25 nanoseconds
https://randomascii.wordpress.com/2022/01/12/5-5-mm-in-1-25-nanoseconds/
121 comments
The speed of light is a useless metric when measuring propagation delay of a signal in a wire since there is load of factors that limit it much more significantly, such as the width of the conductor / capacitance / resistance, the strength of the driver, etc. Starting point: https://en.wikipedia.org/wiki/Elmore_delay
And if you are going to do anything useful (e.g. toggling the signal), the max frequency at which you can do it is even lower than the limit set by the propagation delay.
In any case, even TFA says the reason pretty explicitly: it's actually 4 pipelined stages, thus 4 clock cycles delay. Probably it was way too much power+area to drive the distance in one cycle.
And if you are going to do anything useful (e.g. toggling the signal), the max frequency at which you can do it is even lower than the limit set by the propagation delay.
In any case, even TFA says the reason pretty explicitly: it's actually 4 pipelined stages, thus 4 clock cycles delay. Probably it was way too much power+area to drive the distance in one cycle.
Random historical context (IIRC), in the early 2000s (around when the chip discussed was made) chip designers were dealing with the transition from gate/switch delays being a dominant factor to signal wire propagation delays becoming very significant. This was a side effect of the improving processes making smaller chip features.
Interesting that that was around when this shift was happening. I know things have gotten a lot crazier with modern nodes...
Anecdotally, the DEC Alpha was the first chip to move from "clock is provided at the edge of the chip" to "clock is provided in the middle of the chip", due to a desire to minimise the skew from one edge of the CPU to the other.
How true it is? Not the faintest, but maybe someone here was in a/the Alpha design team and can say yes/no.
How true it is? Not the faintest, but maybe someone here was in a/the Alpha design team and can say yes/no.
More asynchronous design?
I think it's more like a lot more detailed modeling involved during place&route, since we can no longer get away with simplifications.
There's definitely a lot more playing with clock domains too though. Run this bit at half clock, etc. But you still wouldn't want to have entirely async things within an execution unit, because bringing them back in sync costs a couple clock cycles on its own.
I do wonder how the tooling used in leading edge VLSI design rates on software quality. If the open FPGA tooling community has taught us something, it's that vendor tooling is hideously inefficient and just plain bad software. If VLSI design is on the same level (and it wouldn't be surprising if it is; in fact some FPGA tooling is done by the same companies and a similar codebase), then they might be leaving performance, design time, or both on the table just because the damn P&R and timing analysis take much longer to run than they would if the software weren't terrible. Of course I'm sure they just throw more machines at the problem for high stakes chip design, but...
There's definitely a lot more playing with clock domains too though. Run this bit at half clock, etc. But you still wouldn't want to have entirely async things within an execution unit, because bringing them back in sync costs a couple clock cycles on its own.
I do wonder how the tooling used in leading edge VLSI design rates on software quality. If the open FPGA tooling community has taught us something, it's that vendor tooling is hideously inefficient and just plain bad software. If VLSI design is on the same level (and it wouldn't be surprising if it is; in fact some FPGA tooling is done by the same companies and a similar codebase), then they might be leaving performance, design time, or both on the table just because the damn P&R and timing analysis take much longer to run than they would if the software weren't terrible. Of course I'm sure they just throw more machines at the problem for high stakes chip design, but...
> If the open FPGA tooling community has taught us something, it's that vendor tooling is hideously inefficient and just plain bad software
Just plain bad software and hilariously overengineered sure, but inefficient is a big word to throw out. I don't think any non-vendor tool has yet proven able to play in the same league, yet. It's like comparing tinycc with gcc.
Just plain bad software and hilariously overengineered sure, but inefficient is a big word to throw out. I don't think any non-vendor tool has yet proven able to play in the same league, yet. It's like comparing tinycc with gcc.
Interesting.
From what I could gather, latency in ICs is dominated by the time it takes for a voltage to build up at the sink, which is dominated by the resistances and capacitances along the way, makes sense.
At larger nodes, as far as I know the latency was mostly dominated by fan-out, which is how many inputs an output is connected to. The more inputs the larger the total gate capacitance; to compensate you can make the output transistors larger, but that adds its own delay. So if you need to fan out to a lot of inputs, you'd end up chaining stages and adding more delay.
Typical numbers for designs going for higher clocks (read: Pentium 4) would be 16 FO4 stages per clock. So of all you're doing is moving data from point A to point B on the chip, that still gives you quite a bit of leeway for adding buffer stages without having to add an extra cycle of latency.
Things have changed though, as other commenters have pointed out. These days everything is a lot more complicated, as you get to smaller nodes.
Typical numbers for designs going for higher clocks (read: Pentium 4) would be 16 FO4 stages per clock. So of all you're doing is moving data from point A to point B on the chip, that still gives you quite a bit of leeway for adding buffer stages without having to add an extra cycle of latency.
Things have changed though, as other commenters have pointed out. These days everything is a lot more complicated, as you get to smaller nodes.
Trivia: the Xbox 360 CPU design used 10 FO4, meaning that it could get less done per clock cycle than the Pentium 4. In order words, the Xbox 360 CPU was trying to beat the Pentium 4 at the clock-speed game (fewer stages per clock allows for higher frequency) but the power wall intervened and said "Nope!"
Reading from L2 requires sending down a request and then waiting for the response. This makes me realize that the actual speed is 5.5 mm in 0.625 ns because it's a two cycle delay in each direction. I'll update the article.
But, this request/response means that a ring bus seems unlikely because a unidirectional ring bus should make the sum of the request/response times identical for all CPUs, if I'm understanding correctly.
But, this request/response means that a ring bus seems unlikely because a unidirectional ring bus should make the sum of the request/response times identical for all CPUs, if I'm understanding correctly.
I was thinking bidirectional ring bus in my model; indeed if it were unidirectional you'd end up with the same result for all CPUs.
FWIW, the Cell used a bidirectional ring bus network, and it's of the same generation and happens to share technology heritage with the XCPU... (very similar PowerPC core) :-)
FWIW, the Cell used a bidirectional ring bus network, and it's of the same generation and happens to share technology heritage with the XCPU... (very similar PowerPC core) :-)
You mentioned a document with a detailed description of the internals of the Xbox 360 CPU. I don't suppose that document is available to the public?
Sorry, I've never seen a non-NDA document with full details. Some information was released but it was a bit spotty.
Speed of signal propagation though wires on modern chips is much slower than the speed of light. A bit less so on an old Xbox chips, but still a big difference.
On a modern core the delay is enough that you can't come close to reaching from side one side of a core (not to mention CPU) to another in a single cycle.
On a modern core the delay is enough that you can't come close to reaching from side one side of a core (not to mention CPU) to another in a single cycle.
Do you have a measure of this speed?
In chips because of the layers of conductors and insulators you are actually charging a capacitor, not just sending a signal down a lone wire.
Yes, a long bus is like a resistor-capacitor delay circuit. You can speed it up by using a bigger driver for more current, but that takes up more space and adds its own delay. I expect that the bus in the Xbox is split in two, with a second driver in the middle. This makes the first half faster, but the second half of the bus probably takes another clock cycle, which would explain the observed behavior.
That's how all conductors work, not just "in chips due to layers of conductors and insulators". The thing is that in most situations you just model the conductor away as a "perfect ideal wire" and everything usually just works since you don't care about these small delays and/or you have very high power. But when you enter sub-nanosecond and/or sub-mW territory...
You're always driving a waveguide that has inductance and capacitance per unit length. But when resistance is high enough you are just charging a big distributed capacitor. It's a different regime from the high-conductivity situation (which looks like a transmission line). Either picture could apply at sub-ns speeds, it depends mainly on the resistance.
But IC interconnects have a very small cross section, so for them this problem is much more pressing.
this is an interesting video (to me anyway!!) on the speed of electrons vs fields
The Big Misconception About Electricity.. https://www.youtube.com/watch?v=bHIhgxav9LY
The Big Misconception About Electricity.. https://www.youtube.com/watch?v=bHIhgxav9LY
That video is hilariously wrong, which seems to be a common theme for Veritasium lately. I can't tell if he legitimately believes what he's saying, or if he produces these seemingly-correct-but-not videos to drive up engagement and views.
His presentation is not very clear & imo the way he answers the question is not actually helpful in actually understanding what’s going on, but he is correct that current will flow in the far side almost immediately. As is made clearer in the documents he shared which contain his discussions with actual physicists, that current will be much smaller than the final current that flows all the way round the circuit, but it is there nevertheless. (In fact that current will initially flow whether or not the two halves of the flat ring are connected - if you think about it things have to work like this, because the middle of the system cannot “know” whether the far ends are connected until light has had time to get there & back. Relativity is absolute.)
Take a look at the video made by YouTuber AlphaPhoenix where he constructs the entire thing on a smaller scale and demonstrates the effect with an oscilloscope: https://www.youtube.com/watch?v=2Vrhk5OjBP8
One way of viewing what’s going on here is to consider the two sides as a pair of large dipole antennas. When the switch (or in AlphaPheonix’s case, a transistor) is turned on, a pulse of electrons is pushed down one antenna, setting up a transient wave in the electromagnetic field around it which induces a current in the opposite direction in the “receiving” antenna on the other side. This happens regardless of whether the wired are connected in a loop or not!
Physics is great.
Take a look at the video made by YouTuber AlphaPhoenix where he constructs the entire thing on a smaller scale and demonstrates the effect with an oscilloscope: https://www.youtube.com/watch?v=2Vrhk5OjBP8
One way of viewing what’s going on here is to consider the two sides as a pair of large dipole antennas. When the switch (or in AlphaPheonix’s case, a transistor) is turned on, a pulse of electrons is pushed down one antenna, setting up a transient wave in the electromagnetic field around it which induces a current in the opposite direction in the “receiving” antenna on the other side. This happens regardless of whether the wired are connected in a loop or not!
Physics is great.
I found the AlphaPhoenix video a bit disappointing because he didn't clearly explain that the capacitive interaction between both ends is also light speed limited, and very dependent on distance, i.e. the geometry of the test. Had the test been done in a big round loop, current wouldn't start flowing at the far end immediately. Otherwise you'd have made faster than light communications.
I'm also not even sure if his testing methodology is solid; he was getting a ton of common mode junk in the target measurement probes, and subtracting it out in the scope. That works in steady state, but when trying to measure fast transients like this it depends on things like probe skew and more. It's just not clean enough for me to be able to trust the results are caused by the explanation he gave. Measuring subtle phenomena like this with long transmission lines involved with a single ground referenced scope and no true differential probes... ick.
I'm also not even sure if his testing methodology is solid; he was getting a ton of common mode junk in the target measurement probes, and subtracting it out in the scope. That works in steady state, but when trying to measure fast transients like this it depends on things like probe skew and more. It's just not clean enough for me to be able to trust the results are caused by the explanation he gave. Measuring subtle phenomena like this with long transmission lines involved with a single ground referenced scope and no true differential probes... ick.
>Had the test been done in a big round loop, current wouldn't start flowing at the far end immediately. Otherwise you'd have made faster than light communications.
Yes, this is obviously the case. But it's also not the setup that was being tested.
(Apparently he's editing a part2 which contains many weird & wonderful topological arrangements.)
Honestly though, I'm not sure what your problem is here. His results match very closely what you'd expect theoretically given the experimental setup. Not only that, if you model the setup in software using a suitable electromagnetic modelling code (there are videos on YouTube of people doing this) you get exactly the same result. Common mode noise on both sides is an irrelevance - you can just subtract it away without loss of generality.
Yes, this is obviously the case. But it's also not the setup that was being tested.
(Apparently he's editing a part2 which contains many weird & wonderful topological arrangements.)
Honestly though, I'm not sure what your problem is here. His results match very closely what you'd expect theoretically given the experimental setup. Not only that, if you model the setup in software using a suitable electromagnetic modelling code (there are videos on YouTube of people doing this) you get exactly the same result. Common mode noise on both sides is an irrelevance - you can just subtract it away without loss of generality.
You can only subtract common mode noise out if it really is common mode and perfectly equal on both sides of the system. With two discrete probes, that's going to give you a lot worse common mode rejection than with a proper differential probe. He can't even have proper ground references the way he did it (most of his probe ground clips are unconnected). It's just not a good rig. Sure, it might work, and his result might be good, I just don't feel confident about it given the experimental set-up.
If you look at his scope plot, the common mode voltage is kind of a mess and much larger than the actual differential voltage. That doesn't give me a lot of confidence in the final result. I'd like to see a more controlled version of this experiment with better equipment.
Source: I've done the same thing he did, using two probes to measure a differential voltage, and I can tell you it kind of works, but not well. Especially not at higher frequencies.
If you look at his scope plot, the common mode voltage is kind of a mess and much larger than the actual differential voltage. That doesn't give me a lot of confidence in the final result. I'd like to see a more controlled version of this experiment with better equipment.
Source: I've done the same thing he did, using two probes to measure a differential voltage, and I can tell you it kind of works, but not well. Especially not at higher frequencies.
The common mode problem can be avoided by making the experiment not differential (which coincidentally saves half the wiring) but even if you do that, you still get a large influence on the result due to the coupling between the twin-lead line and ground. It's actually a pretty good demonstration why using baluns for twin-lead is necessary; only the differential mode of the line works well, because it's not actually a two-conductor line, as it's an open line it is also coupled to ground. In my experiment (with ~6 cm wire spacing, which makes relatively little difference as the impedance of the line is proportional to the log of the spacing) I found that suspending it around a meter above ground gave almost identical differential and common mode impedances. That of course rather significantly reduces the amplitude you're going to see in the experiment.
He has an upcoming part2 of the video which he listed big round loop as one of the follow-up experiments. We should just wait for that.
[deleted]
Have you read the slides cited in the description on YouTube, and found the error? There's both a theoretical argument (which I haven't followed), and lab results using a 15m (?) transmission line. Both seem to confirm the claim in the video. If they're wrong, I'd really like to understand where the error is.
E&M can be a little tricky, even for experienced circuit designers.
E&M can be a little tricky, even for experienced circuit designers.
The video gives a wrong impression that most current is flowing along the Poynting vector. In fact, only a tiny amount of current is flowing directly, and the vast majority is flowing along the wires, as expected. The tiny amount flowing directly through the air is much better understood as an antenna effect, unrelated to regular current flow, and has nothing really to do with the Poynting vector.
I agree that current doesn't follow the Poynting vector. Power follows the Poynting vector. That's true for antennas and for transmission lines.
Yes, but most power is in fact following the Poynting vector along the wires, not the direct Poynting vector between the battery and the bulb, as the video misleadingly suggests (but doesn't outright claim).
> Yes, but most power is in fact following the Poynting vector along the wires.
Only in the steady state does the Poynting vector follow the wires all around the loop (a point made in the original video.) In the period of interest - well before the EM waves launched by closing the switch have reached the far ends of the transmission lines - it does not, yet during this period, the load is passing a non-trivial current (and therefore dissipating power) that is determined by the voltage of the battery, the resistance of the load, and the characteristic impedances of the two transmission lines. For example, for 24 awg superconducting wire (~0.5mm in diameter) the characteristic impedance for each of the transmission lines would be a little less than 1 kΩ, so with a 12 volt battery, a 2kΩ load would be passing about 3mA and dissipating about 18mW (that is fully 50% of the current it will pass in the steady state.)
During this period, there is no energy-transferring chain of physical cause-and-effect that goes all around the wire loop, and it would, of course, upend physics if there were! In fact, during this period, it makes no difference whether the far ends of the transmission lines are open- or closed-circuit.
Only in the steady state does the Poynting vector follow the wires all around the loop (a point made in the original video.) In the period of interest - well before the EM waves launched by closing the switch have reached the far ends of the transmission lines - it does not, yet during this period, the load is passing a non-trivial current (and therefore dissipating power) that is determined by the voltage of the battery, the resistance of the load, and the characteristic impedances of the two transmission lines. For example, for 24 awg superconducting wire (~0.5mm in diameter) the characteristic impedance for each of the transmission lines would be a little less than 1 kΩ, so with a 12 volt battery, a 2kΩ load would be passing about 3mA and dissipating about 18mW (that is fully 50% of the current it will pass in the steady state.)
During this period, there is no energy-transferring chain of physical cause-and-effect that goes all around the wire loop, and it would, of course, upend physics if there were! In fact, during this period, it makes no difference whether the far ends of the transmission lines are open- or closed-circuit.
> During this period, there is no energy-transferring chain of physical cause-and-effect that goes all around the wire loop, and it would, of course, upend physics if there were!
Even before the steady state is achieved, there is an energy-transferring chain of physical cause-and-effect that is moving (at limited speed, ~c) along the wire (but not all around the wire loop yet) - this is of course the moving electric and magnetic field caused by the "chain" of electrons being pushed or pulled. Of course, that will only reach the lightbulb after ~1 second in the original experiment. At the same, time, there is a different, smaller electric field "leaking" through the air/void in a straight line from the battery to everywhere else, which will reach the lightbulb much sooner in the original configuration, and of course this is also carrying some energy.
The situation is analogous to what would happen with mechanical waves (at least qualitatively if not quantitatively) - if you were to have the same wires but a source of sound instead of the battery, and a sound detector (or a seismograph) instead of the lightbulb, you would get a pretty similar effect - the "main" sound wave would travel along the wires at the speed of sound in that medium, while some other waves would also travel through the air and ground through the much shorter straight-line distance, and register much more quickly on the seismograph. Of course, there are some significant quantitative differences - there is no sound super-conductor, so some amount of mechanical energy will always be lost along the wires; and sound travels much more slowly through air than through metal wires, so the speed difference will be less noticeable.
Even before the steady state is achieved, there is an energy-transferring chain of physical cause-and-effect that is moving (at limited speed, ~c) along the wire (but not all around the wire loop yet) - this is of course the moving electric and magnetic field caused by the "chain" of electrons being pushed or pulled. Of course, that will only reach the lightbulb after ~1 second in the original experiment. At the same, time, there is a different, smaller electric field "leaking" through the air/void in a straight line from the battery to everywhere else, which will reach the lightbulb much sooner in the original configuration, and of course this is also carrying some energy.
The situation is analogous to what would happen with mechanical waves (at least qualitatively if not quantitatively) - if you were to have the same wires but a source of sound instead of the battery, and a sound detector (or a seismograph) instead of the lightbulb, you would get a pretty similar effect - the "main" sound wave would travel along the wires at the speed of sound in that medium, while some other waves would also travel through the air and ground through the much shorter straight-line distance, and register much more quickly on the seismograph. Of course, there are some significant quantitative differences - there is no sound super-conductor, so some amount of mechanical energy will always be lost along the wires; and sound travels much more slowly through air than through metal wires, so the speed difference will be less noticeable.
> Even before the steady state is achieved, there is an energy-transferring chain of physical cause-and-effect that is moving (at limited speed, ~c) along the wire (but not all around the wire loop yet)... [my emphasis.]
Well, yes, that's one of the points being made in the original video!
> At the same, time, there is a different, smaller electric field "leaking" through the air/void in a straight line from the battery to everywhere else, which will reach the lightbulb much sooner in the original configuration, and of course this is also carrying some energy.
Well, yes, that is one of the other points being made in the original video!
And those effects are not so small as to be trivial - check out the numbers in the example I have provided.
Sound is rather different than EM, so one should be careful in arguing from analogies, even if it seems to give the correct answer. Why not just go with the very well-established EM formulae for this situation?
in your other reply (https://news.ycombinator.com/item?id=29935760) you are essentially saying of course this is all correct! - but the mere fact that this video prompted half a dozen or more videos in response (of wildly varying quality - some of them are laden with non-sequiturs about what would happen in different experiments) indicates that a nontrivial point is being made here, that seems counterintuitive for many people.
Given that you are confirming the main points of the video, it is not clear to me why you would call it "extremely misleading, if not technically wrong." In your other reply, you claim that Veritasium is deliberately obscure, but it is not clear to me that one can even make much of a case for him being accidentally less straightforward than he could have been, from this evidence.
Well, yes, that's one of the points being made in the original video!
> At the same, time, there is a different, smaller electric field "leaking" through the air/void in a straight line from the battery to everywhere else, which will reach the lightbulb much sooner in the original configuration, and of course this is also carrying some energy.
Well, yes, that is one of the other points being made in the original video!
And those effects are not so small as to be trivial - check out the numbers in the example I have provided.
Sound is rather different than EM, so one should be careful in arguing from analogies, even if it seems to give the correct answer. Why not just go with the very well-established EM formulae for this situation?
in your other reply (https://news.ycombinator.com/item?id=29935760) you are essentially saying of course this is all correct! - but the mere fact that this video prompted half a dozen or more videos in response (of wildly varying quality - some of them are laden with non-sequiturs about what would happen in different experiments) indicates that a nontrivial point is being made here, that seems counterintuitive for many people.
Given that you are confirming the main points of the video, it is not clear to me why you would call it "extremely misleading, if not technically wrong." In your other reply, you claim that Veritasium is deliberately obscure, but it is not clear to me that one can even make much of a case for him being accidentally less straightforward than he could have been, from this evidence.
I say that he is misleading because of a few points:
- he claims the chain analogy is a lie, even though it gives the exact right intuition about the effects. He also obscures the intuition by asking why the energy doesn't go back and forth if the engine pulls the chain back and forth, which is nonsense.
- he phrases everything in a way that, to me, suggests that the energy is flowing directly from producer to consumer, when in fact energy is flowing on two separate pathways - radially away from the producer, and along the wires. Energy flow doesn't change if the consumer isn't there, though he seems to me to imply that it does.
- he claims that energy flows "outside the wires" and shows diagrams of the Poynting vectors all-around the circuit, but doesn't show that energy flow quickly decreases with distance from the wires, at least for the DC case
- he claims that what's happening inside the wires (the movement of the electrons) is not that important, when in fact it is the very movement of those electrons that generates the magnetic field, and the initial moving electric field
Overall, the video very explicitly tells you that the movement of the electrons and the chain analogy are wrong and mostly irrelevant to how power is actually transmitted in an electric circuit, which is simply wrong and misleading - even though the fields are an important part, they are intrinsically connected to the movement of electrons, and the chain analogy is pretty good at showing that (a compressive wave analogy would be even closer in some ways).
It's also important to note that you are the one talking about transmission line theory - the Veritassium video doesn't, and exclusively talks about Poynting vectors as an explanation, which would make it very hard to come up with a quantitative explanation of the phenomenon.
- he claims the chain analogy is a lie, even though it gives the exact right intuition about the effects. He also obscures the intuition by asking why the energy doesn't go back and forth if the engine pulls the chain back and forth, which is nonsense.
- he phrases everything in a way that, to me, suggests that the energy is flowing directly from producer to consumer, when in fact energy is flowing on two separate pathways - radially away from the producer, and along the wires. Energy flow doesn't change if the consumer isn't there, though he seems to me to imply that it does.
- he claims that energy flows "outside the wires" and shows diagrams of the Poynting vectors all-around the circuit, but doesn't show that energy flow quickly decreases with distance from the wires, at least for the DC case
- he claims that what's happening inside the wires (the movement of the electrons) is not that important, when in fact it is the very movement of those electrons that generates the magnetic field, and the initial moving electric field
Overall, the video very explicitly tells you that the movement of the electrons and the chain analogy are wrong and mostly irrelevant to how power is actually transmitted in an electric circuit, which is simply wrong and misleading - even though the fields are an important part, they are intrinsically connected to the movement of electrons, and the chain analogy is pretty good at showing that (a compressive wave analogy would be even closer in some ways).
It's also important to note that you are the one talking about transmission line theory - the Veritassium video doesn't, and exclusively talks about Poynting vectors as an explanation, which would make it very hard to come up with a quantitative explanation of the phenomenon.
I take your point that Veritasium himself did not analyze the scenario as a transmission line, and he would probably have been clearer if he had done so. Also, in several places here, you say that you took him as saying this or that, and if that is how you (and probably others) saw it, then he could have been clearer by anticipating and explicitly addressing those concerns. In addition, it was probably a mistake to present it as an issue of whether a bulb of the sort he showed would light up, given how many people got distracted by that detail. Therefore, I accept that the video could have been clearer, but I still see no reason at all to accuse Veritasium of being deliberately misleading.
On the other hand, the thing about the chain analogy is that it is not "nonsense", as you put it, to point out that it is not the complete picture in general, it is not an "exact" intuition, and, most relevantly here, that it completely fails to explain what happens in this case in the period of interest, prior to the arrival of the reflected wave back to the origin and the establishment of a steady state. Furthermore, one can not get the correct answers - or the correct intuitions, for that matter - from any model that assumes the energy flows only where the charges are moving (this was a roadblock in understanding electromagnetism which was broken by Maxwell introducing the displacement current.)
Therefore, Veritasium had good pedagogical reasons for saying that the chain model is not accurate and for introducing the Poynting vector. As I pointed out in my previous post, your previous post consisted of a series of points in which you were saying, in effect, that Veritasium was correct, and if you want to reverse course on that now, I think you owe us an explanation of how the chain model explains what happens in the first second after the switch is turned on.
On the other hand, the thing about the chain analogy is that it is not "nonsense", as you put it, to point out that it is not the complete picture in general, it is not an "exact" intuition, and, most relevantly here, that it completely fails to explain what happens in this case in the period of interest, prior to the arrival of the reflected wave back to the origin and the establishment of a steady state. Furthermore, one can not get the correct answers - or the correct intuitions, for that matter - from any model that assumes the energy flows only where the charges are moving (this was a roadblock in understanding electromagnetism which was broken by Maxwell introducing the displacement current.)
Therefore, Veritasium had good pedagogical reasons for saying that the chain model is not accurate and for introducing the Poynting vector. As I pointed out in my previous post, your previous post consisted of a series of points in which you were saying, in effect, that Veritasium was correct, and if you want to reverse course on that now, I think you owe us an explanation of how the chain model explains what happens in the first second after the switch is turned on.
The slides look correct to me but the video massively misrepresents what is actually going on. For example, you could cut the wire at both ends and the answer would not change, so the fact that there is a 'circuit' is irrelevant.
Care to share the hilarity with the rest of the class?
Disclaimer: I don't understand nearly enough about the physics of electricity, but this was a popular response video by ElectroBOOM that Veritasium also responded to in the comments: https://www.youtube.com/watch?v=iph500cPK28
To be clear, you will not find that Veritasium is wrong here (whether hilariously or otherwise); it supports the essential features of the original claims.
He is extremely misleading, if not technically wrong. The Poynting vector has nothing to do with why some small amount of current is temporarily induced into the light bulb. The actual electrical energy flows along the wires (inside and out). In an unrelated phenomenon, you transmit some tiny amount of electrical power directly through the air/vacuum between the battery and the bulb. In a different configuration, or if you inserted certain kinds of reflective materials, you could block (most of) this energy from ever reaching the bulb, without any change whatsoever in the current flowing along the wires. Also, if you submerged the whole circuit (or just the space around the battery and bulb) in a dielectric material with a low speed of light (say, in a piece of rock), you would get a vastly slower and weaker current, with no effect on the current flowing through the wires.
Even the part where he explains the problem with the chain metaphor is wrong. If you actually had a mechanical chain and an engine moving it back and forth, you could extract energy from the movement of the chain either by exploiting friction (to heat up something, just like a resistor does) or by using gears that resist movement in the opposite direction (e.g. slipping the chain) to achieve movement in a single direction. There's nothing all that mysterious about how we extract energy from electricity, at least in practice.
In fact, you could even get an equivalent of the small induced curent: if you recreate his extremely long circuit with a motor instead of the battery and an extremely sensitive motion detector instead of the light bulb 1m away, you would detect some motion [1m/speed of sound in material connecting them] seconds after the motor is started, assuming you are not floating in a perfect vacuum; and then vastly higher motion after 300,000km/speed of sound in chain seconds later.
Nothing more mysterious going on with the EM field.
Even the part where he explains the problem with the chain metaphor is wrong. If you actually had a mechanical chain and an engine moving it back and forth, you could extract energy from the movement of the chain either by exploiting friction (to heat up something, just like a resistor does) or by using gears that resist movement in the opposite direction (e.g. slipping the chain) to achieve movement in a single direction. There's nothing all that mysterious about how we extract energy from electricity, at least in practice.
In fact, you could even get an equivalent of the small induced curent: if you recreate his extremely long circuit with a motor instead of the battery and an extremely sensitive motion detector instead of the light bulb 1m away, you would detect some motion [1m/speed of sound in material connecting them] seconds after the motor is started, assuming you are not floating in a perfect vacuum; and then vastly higher motion after 300,000km/speed of sound in chain seconds later.
Nothing more mysterious going on with the EM field.
Of course, if you do different experiments, you get different outcomes - no-one is suggesting otherwise.
> Nothing more mysterious going on with the EM field.
That's precisely the point here - it all works out exactly in accordance with Maxwell's laws, via transmission line theory - see also my other reply (https://news.ycombinator.com/item?id=29934233)
> Nothing more mysterious going on with the EM field.
That's precisely the point here - it all works out exactly in accordance with Maxwell's laws, via transmission line theory - see also my other reply (https://news.ycombinator.com/item?id=29934233)
Touched on this in my other reply as well, but my point was that our intuitions about mechanical waves describe the electrical system decently enough - the same effects (though with significantly different magnitudes) can be seen with a mechanical equivalent of this electric circuit.
This is to be expected, since the Poynting vector is ultimately a consequence of two very basic physical laws: conservation of energy, and special relativity. Any system which obeys these two laws will have some equivalent of Poynting's vector, though of course the exact formula will be different.
Veritasium's video is deliberately constructed to obscure these facts, and to make it seem like electricity is in fact more mysterious/counter-intuitive than it actually is.
This is to be expected, since the Poynting vector is ultimately a consequence of two very basic physical laws: conservation of energy, and special relativity. Any system which obeys these two laws will have some equivalent of Poynting's vector, though of course the exact formula will be different.
Veritasium's video is deliberately constructed to obscure these facts, and to make it seem like electricity is in fact more mysterious/counter-intuitive than it actually is.
See my reply to your other reply: https://news.ycombinator.com/item?id=29937377
Reply video here: https://youtu.be/iph500cPK28
Edit: apparently too slow, sorry for the noise.
Edit: apparently too slow, sorry for the noise.
ElectroBOOM replied to this: https://youtu.be/iph500cPK28
[deleted]
So first, there are two types of velocity when it comes to signals on a transmission line which is what metal lines on chip are: phase velocity and group velocity.
Phase velocity is close to the speed of light. It can be reduced by dielectric materials parameters so it's often lower than c.
https://en.wikipedia.org/wiki/Phase_velocity
Group velocity is often much slower. Information transfer can never be faster the group velocity, rather than the phase velocity. So when it comes to "on chip communication" it is group velocity that matters. Group velocity depends on many factor of transmission line design such as line thickness, line width, dielectric thickness, etc.
https://en.wikipedia.org/wiki/Group_velocity
Phase velocity is close to the speed of light. It can be reduced by dielectric materials parameters so it's often lower than c.
https://en.wikipedia.org/wiki/Phase_velocity
Group velocity is often much slower. Information transfer can never be faster the group velocity, rather than the phase velocity. So when it comes to "on chip communication" it is group velocity that matters. Group velocity depends on many factor of transmission line design such as line thickness, line width, dielectric thickness, etc.
https://en.wikipedia.org/wiki/Group_velocity
[deleted]
I was working on the central technology team at EA during the run up to the launch of the Xbox 360 and some of us got early access to help prepare for the new architecture.
I was blown away by the amount of technical detail we were getting access to and how clearly explained it was. Much of that was thanks to Bruce Dawson. I remember devouring everything I could find that he'd written and it was a fascinating crash course in CPU architecture for a relatively young software engineer at the time with little hardware background. Thanks Bruce!
I was blown away by the amount of technical detail we were getting access to and how clearly explained it was. Much of that was thanks to Bruce Dawson. I remember devouring everything I could find that he'd written and it was a fascinating crash course in CPU architecture for a relatively young software engineer at the time with little hardware background. Thanks Bruce!
> I got a copy of the detailed descriptions of the Xbox 360 CPU and I read it through multiple times
This way of learning is not taught often enough, we learn it in school when learning another language (e.g. repeating words over and over). But in sciences and engineering the repeated reading of the material is not usually encouraged or talked about.
It would be interesting to see what the material was, it's not linked, but it must have been really detailed.
This way of learning is not taught often enough, we learn it in school when learning another language (e.g. repeating words over and over). But in sciences and engineering the repeated reading of the material is not usually encouraged or talked about.
It would be interesting to see what the material was, it's not linked, but it must have been really detailed.
The material was all proprietary/NDA and I don't think it's ever been shared publicly, sorry.
The main point I wanted to make with how I became the CPU expert was not actually the "reading multiple times" in order to deeply understand it (although that was important) but rather the fact that I chose to become the CPU expert rather than having it assigned to me.
It was one of many times that I became the acknowledged expert of some area, and perhaps therefore in charge of that area, just by working hard in that area until I was "obviously" the expert.
The main point I wanted to make with how I became the CPU expert was not actually the "reading multiple times" in order to deeply understand it (although that was important) but rather the fact that I chose to become the CPU expert rather than having it assigned to me.
It was one of many times that I became the acknowledged expert of some area, and perhaps therefore in charge of that area, just by working hard in that area until I was "obviously" the expert.
Yeah, I definitely echo this.
I work on Display team in Windows and in past worked mostly on IddCx and SoftGpu but recently went through some VESA docs and chimed in my opinion during some meetings. Now I'm leading DisplayPort reliability efforts with graphics IHVs
I work on Display team in Windows and in past worked mostly on IddCx and SoftGpu but recently went through some VESA docs and chimed in my opinion during some meetings. Now I'm leading DisplayPort reliability efforts with graphics IHVs
> repeated reading of the material
I taught myself almost everything I know, and repeated reading is the method I usually use. I don't memorize, but instead I attack any material to learn by "reading sweeps" (this only applies to topics I know nothing about).
I first read all the material and, even if I don't understand a word about anything, I keep going until the end. Then I read everything again from start to end and here I can definitely say that I'm starting to understand. Then again, and this time I allow myself to go back and clarify something I didn't understand. When I feel confident, I try to implement something with the reading material at hand.
I can't recall any material that I recently learnt that way but "The definitive guide to the ARM Cortex M3" by Joseph Yiu is a book I remember (back in 2007 when I started with Cortex microcontrollers).
I taught myself almost everything I know, and repeated reading is the method I usually use. I don't memorize, but instead I attack any material to learn by "reading sweeps" (this only applies to topics I know nothing about).
I first read all the material and, even if I don't understand a word about anything, I keep going until the end. Then I read everything again from start to end and here I can definitely say that I'm starting to understand. Then again, and this time I allow myself to go back and clarify something I didn't understand. When I feel confident, I try to implement something with the reading material at hand.
I can't recall any material that I recently learnt that way but "The definitive guide to the ARM Cortex M3" by Joseph Yiu is a book I remember (back in 2007 when I started with Cortex microcontrollers).
That the approach I've settled on that works best for me. I used to get frustrated that there wasn't "one source" of information that could take me on the journey from novice to expert, and that there was "so much to choose from" on most topics.
Now I happily browse through as many sources as I can find, noting which I think are high quality even if above my head, and absorbing what I can for my current knowledge level. Then I'll revisit the good stuff and scan it to pick up the next layer deep, and repeat over select material until I feel I have what I need.
The other thing I do is make flashcards as I go (I use an app called Quizlet, but I know there are lots out there). Especially with a new subject, just basic terms can be overwhelming at first. I capture want I feel is important in a question & answer format, and just fire it up when I have to a few mins to run through some flashcards (e.g. waiting for a meeting, sitting on the lav, etc.). It seems to work really well for me.
Now I happily browse through as many sources as I can find, noting which I think are high quality even if above my head, and absorbing what I can for my current knowledge level. Then I'll revisit the good stuff and scan it to pick up the next layer deep, and repeat over select material until I feel I have what I need.
The other thing I do is make flashcards as I go (I use an app called Quizlet, but I know there are lots out there). Especially with a new subject, just basic terms can be overwhelming at first. I capture want I feel is important in a question & answer format, and just fire it up when I have to a few mins to run through some flashcards (e.g. waiting for a meeting, sitting on the lav, etc.). It seems to work really well for me.
Impressive. I’m just now learning how to learn that way, and I’m at retirement age. My way is much less efficient, because I stop and research each thing I don’t understand until I feel comfortable moving on. Highly inefficient, I now believe. My kid does what you do and learns way faster than I ever did.
It depends, as always. A CPU is a whole unit, where (I think) it's worth knowing all the details. A programming language's standard library would be more about having a high level overview of what is available, and not a rote reading of all APIs.
...Unless you're into that kind of thing, and I do believe it will help "pick the right tool for the job", instead of writing your own or picking a random library off the internet. Maybe I should make a habit of it, I'm quite invested in Go at the moment.
On the other hand, probably a bigger factor is 'arsedness'. I don't have the attention span or interest to read something back-to-front, or maybe not anymore? I don't know for sure. But there's not many things that grip me enough to really draw me in.
...except writing shitpost comments on HN.
...Unless you're into that kind of thing, and I do believe it will help "pick the right tool for the job", instead of writing your own or picking a random library off the internet. Maybe I should make a habit of it, I'm quite invested in Go at the moment.
On the other hand, probably a bigger factor is 'arsedness'. I don't have the attention span or interest to read something back-to-front, or maybe not anymore? I don't know for sure. But there's not many things that grip me enough to really draw me in.
...except writing shitpost comments on HN.
Yes, I teach my students to always at least look at the overview and see what is available and the taxonomy or ontology!
Don't treat all sources as a mere dictionary of self-evident structure. Quitting just because the blurb of immediate interest has been rendered leaves out key opportunities to learn what is available.
Don't treat all sources as a mere dictionary of self-evident structure. Quitting just because the blurb of immediate interest has been rendered leaves out key opportunities to learn what is available.
I used to read a lot of books when learning about computer science topics. I'm sure i've read the Camel book at least 4 times over several years. A well written book like that can really do much more than just provide a reference.
A lot of documentation these days is mostly references that you look up when you need the nitty gritty details and the bigger picture is not documented as well.
A lot of documentation these days is mostly references that you look up when you need the nitty gritty details and the bigger picture is not documented as well.
this is my standard way of learning stuff,
I don't repeatedly read books just to memorise or remember stuff, but I repeatedly read books because you learn and fully digest certain concepts which are then needed before moving on to other concepts
I don't repeatedly read books just to memorise or remember stuff, but I repeatedly read books because you learn and fully digest certain concepts which are then needed before moving on to other concepts
This is exactly it for me: on your first reading, there are underlying concepts you kind of get, but don't fully understand until you grasp what's built on top of them. Then, with that fuller grasp, you can go back and increase your understanding of the underlying material, which lets you understand the superstructure better — and the effect persists for several iterations if the topic is involved enough.
Short version: don't be too concerned if you're not completely confident on the details the first time through, because it will make a lot more sense next time around.
Short version: don't be too concerned if you're not completely confident on the details the first time through, because it will make a lot more sense next time around.
I also have the same approach for new projects
I appologise in advance for the fact I will repeat questions to people and get it wrong initially, it's part of the learning process
I appologise in advance for the fact I will repeat questions to people and get it wrong initially, it's part of the learning process
I think rote memorization is less useful in engineering than critical thinking/problem solving, that is probably why. It's not really important you know X value of Y part by heart, you need to know how to get X value of any possible part you encounter.
To learn a language, you can't problem solve your way to the solution, you either know it or you don't, and when you use it in practice (in a conversation) you can't look up what you need to know on the spot.
To learn a language, you can't problem solve your way to the solution, you either know it or you don't, and when you use it in practice (in a conversation) you can't look up what you need to know on the spot.
We're not talking about rote memorization here. We're talking about deeply studying something.
In the mid-90s I set up my then-employer's first WAN. Cisco 2501 with T1s for in-city links and frame relay for inter-city/international. As part of our Cisco contract, we got a full manual set, which was maybe 24" of shelf space. In my spare time over a couple of weeks, I sat down and read the whole thing. Then I went back and actually studied the parts that were relevant, mostly by reading and re-reading until it all made sense to me.
On top of that, I added a lot of practical experimentation with the gear. But foundational for me was really understanding the perspective of the people who made it.
In the mid-90s I set up my then-employer's first WAN. Cisco 2501 with T1s for in-city links and frame relay for inter-city/international. As part of our Cisco contract, we got a full manual set, which was maybe 24" of shelf space. In my spare time over a couple of weeks, I sat down and read the whole thing. Then I went back and actually studied the parts that were relevant, mostly by reading and re-reading until it all made sense to me.
On top of that, I added a lot of practical experimentation with the gear. But foundational for me was really understanding the perspective of the people who made it.
Ah, that is different then yes. I think another comment alluded to it but much documentation these days is just simple reference material which without context is only so useful for deep understanding.
I fully agree with understanding the perspective of the people making the thing, knowing the what isn't always as useful as knowing the why. I speak a lot about being idiomatic, which is to say developing in a way that is sympathetic to the system and its existing approaches. That takes understanding the why more than the what.
I am reminded of the Honda motorcycle maintenance manuals. They are like being face to face with the engineers who designed the bike, reading that back to back would give you that deeper understanding of the system I think.
That's my pet peeve with auto-generated docs, they don't actually help much. I can see the function for myself, I don't need to be told it exists, I need to know why!
I fully agree with understanding the perspective of the people making the thing, knowing the what isn't always as useful as knowing the why. I speak a lot about being idiomatic, which is to say developing in a way that is sympathetic to the system and its existing approaches. That takes understanding the why more than the what.
I am reminded of the Honda motorcycle maintenance manuals. They are like being face to face with the engineers who designed the bike, reading that back to back would give you that deeper understanding of the system I think.
That's my pet peeve with auto-generated docs, they don't actually help much. I can see the function for myself, I don't need to be told it exists, I need to know why!
Aargh the thing that amazes me about people like you is the ability to push through when the docs don’t explain something before it’s referenced. How do you get past that point so quickly?
On the first pass? I usually just let it be. Maybe I'll mark it or make a note, but probably not. I've spent my whole life not understanding almost everything right away. If it's important, it'll come up again. It's sort of like starting a new job: you don't know who everybody is right away but you get it over time.
On later passes, I'm more inclined to jump around.
On later passes, I'm more inclined to jump around.
Thank you! I never tire of learning how people learn.
It is important to develop the confidence that you are not actually wasting time reading something which feels as if you understand almost none of it.
It is counter-intuitive because it tends to feel a little bit like a small child who has not yet learned to read, picking up a book and pretending to read by mimicking what the behavior looks and sounds like.
It is counter-intuitive because it tends to feel a little bit like a small child who has not yet learned to read, picking up a book and pretending to read by mimicking what the behavior looks and sounds like.
For what it's worth, I think this "deep study" mode of learning is perhaps less useful today in tech. We have a lot more things we need to work with with now, and a searchable internet means we can draft off other people's learning a lot more. Deep understanding is both less possible and less useful for the bulk of us, who are mainly integrating lots of libraries, services, tools, and frameworks.
But for every given topic, we still need deep experts, like Bruce Dawson was for this processor at Microsoft. So I think this mode is still very valuable, so I agree with Ciantic: this way of learning is something everybody should have at least some practice in.
But for every given topic, we still need deep experts, like Bruce Dawson was for this processor at Microsoft. So I think this mode is still very valuable, so I agree with Ciantic: this way of learning is something everybody should have at least some practice in.
What he is describing is just RTFM. It shouldn't be groundbreaking or really up for debate yet here we are. Manuals are written expressly for this purpose. A properly written manual has everything you need to know to get it working in a practical sense. Theory is a different matter altogether. But we are talking about engineering not science. Engineering is very much in realm of practical application.
If reading a manual front to back for a bit of tech doesn't tell you everything you need to know to use it properly then its not a good manual.
If reading a manual front to back for a bit of tech doesn't tell you everything you need to know to use it properly then its not a good manual.
This applies well for some manuals and poorly for others. When technology changes fast you're likely to read a lot of deprecated stuff. It's an unfortunate state of affairs we find ourselves in.
It doesn't even have to move fast. There are plenty of vendors who are just awful at their documentation even when given all the time in the world.
I think it is my fault, I misunderstood that the GP meant RTFM where available essentially. Though I think it's still relevant, as what is clear to me now is that a lot of us are working with tech that has no true manual, just reference docs, which is a poor substitute for a real user manual.
My argument was essentially that you gain very little from memorizing reference docs. Reading a good manual is definitely invaluable on the other hand.
My argument was essentially that you gain very little from memorizing reference docs. Reading a good manual is definitely invaluable on the other hand.
That is sadly the case. So much documentation is incomplete or out of date to the point of uselessness.
I am not sure why you were downvoted, this is a fairly common response to real world work. There is so much to know, and as systems get more abstracted working in the industry typically requires breadth not depth.
Is that good? Honestly I don't think so, it would be nice to be able to spend more time mastering a stack and using that, and I feel like the outcomes would be infinitely better than jumping ship every 12 months. But that is the reality of parts of the industry, it moves fast.
Is that good? Honestly I don't think so, it would be nice to be able to spend more time mastering a stack and using that, and I feel like the outcomes would be infinitely better than jumping ship every 12 months. But that is the reality of parts of the industry, it moves fast.
Memorizing facts is necessary to make them accessible to your critical thinking and problem solving though.
Like it's much easier to find a connection between two things you know about compared to two things you could look up.
Like it's much easier to find a connection between two things you know about compared to two things you could look up.
> I think rote memorization is less useful in engineering than critical thinking/problem solving
i think this is exactly the right take in entirely the wrong direction.
proficiency and mastery are about committing more and more complex things into sub- or un- concious action; muscle memory as it were. grandmaster chess players dont think about solving puzzles that stump novices, they absorb whole board states and many/all permutations instantly. BJJ black belts dont have to think about arm bars, they anticipate complex possibilities of moves and countermoves that a novice simply cannot fathom. this is as true in engineering as any other field. a simple litmus test: is there a difference between a college grad and a 40-years experienced engineer? of course there is
I think GPs point is exactly right. there is a certain lost magic to simply smashing your brain into something and absorbing as much as possible. big eyes, big ears, ego to attempt but humble to fail. one might call such a person a hacker.
edit: see The Art of Learning, Waitzkin
https://www.amazon.com/gp/aw/d/0743277465/
i think this is exactly the right take in entirely the wrong direction.
proficiency and mastery are about committing more and more complex things into sub- or un- concious action; muscle memory as it were. grandmaster chess players dont think about solving puzzles that stump novices, they absorb whole board states and many/all permutations instantly. BJJ black belts dont have to think about arm bars, they anticipate complex possibilities of moves and countermoves that a novice simply cannot fathom. this is as true in engineering as any other field. a simple litmus test: is there a difference between a college grad and a 40-years experienced engineer? of course there is
I think GPs point is exactly right. there is a certain lost magic to simply smashing your brain into something and absorbing as much as possible. big eyes, big ears, ego to attempt but humble to fail. one might call such a person a hacker.
edit: see The Art of Learning, Waitzkin
https://www.amazon.com/gp/aw/d/0743277465/
I have pretty much the same outlook as you have described, so it's notable that we disagree at least a bit on this point of memorization. I think this is my fault as I misunderstood the GP a bit in my reply. But I would suggest in some ways that practice is different to memorization in some interesting ways. Memorizing a manual on motorcycle riding wouldn't make you a good rider if you have never ridden a bike, and you can become a better rider without it, but it would prepare you for the topics involved and you would likely be far more effective at absorbing the learning from the practice having read the manual.
In other instances memorization is a foundational requirement, like language learning. Can't leanr a word if you don't know the alphabet, for example. In that sense practice only serves to reinforce the memorization it is the memory that is most important to being effective in that case.
In other instances memorization is a foundational requirement, like language learning. Can't leanr a word if you don't know the alphabet, for example. In that sense practice only serves to reinforce the memorization it is the memory that is most important to being effective in that case.
[deleted]
I think it depends alot on your rate of digestion (or understanding? can't find the right word...) of a piece of material. Being dropped in an alien book can make it tough to grasp everything on first pass. If you already have a lot of knowledge that links to the topics being discussed it is a lot easier to grok it in one pass.
Specifically for CPU manuals, detailed reading used to pay off especially back when every cycle counted. You would spend days rereading tucked away sections describing some weird extension or edge case hoping to harness it for your game/program and get more speed out of it.
Somewhat similar is Grace Hopper explaining the nanosecond: https://www.youtube.com/watch?v=9eyFDBPk4Yw
I thought the later 360 CPUs were curiously designed. They had the 360 GPU integrated into the die, and had circuits that purposefully slowed things down to emulate separate chips.
https://en.wikipedia.org/wiki/Xenon_(processor)
https://en.wikipedia.org/wiki/Xenon_(processor)
Presumably to ensure behaviour as near to identical as possible with earlier multi chip systems. Because they're fixed targets developers can end up coding right to the limits of console hardware, and end up with lots of reliance on exact timings etc.
Xbox 360 was getting into the era where consoles had OSes and things should be abstracted through DirectX but I guess Microsoft decided the safest thing to do was create a clone with artificial slowdowns rather than risk games pushing the limit breaking.
Nowadays consoles can change CPU / GPU microarchitectures seemingly without problems...
Xbox 360 was getting into the era where consoles had OSes and things should be abstracted through DirectX but I guess Microsoft decided the safest thing to do was create a clone with artificial slowdowns rather than risk games pushing the limit breaking.
Nowadays consoles can change CPU / GPU microarchitectures seemingly without problems...
I am blown away by the wafer of Xbox 360 CPUs hanging on this guy's wall. That was a kingly gift!
>> I am blown away by the wafer of Xbox 360 CPUs hanging on this guy's wall. That was a kingly gift!
Yeah, the only place I've seen a full wafer on display is a display case in the lobby of a chip company office building. I wonder how often some process goes out of whack and they get an entire known-bad wafer that still looks great?
Yeah, the only place I've seen a full wafer on display is a display case in the lobby of a chip company office building. I wonder how often some process goes out of whack and they get an entire known-bad wafer that still looks great?
You can buy complete wafers on ebay for a few bucks, so I'd guess it's pretty common.
I think many of the alignment steps during manufacturing involve making a wafer, seeing how misaligned it is using an electron microscope, adjusting all the machines, then making another wafer. Repeat until the wafers start working.
I think many of the alignment steps during manufacturing involve making a wafer, seeing how misaligned it is using an electron microscope, adjusting all the machines, then making another wafer. Repeat until the wafers start working.
Yeah I'm seeing them for like $80 for 20-30 year old wafers, it'd make a pretty neat decorative piece: https://www.ebay.com/sch/i.html?_nkw=cpu+wafer
reminds me of when I had some 'trash' leftover CPU's, chips, or memory units; drill a hole in it and you have a keychain gadget.
reminds me of when I had some 'trash' leftover CPU's, chips, or memory units; drill a hole in it and you have a keychain gadget.
[deleted]
Wow. Those are beautiful. If I had wall space left I’d start a collection.
https://twitter.com/Siliconinsid/status/1480216470374207500
"Wafer of the Sony PlayStation 1 CPU. While decaping a Sony CXD8606Q, I was very lucky to be able to match the die to an unidentified wafer I had in my collection. The 6“ wafer could accommodate a total of 200 individual dies."
"Wafer of the Sony PlayStation 1 CPU. While decaping a Sony CXD8606Q, I was very lucky to be able to match the die to an unidentified wafer I had in my collection. The 6“ wafer could accommodate a total of 200 individual dies."
Anyone know how much that would cost roughly? Wondering if they had a big reject bin that needed to be disposed of.
Guessing that the cost for a wafer at a state-of-the-art process has gone up over the years but not that much, in the vicinity of ~$10,000?
https://twitter.com/chiakokhua/status/1306437988801486848 sourced from
https://cset.georgetown.edu/wp-content/uploads/AI-Chips%E2%8... p45
https://twitter.com/chiakokhua/status/1306437988801486848 sourced from
https://cset.georgetown.edu/wp-content/uploads/AI-Chips%E2%8... p45
It depends, is the wafer passing or failing the manufacturing tests? This is an important consideration.
The manufacturing pipeline is generally pretty long too, and you can stop wafers midflight if you're just going to throw them out anyway. So for instance, if you have some B0 wafers that have enough metal layers that you couldn't easily change them into B1 wafers half way through the process, you might end up with it being cheaper to end up with unusable wafers for plaques and what have you. The fab is generally happy to have the extra capacity even for tail end of the design. There's generally some cheap customers that'll slot in wherever there's gaps.
It was always rumored around the FAB that dropping a case of wafers was akin to totaling a Ferrari. Maybe ~20 wafers in a case, so this math checks out!
Pretty pricey for a plaque.. either they really liked him or they had some rejects I would guess.
They always have rejects. Actually, that's almost certainly an unfinished wafer. Modern flip chips don't look like that finished - you have an array of pads and power distribution covering all the cool features.
I think there's a good chance that wafer doesn't have any metal layers, or only M1 at most. It looks the same as the chips I've delayered and removed all or almost all of the metal layers from. For example, here's a shot of the Wii's GPU with the metal layers scraped off:
https://marcan.st/transf/hollywood_die.jpg
I think there's a good chance that wafer doesn't have any metal layers, or only M1 at most. It looks the same as the chips I've delayered and removed all or almost all of the metal layers from. For example, here's a shot of the Wii's GPU with the metal layers scraped off:
https://marcan.st/transf/hollywood_die.jpg
At that distance, depending of the frequency of those buses, it could have some distortion and some latency due to being a transmission line. If this happened, the team that made that CPU would add some kind buffers at the receiving side to get the data at a correct time, and that could be most of the induced lag.
Adding that to the fact that the three cores have a shared common bus, and there are gone to be some kind of signalling about who is using it (that we don't know), this could be reasonable.
The Xbox 360 CPUs works at 3.2 GHz, that's 0.3125 ns per cycle, and four cycles make those 1.25 ns. I won't be surprised if those who made the CPU designed to have 4 cycles of delay to cores 1 and 2 to be sure there isn't any kind of glitch reading the data from the port.
Adding that to the fact that the three cores have a shared common bus, and there are gone to be some kind of signalling about who is using it (that we don't know), this could be reasonable.
The Xbox 360 CPUs works at 3.2 GHz, that's 0.3125 ns per cycle, and four cycles make those 1.25 ns. I won't be surprised if those who made the CPU designed to have 4 cycles of delay to cores 1 and 2 to be sure there isn't any kind of glitch reading the data from the port.
You meant 0.3125ns per cycle, the rest of your comment triggered a thought:
It's common in FPGA/microcontroller designs to have 'input synchronizers' on inputs from long digital lines (on any input where you can't guarantee synchronicity) to prevent metastability problems, especially when crossing clock domains. I think that's likely the case here, there are both long lines and different clock domains.
It's common in FPGA/microcontroller designs to have 'input synchronizers' on inputs from long digital lines (on any input where you can't guarantee synchronicity) to prevent metastability problems, especially when crossing clock domains. I think that's likely the case here, there are both long lines and different clock domains.
Oops! Totally true: 0.3125 ns per cycle
https://en.wikipedia.org/wiki/Signal_velocity - my understanding is that the speed is driven by interactions between the trace and its surrounding material, which creates capacitance and inductance along the path
Sounds like mostly gate delay? I'll share my ignorance. For metal traces on silicon the physical "speed of light in this material" propagation delay should only be around 9-10 ns/m. Call it 10 ps/mm, about 55ps in 5.5mm. Or else if the trace has high enough resistance (maybe not metal), another thing to worry about is charging the line capacitance. That is longer for longer lines, but it is a different kind of delay from speed-of-light.
Technical aspects aside (and congrats on the achievement!), I love the implications of the author's "Aside":
1. An otherwise inconvenient situation (snowpocalypse) was turned into a learning opportunity. I would've probably turned it into a Netflix binge.
2. People took the time to detail the CPU design in a document. I'm always looking for examples showing the benefits of documenting design (I'm an EM) and it's rare to find one that changes someone's life trajectory. :)
1. An otherwise inconvenient situation (snowpocalypse) was turned into a learning opportunity. I would've probably turned it into a Netflix binge.
2. People took the time to detail the CPU design in a document. I'm always looking for examples showing the benefits of documenting design (I'm an EM) and it's rare to find one that changes someone's life trajectory. :)
2004 was a bit early for a Netflix binge. Plus, the power was out, so there goes that plan.
The documentation that I read showed the pipelines in great deal, but they were badly presented such that the flows of data and time were obscured. My main contribution was to straighten out and simplify the diagrams, and then animate them. Well, and then explain them. It was definitely a CPU that required that level of detail.
The documentation that I read showed the pipelines in great deal, but they were badly presented such that the flows of data and time were obscured. My main contribution was to straighten out and simplify the diagrams, and then animate them. Well, and then explain them. It was definitely a CPU that required that level of detail.
Agreed. I’m a pathetically slow learner so situations like #1 were always an essential part of how I got ahead of the curve. #2 is very cool also... but what is an EM?
This post should be retitled to "11 mm in 1.25 nanoseconds", the blog post has been renamed to that as per this update:
"...So the 5.5 mm actually only takes 0.625 nanoseconds each way, the signal actually goes 11 mm in 1.25 nanoseconds, so the original title of this blog post is a lie. Sorry!"
"...So the 5.5 mm actually only takes 0.625 nanoseconds each way, the signal actually goes 11 mm in 1.25 nanoseconds, so the original title of this blog post is a lie. Sorry!"
I have seen these hang on someone's wall. Because they made the ATI cpu. I thought the whole thing was one big cpu. I was not impressed.
Now I am! 15 years late.
Now I am! 15 years late.
The post itself was a pleasure to read. The comments are a mini education on how to learn. I strongly recommend reading through both!
Isn’t the discrepancy due to https://en.m.wikipedia.org/wiki/Space-filling_curve ? (Aka Peano curves)
[deleted]
All I want to say is that the XBOX 360 was one of the best consoles EVER!
I still happily play games on mine.
I think it's more likely that this is an artifact of the interconnect design. For example, the interconnect may be designed as a tree, where the path from core 0 to the L2 only visits a branch but the path to core1/2 has to traverse the root of the tree. If each stage adds a clock cycle, there's your 4 clock cycles: one to go to the root, one back down to the other side, and then the whole thing in the other direction for the reply from L2 with the data.
If the interconnect had been a ring bus instead, you'd find that the latency from cores 0 and 2 is the same, but higher for core 1 - assuming no other endpoints in the ring, but that's obviously not the case, since I/O needs to be on the bus too. It's possible he got the core numbers wrong in the die shot, and core 0 is the bottom left core. Then if the ring goes clockwise L2 - core 0 - core 1 - core 2 - I/O on the top right - L2, that's how you end up with core 0 being closer to the L2 in terms of clock cycles than the others, and the observation would be consistent with this design too.