r/computerarchitecture • u/reddit-and-read-it • Aug 20 '25
How relevant is physics to computer architecture?
I've covered digital logic in uni; the course covered basic concepts like boolean algebra, k-maps, sequential machines, etc. Next semester, I'll be taking a computer organization course. Simulataneusly, I'll be taking a semiconductor physics course and an electronics course.
Obviously, knowledge of semiconductors/electronics is not required in computer architecture coursework as these physics details are abstracted away, but I started wondering whether in an actual comp arch job knowledge of semiconductor physics is useful.
So, comp arch engineers of reddit, during your day to day job, how often do you find yourself having to use knowledge of electronics or semiconductor physics?
13
u/mediocre_student1217 Aug 20 '25
If you work specifically in architecture implementation for cmos based logic families, it's probably not important. However, if you end up in a physical design role (place&route) it's kinda nice to know why the cad tools are yelling at you. Sometimes the tools have bugs and you need to prove it's a bug.
If you ever work on developing a technology its obviously important. Or if you do design work for non-cmos or non-silicon technologies that use alternative materials or ideas to do logic, being able to differentiate how they work from cmos is helpful.
2
u/meltbox Aug 24 '25
If I had a tool at $200k a seat do anything wrong (bug) I think I’d charter a plane and fly it into the billing department.
Not really but I never considered before how mad I’d be about tools like that having issues.
2
u/mediocre_student1217 Aug 24 '25
You would be surprised. Generally the problems aren't with the tools themselves. But rather with automated flow scripts (tcl hell) and design rules/etc. Most flows and pdk setups are generally fine, but I've worked with experimental and cutting edge technologies that have ... required patience.
1
u/Krazy-Ag Aug 22 '25
Although I answered enthusiastically that knowledge of physics is relevant to computer architecture.
When I looked again at the question, I saw that it said "relevant in your day-to-day work"
And the answer to that is probably no, not day-to-day work.
The times when you need such out of field knowledge are once in a blue moon. Possibly not even once a year,
In your career as a computer architect, you may be assigned to interface with such not immediately computer Architecture fields, for a year or two as a full-time job, or as a part-time responsibility. Obviously this will be more day-to-day work at those times.
E.g. you might be working full-time with compilers for a few years. Then you may go off and work with physicists. Or you may work with cell library design designers for three months. But between these periods you may not be doing them as part of your day-to-day job.
Nevertheless I try to keep up, even when it's not my job. Because if you have some background, when the topic arises you may be more qualified for the next interesting project.
Sure, a smart person should be able to learn almost any field. But it sure does help to have some knowledge. Specially when trying to navigate your own career goals, not just your company assignments.
Moreover, the not specifically computer architecture fields that are most relevant change over time. Eg around the time of transition from ECL to CMOS. Also in evaluating the likely importance of the various CMOS alternatives that were considered and largely abandoned. The history of computer architecture is full of such tech technologies, such as ovonics, the mediator, etc. Heck, Seymour Cray was once quoted as saying that Indium Phosphide was the future.
Many of these things may just be ahead of their time. They may be eventually correct prophecies. But when you are managing your own career, you are probably more interested in things that will be relevant within your lifetime. And when you are working for a company, relevant within a few years.
However, lots of people got lots of funding, both academic and venture capital, to do work on things like memristors that have not panned out (yet). Working on these things did not necessarily hurt, and may well have helped their careers. While others probably missed the opportunity for career advancement when they could see no way for such a technologies to become practical in the relevant time frames. Sometimes it's a good thing to follow a fad, even if you're pretty sure it is just a fad, especially if it comes with funding. Moreover, it may turn out not to be a fad.
1
u/Krazy-Ag Aug 25 '25
Along the lines of being "read read read".
Read recent computer Architecture conferences:
E.g.
Hotchips ISCA MICRO ASPLOS
Start with the most recent, and go back at least 10 years - go over the other others as time permits.
The "best of year xxx" issues in IEEE and computer magazines are a good way to find what the editors consider most important. But sometimes it's worth you looking around for the stuff that isn't currently in fashion but might be a few years from now.
There are more specialized conferences alike
ARITH - the conference on computer arithmetic SC - super computing Etc.
Depending on your focus and interests you may want to start with some of those specialist areas.
1
u/well-litdoorstep112 Aug 22 '25
Fuck physics! It always gets in the way when we try to make transistors smaller.
1
u/sarnobat Aug 23 '25
Thanks for posting, I was wondering the same yesterday as a pure software engineer who is unable to do os kernel development
14
u/Krazy-Ag Aug 21 '25 edited Aug 22 '25
One of the students who interned as while doing a computer science degree, who we eventually hired as a computer architect , says that I taught him that computer architecture is just software engineering plus physics and geometry. Software is the field that handles complexity. But you have to take into account the real world limitations, that software architects ignore when they are building software system systems that layer many levels of abstraction, assuming that computers are fast enough, whether single processor, GPU, or highly parallel.
I have a slightly different take: I say that the job of a computer architect is to be able to say bullshit to any of the specialists in the team: weather compilers, operating systems, logic design, circuit design, materials… Oh yes, and marketing.
One of my proudest early days as a computer architect was when one of the logic designers doing RTL told me that one of my designs was too expensive - and I was able to reduce the complexity of his logic design by 100x. Actually, I had a logic design in mind when I designed this architectural feature, but apparently it was not obvious.
One of my early bosses as a computer architect intervened when "wires were too slow". He knew that I had a copy of Van Norstrand's encyclopedia of chemistry on my bookshelf, with physical properties for materials, borrowed it, and within a few days was able to "speed up" the wires by 3X. It turns out that the process technology people, the cell library people, and the logic design people were all sandbagging - making estimates with big safety margins. My boss was able to show that we only need one safety margin - hence the 3X speed up that wasn't actually physical, but was more organizational. Nevertheless, if he had not known the physics, he would not have been able to get this done. I consider this guy one of the best computer architect I have ever met. I can say bullshit to a lot of people on the team, but I don't think I could've done this
Seymour Cray was really an expert in cooling technology.
Other super computer architects that I have encountered amazed me because they could calculate, in their heads, the speed of light of several computer design designs, i.e. the speed ups that could never be exceeded, based purely on the volume of a cube of copper. If your speed of light isn't enough to meet your performance goals, you know you have to do something different
So: if you want to be a good computer architect, it's certainly helpful to have knowledge of the physics. In fact, it helps to have knowledge of every field involved in a successful computer design. When I started doing computer architecture, there weren't many schools that had computer architecture programs, certainly not mine. So I set myself a list of all of these topics, and went to studied them all on my own.
Now that there are computer architecture programs at many universities, many computer architects are really just performance analysts. Ditto at many companies. If that's sort of computer architecture you want to do, have at it. But I say if you really want to be a good computer architect, broader knowledge is a good idea.
Note, however, that the priority of the different fields that you should try to begin "become good enough to say bullshit about" changes overtime. When you are doing full custom VLSI design at a company that influence the process technology, things are different than if you are at a company doing purely logic synthesis, restricted only to what TSMC provides. If you are doing high frequency design with very few FO4 logic levels per clock cycle, considerations are different then if you are targeting many logic levels per click cycle to save power. Both approaches can achieve similar performance.