4 ms·

In the first 2 years of work, I bounced about quite a lot within my first company, and did the following: Formal proofs and checks for a full unit. RTL design

In the first 2 years of work, I bounced about quite a lot within my first company, and did the following: Formal proofs and checks for a full unit. RTL design with another bloke on a block. Owner of an testing tool (developer). Owner of a testbench for top level design. Owner of process for bringing up new pieces of RTL(4 blocks, one after the other) into the top level design. All of this was caused because the startup I started in was stupidly undermanned, and there wasn't anyone else about. When I left that company, they had gone and hired about 12 people to do all of those tasks, and I saw myself handing over tasks to more senior people. I had experienced atleast 3-4 different areas of the process, and became really familiar with ARMV8 (what got me my next job). Yet this guy over here is thinking that its gonna take 2 years for someone to be even able to do 1 of those tasks? Could argue a really long time about individual cases, but I think the Hardware industry has a very big problem with arrogance. Most companies and senior people carry an air of "no one else can do what I do" kind of bs, that I experienced in SV quite a bit. They look down on junior devs thinking that they are incapable of doing anything. I asked in my office just now, the reasons for leaving their first jobs: 1. Wasn't allowed to do RTL design work inside the CPU 2. Wasn't given any responsibilities other than manually writing coverage(automating this was not permitted) 3. Ownership of the block that he had written from scratch was given to a more senior person once it came to integrating it to the top level 4. Money I find it extremely common for people(usually at the 2-3 year mark) to leave for greener pastures where they are taken in as experienced engineers, rather than useless babes. It might be a rite of passage, or it might just be the mistakes of an industry entrenched in the past

petra 10y ago
Well, the chip industry is an industry with low risk tolerance - making a buggy chip is very expensive, You'll probably see a similar behaviour in many high-risk engineering fields. Software works differently , so no wonder it's more appealing.
aninhumer 10y ago
I had a similar experience working in a hardware research group for a few years. We were working in Bluespec, and our process was very software like, in that we'd hack things together and fix bugs when they arose. We were doing okay in terms of getting working hardware quickly, and our process was fairly bad (e.g. we used SVN, often badly). I think a better funded team using modern practices (backed by some more traditional QA) could do really well. And my impression from our interactions with the industry is that hardware and software are so culturally separated that there are hardly any people who end up experiencing enough of both to truly tackle the problems. Hardware people tend to think abstraction is a synonym for inefficiency, and software people often aren't familiar enough with the complications of hardware to abstract it efficiently.

petra 10y ago

Well, the chip industry is an industry with low risk tolerance - making a buggy chip is very expensive, You'll probably see a similar behaviour in many high-risk engineering fields. Software works differently , so no wonder it's more appealing.

aninhumer 10y ago

I had a similar experience working in a hardware research group for a few years. We were working in Bluespec, and our process was very software like, in that we'd hack things together and fix bugs when they arose. We were doing okay in terms of getting working hardware quickly, and our process was fairly bad (e.g. we used SVN, often badly). I think a better funded team using modern practices (backed by some more traditional QA) could do really well. And my impression from our interactions with the industry is that hardware and software are so culturally separated that there are hardly any people who end up experiencing enough of both to truly tackle the problems. Hardware people tend to think abstraction is a synonym for inefficiency, and software people often aren't familiar enough with the complications of hardware to abstract it efficiently.