| General > General Technical Chat |
| Starting a new CompSci/Electronics career -need advice! |
| << < (10/14) > >> |
| fourfathom:
--- Quote from: tggzzz on September 08, 2022, 07:00:39 pm ---[more of the same, from both of us] --- End quote --- I think we're shooting past each other, and you seem to be assuming ridiculously fundamental ignorance on my part. I would enjoy continuing this friendly debate, but this probably isn't the thread for it. |
| tggzzz:
--- Quote from: dunkemhigh on September 08, 2022, 07:12:19 pm --- --- Quote ---So, is an x86 processor hardware or software? Is an IC hardware or software? Does the answer change if the IC is an MCU? Why? Is an FPGA hardware or software? In what way is that fundamentally different to an embedded MCU? --- End quote --- Wouldn't the answer depend on what you're going to do with them? If you're making one run Windows then clearly it is software. But if you're trying to create a motherboard on which to stick them then clearly that's hardware. You can be a wiz at DDR5 layout and barely able to write a one-line hello.bat, and similarly be able to implement some adjacent row snooping algorithm and yet be unable to identify the right DIMM slot to plug one into. --- End quote --- I don't think the use matters. FPGA are blank until made useful by code written in an HDL. MCUs blank until made useful by code written in C. X86s are the name of our lives. FSMs can be created in pure software (e.g. telecom systems) or pure hardware (e.g. offshore oil rigs using hydraulic logic) or programes that configure blank hardware,or a combination of all techniques. That principle is not limited to FSMs, of course. There is no easily defendable black and white distinction between hardware and software; it is a gray continuum. |
| tggzzz:
--- Quote from: fourfathom on September 08, 2022, 07:20:20 pm --- --- Quote from: tggzzz on September 08, 2022, 07:00:39 pm ---[more of the same, from both of us] --- End quote --- I think we're shooting past each other, and you seem to be assuming ridiculously fundamental ignorance on my part. I would enjoy continuing this friendly debate, but this probably isn't the thread for it. --- End quote --- The relevance is limited to helping budding engineers realise that labels unhelpfully and incorrectly partition design concepts and implementations. The earlier and more they think in general terms, the better for their career. Anything that prods people to discard unhelpful concepts is to be welcomed. |
| fourfathom:
--- Quote from: tggzzz on September 08, 2022, 08:14:44 pm ---The relevance is limited to helping budding engineers realise that labels unhelpfully and incorrectly partition design concepts and implementations. The earlier and more they think in general terms, the better for their career. Anything that prods people to discard unhelpful concepts is to be welcomed. --- End quote --- But to think clearly about a system / problem / solution, you need to be able to analyze and recognize the fundamental essence as well as the details. We partition and categorize (label) things so we can best find the optimum interconnections (I'm not talking about wires here), and overall structure. You saying, essentially, "we can't call this hardware because, hey, look over there, someone did something similar with software!, or "there's 'software' inside that component" is not being helpful. Of course we should consider all the tools in the box when we are approaching a design -- hardware, software, etc. -- and usually it's a mix. But first you must understand the thing, and appropriate labels can be essential to that understanding. Yes, you can also trap yourself into a poorly thought-out solution with improper labeling, but I submit that that the labeling is usually an effect, not a cause. |
| tggzzz:
--- Quote from: fourfathom on September 08, 2022, 08:44:36 pm --- --- Quote from: tggzzz on September 08, 2022, 08:14:44 pm ---The relevance is limited to helping budding engineers realise that labels unhelpfully and incorrectly partition design concepts and implementations. The earlier and more they think in general terms, the better for their career. Anything that prods people to discard unhelpful concepts is to be welcomed. --- End quote --- But to think clearly about a system / problem / solution, you need to be able to analyze and recognize the fundamental essence as well as the details. We partition and categorize (label) things so we can best find the optimum interconnections (I'm not talking about wires here), and overall structure. You saying, essentially, "we can't call this hardware because, hey, look over there, someone did something similar with software!, or "there's 'software' inside that component" is not being helpful. --- End quote --- No, I'm not saying that. I'm saying don't be constrained by needlessly structuring your thinking around a bogus split between hardware and software. Yes, that does happen.it is a variant of Conway's Law, viz Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. — Melvin E. Conway As I recounted, during one job interview the HRDroid needed to pigeonhole me as either a hardware engineer exclusive-or a software engineer, because that dictated the part of the organisation I would work in. I declined to answer, and he was stymied. I didn't take the offered job! --- Quote ---Of course we should consider all the tools in the box when we are approaching a design -- hardware, software, etc. -- and usually it's a mix. But first you must understand the thing, and appropriate labels can be essential to that understanding. Yes, you can also trap yourself into a poorly thought-out solution with improper labeling, but I submit that that the labeling is usually an effect, not a cause. --- End quote --- |
| Navigation |
| Message Index |
| Next page |
| Previous page |