Comment by wronglebowski a day ago
It’s incredible how bad driver support is the ARM space. I was looking into some of the various Ambernic handhelds and their Linux firmware. Despite their SoCs being advertised as having Vulkan 1.1 support every firmware for the device ships with it disabled.
It bewilders me. Software's gotta be easier than hardware right? Not that either is easy but as a software engineer, the engineering that goes into modern hardware mystifies me.
It's different definitions of "easy."
With hardware, you have about one billion validation tests and QA processes, because when you're done, you're done and it had better work. Fixing an "issue" is very very expensive, and you want to get rid of them. However, this also makes the process more of, to stereotype, an "engineer's engineering" practice. It's very rules based, and if everything follows the rules and passes the tests, it's done. It doesn't matter how "hacky" or "badly architected" or "nasty" the input product is, when it works, it works. And, when it's done, it's done.
On the other hand, software is highly human-oriented and subjective, and it's a continuous process. With Linux working the way it does, with an intentionally hostile kernel interface, driver software is even more so. With Linux drivers you basically chose to either get them upstreamed (a massive undertaking in personality management, but Valve's choice here), deal with maintaining them in perpetuity at enormous cost as every release will break them (not common), or give up and release a point in time snapshot and ride into the sunset (which is what most people do). I don't really think this is easier than hardware, it's just a different thing.
From the outside looking in. It really seems like both fields are working around each other in weird ways, somewhat enforced by backwards compatibility and historical path dependence.
The transition from more homogeneous architectures to the very heterogeneous and distributed architectures of today has never really been all that well accounted for, just lots of abstractions that have been papered over and work for the most part. Power management being the most common place these mismatches seem to surface.
I do wonder if it will ever be economical to "fix" some of these lower level issues or if we are stuck on this path dependent trajectory like the recurrent laryngeal nerve in our bodies.
I think what they were referencing with that is that the kernel hardware interface is unstable, it changes literally every version, which is why you went to upstream it so you don't have to keep it up yourself after that.
Software is easier than hardware in general but companies generally pay their hardware guys 25-50% less than their software counterparts
People repeat this line a lot but I don’t think it’s true. Companies like Intel, AMD, Arm, Broadcom, etc. afaik all pay their software folks of equivalent YoE or level roughly the same as their hardware folks. To the extent there’s any difference, it’s much less than 25%.
OTOH, there’s a small slice of (mainly) software companies like Google and Meta, along with Unicorn private companies, that skew the average software engineer salary high. Then there’s a long tail of “old school” hardware companies like TI, Motorola, Atmel, Microchip, and tons of smaller less well known companies that all pay much lower than Google. But they pay their software people poorly as well.
So if you just look at “average software engineer salary” vs “average hardware engineer salary” it appears that SW people are making 50% more than HW people, but it’s not at the same companies.
I've done both. There are difficulties with both but overall I would say software is significantly more difficult than hardware.
Most hardware is actually relatively simple (though hardware engineers do their best to turn it into an incomprehensible mess). Software can get pretty much arbitrarily complex.
In a way I suspect it's because hardware engineers are mostly old fogies stuck in the 80s using 80s technologies like Verilog. They haven't evolved the tools that software developers have that enable them to write extremely complicated programs.
I have hope for Veryl though.
Wow, super hard disagree, comment here sounds like the typical arrogance hardware engineers face from people in software who've never really done the job or have some superficial experiences.
I won't blindly state "software is easier" but software is definitely easier to modify, iterate and fix, which is why sofware tools and resulting applications can evolve so fast.
I have done both HW & SW, routinely do so, and switch between deep hardware jobs and deep software so I'm qualified to speak.
If you're blinking a light or doing something with Bluetooth you can buy microcontrollers that have this capability and yes that hardware is simple.
But have you ever DESIGNED a microcontroller, let alone a modern processor or complex system ?
Getting something "simple" like a microcontroller to reliably start-up involves complex power sequencing, making sure an oscillator works, a phase-locked-loop that behaves correctly and that's just "to make a clock signal run at a frequency" we're not talking about implementing PCIe Gen5 or RDMA over 100Gbps Ethernet.
Hardware engineers definitely welcome better tools but the cost of using an unproven tool or tool that might have "a few" corner cases resulting in your $5-million SoC not working is a hard risk to tolerate, so sadly(and to our pain) we end up using proven but arcane infrastructure.
Software in contrast can evolve faster because you can "fix it in software". New tools can be readily tested, iterated on and deployed.
> But have you ever DESIGNED a microcontroller
Yes... But in fairness I was just talking about the digital RTL, not the messy analogue stuff (PLLs, power/reset, etc.) I've never done that.
> but software is definitely easier to modify, iterate and fix,
Definitely true.
> which is why sofware tools and resulting applications can evolve so fast.
Not sure I agree here though. It seems to me that EDA tools evolve super slowly because a) hardware engineers are timid old fogies who never want to learn anything new, and b) the big three have a monopoly on tooling.
What do you think about Atopile? I'm not a hardware person yet, but these seem similar.
Come to think of it, for them it is basically customer support.
Most will want to outsource it as cheap as possible and/or push it to the community. They won't care if it takes an eternity for the customer to get their issues solved as long as new customers keep buying.
And a few companies will see an opportunity to bring better customer care as an advantage and/or integrate it in their philosophy.
But - doesn’t open sourcing it kinda make it someone else’s chore?
Obviously it has to “work” at sale but ongoing maintenance could be shared with the community.
They're stuck in the building model of making semi-custom SoCs for enormous corporations and releasing/developing drivers for them in extreme NDA environments.
It's fine (or arguably not) for locked down corporate devices.
Not so fine for building computers people want to use and own themselves.
So many chipmakers and development board manufacturers see software/driver support as some kind of necessary evil--a chore that they grudgingly do because they have to, and they will do the absolute minimum amount of work, with barely enough quality to sell their hardware.