[HN Gopher] 5.5 mm in 1.25 nanoseconds
___________________________________________________________________
5.5 mm in 1.25 nanoseconds
Author : asicsp
Score : 283 points
Date : 2022-01-13 13:37 UTC (9 hours ago)
(HTM) web link (randomascii.wordpress.com)
(TXT) w3m dump (randomascii.wordpress.com)
| theandrewbailey wrote:
| 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)
| fredoralive wrote:
| 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...
| Ciantic wrote:
| > 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.
| 123pie123 wrote:
| 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
| JasonFruit wrote:
| 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.
| 123pie123 wrote:
| 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
| foobarian wrote:
| 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.
| bostonsre wrote:
| 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.
| brucedawson wrote:
| 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.
| Cthulhu_ wrote:
| 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.
| erosenbe0 wrote:
| 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.
| scoutt wrote:
| > 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).
| billti wrote:
| 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.
| tomcam wrote:
| 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.
| Tepix wrote:
| 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.
| ehnto wrote:
| 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.
| wpietri wrote:
| 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.
| tomcam wrote:
| 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?
| tanseydavid wrote:
| 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.
| wpietri wrote:
| 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.
| tomcam wrote:
| Thank you! I never tire of learning how people learn.
| wpietri wrote:
| 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.
| thereddaikon wrote:
| 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.
| onemoresoop wrote:
| 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.
| kryogen1c wrote:
| > 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/
| im3w1l wrote:
| 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_.
| [deleted]
| tom-thistime wrote:
| 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.
| Tuna-Fish wrote:
| Somewhat similar is Grace Hopper explaining the nanosecond:
| https://www.youtube.com/watch?v=9eyFDBPk4Yw
| mattnewport wrote:
| 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!
| discreditable wrote:
| I am blown away by the wafer of Xbox 360 CPUs hanging on this
| guy's wall. That was a kingly gift!
| phkahler wrote:
| >> 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?
| londons_explore wrote:
| 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.
| Cthulhu_ wrote:
| 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.
| tomcam wrote:
| Wow. Those are beautiful. If I had wall space left I'd
| start a collection.
| [deleted]
| bostonsre wrote:
| Anyone know how much that would cost roughly? Wondering if they
| had a big reject bin that needed to be disposed of.
| andreareina wrote:
| 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
| bostonsre wrote:
| Pretty pricey for a plaque.. either they really liked him
| or they had some rejects I would guess.
| marcan_42 wrote:
| 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
| qsmi wrote:
| It depends, is the wafer passing or failing the
| manufacturing tests? This is an important consideration.
| monocasa wrote:
| 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.
| bowmessage wrote:
| 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!
| nashashmi wrote:
| 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.
| mring33621 wrote:
| All I want to say is that the XBOX 360 was one of the best
| consoles EVER! I still happily play games on mine.
| tomcam wrote:
| The post itself was a pleasure to read. The comments are a mini
| education on how to learn. I strongly recommend reading through
| both!
| cmpaul wrote:
| 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. :)
| tomcam wrote:
| 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?
| cshokie wrote:
| Based on the context most likely "Engineering Manager.
| brucedawson wrote:
| 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.
| ridaj wrote:
| 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
| marcan_42 wrote:
| The speed of light story is a fun conjecture, but given the
| discrepancy (30cm vs 5.5mm), I don't think that's it. Light
| travels slower in wires but not _that_ much slower, and increased
| design clocks don 't explain the discrepancy either.
|
| 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.
| [deleted]
| brucedawson wrote:
| 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.
| marcan_42 wrote:
| 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) :-)
| kens wrote:
| 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?
| BeeOnRope wrote:
| 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.
| AshamedCaptain wrote:
| 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.
| entangledqubit wrote:
| 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.
| 123pie123 wrote:
| 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
| [deleted]
| Dumble wrote:
| https://www.youtube.com/watch?v=2Vrhk5OjBP8
| krupan wrote:
| ElectroBOOM replied to this: https://youtu.be/iph500cPK28
| jaywalk wrote:
| 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.
| scrollaway wrote:
| Care to share the hilarity with the rest of the class?
| Tostino wrote:
| Reply video here: https://youtu.be/iph500cPK28
|
| Edit: apparently too slow, sorry for the noise.
| aemreunal wrote:
| 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
| mannykannot wrote:
| 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.
| tsimionescu wrote:
| 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.
| tom-thistime wrote:
| 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.
| sebzim4500 wrote:
| 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.
| tsimionescu wrote:
| 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.
| tom-thistime wrote:
| I agree that current doesn't follow the Poynting vector.
| Power follows the Poynting vector. That's true for
| antennas and for transmission lines.
| tsimionescu wrote:
| 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).
| pja wrote:
| 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.
| [deleted]
| krupan wrote:
| 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.
| kens wrote:
| 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.
| AshamedCaptain wrote:
| 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...
| jhgb wrote:
| But IC interconnects have a very small cross section, so
| for them this problem is much more pressing.
| tom-thistime wrote:
| 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.
| jmrm wrote:
| 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.
| SeasonalEnnui wrote:
| 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.
| jmrm wrote:
| Oops! Totally true: 0.3125 ns per cycle
| [deleted]
___________________________________________________________________
(page generated 2022-01-13 23:00 UTC)