6 ms·

This is almost a universal problem with firmware and chip engineers, who are generally older and more experienced, and thus apparently can't be taught new trick

This is almost a universal problem with firmware and chip engineers, who are generally older and more experienced, and thus apparently can't be taught new tricks. There are also issues with bureaucracies in each and every semiconductor company (which are on average decades old) so firmware is usually hot potatoed around by management and ends up lighting the customers' projects on fire almost every damn time. I don't have enough fingers to count how many times I've encountered problems in a project and wasted weeks treading water, eventually to find out that the code examples weren't tested, a parameter that closely effects very sensitive silicon isn't documented, or even that I can't so much as get the documentation for a licensed USB peripheral that is non EHCI compliant (who knew such a thing even existed anymore). Everyone from Broadcom to Qualcomm (and many more) are guilty of this and it is a very rare treat to find a chip that is well documented with firmware and code examples that work and give you a full picture of what you can do and where the pitfalls are.

CamperBob2 13y ago
They also have to live in fear of patent suits. Open-sourcing a modern chipset driver is a pretty ballsy thing to do.
- akiselev 13y ago
  IANAL and I don't have much experience with the legal side of silicon IP but from some cursory conversations with people in the industry, if you're making a chip as advanced as a VideoCore, you're certainly already cross licensing a lot of IP cores. If you license, for example, a EHCI compliant USB core or an MMU or cache pipeline that you get in the form of a VHDL or Verilog file (poor you), that license automatically transfers a right to the patents (as long as the legal chain of contracts were worked on by competent negotiators and lawyers) and rarely do those extend to firmware source code from my understanding. There could still be problems with the documentation of the interfaces to different cores or whatever, but that's peanuts to a company like Broadcom. I'd guess they already have very liberal agreements for important IP and the stuff you'd sue over is mostly the closed source silicon.
DougMerritt 13y ago
> generally older and more experienced, and thus apparently can't be taught new tricks. Ah yes, experience, the bane of all technical projects. I have worked at lots of hardware companies over the years, and to varying degrees, they universally treat software as the red headed stepchild -- an unfortunate necessity akin to paying taxes, or worse.
- AceJohnny2 13y ago
  Hahaha! Ha! Haa... And that's why I no longer work for a semiconductor company.
embedded 13y ago
Wow, armchair engineer, you sound like you really know what you're talking about. When this old engineer worked on embedded MIPS cores and 802.11[abgn] at Broadcom, everything was under source code control. This was pre-git, so I think we were using cvs. How the hell do you conclude that releasing a zip file means the engineers don't use source code control?
- GFK_of_xmaspast 13y ago
  The fashion of the day is, for better or worse, "if you don't have a github you ain't shit."
  - bdamm 13y ago
    git is overkill for facilities with small groups working in a common area (not hard to imagine if you're in the hardware biz) and all the engineers are used to cvs command syntax..
    - GFK_of_xmaspast 13y ago
      The best VCS is the one you use.
      - ardacinar 13y ago
        unless it's CVS, or god forbid, Visual SourceSafe.
      - bigiain 13y ago
        There _are_ differences, but yeah - you're arguing about the ranking of the 99.91% - 99.95% better solutions compared to no version control. (Seriously - even CVS and SourceSafe are 99.9% closer to "perfect" than doing nothing)
    - jjoonathan 13y ago
      Overkill until the network goes down or the server dies or somebody needs to work remotely and the VPN isn't working. I don't know how fast git is wrt cvs, but I remember being pleasantly surprised coming from svn. You don't have to have a distributed workflow to occasionally reap the benefits of working with git.
Taniwha 13y ago
akislev: I think you paint with too broad a brush - I've worked as a chip designer, embedded systems programmer, kernel hack - it really depends on the team - also most chip teams I've worked with have been relatively young (most in their 20s)- most big silicon projects depend on good version control software because you are doing continual integrations and practice tapeouts through the last half of a project - you may have 2-3 different versions of the code you're working on passing through different portions of the process at any one time As the guy on the chip team who understood software well (or the guy on the software team who understood the gates) I do think there's a somewhat different issue that has to do with schedules: as a chip designer you get to do maybe 1 month a year of creative design and 11 months meeting timing and making damn sure that silicon will really work the first time - by the time you tape out you're really looking forward to that creative bit and about the time you've up to your armpits in it the silicon comes back and the firmware guys are doing bringup - you don't have a lot of time for the firmware guys because they're getting in the way of the cool part of your job, and besides you are sooo done with that chip you slaved over last year I don't know what the answer is other than making sure you have firmware running on your logic simulator long before tapeout (you should be doing that anyway)
- akiselev 13y ago
  Ooops yeah I chose the wrong words and painted way too broad. I meant version control as far as the firmware libraries and public facing code. I can't imagine going from FPGA to silicon synthesis is even possible without extremely tight version control of some sort or another (I think they used to use basic transperencies for comparing masks) I stand corrected as far as the average age of employees but every time I have interfaced with any level of a silicon company the average age distribution has been skewed pretty high.
bjackman 13y ago
22 year old working in firmware department of major silicon IP company here (you can probably guess who - obviously standard disclaimer about I don't represent them). My company selling IP rather than hardware makes it a bit easier, but: management is realistic and reasonably versatile. Attitude to proper technologies (e.g. using Github instead of releasing tar bombs over FTP) is good. Documentation is good, bar "don't document that or we will be sued" situations, which are too common. Testing sucks in certain areas but is good in most. Obviously at my age I don't have much experience, but I thought the alternative view might be nice.

CamperBob2 13y ago

They also have to live in fear of patent suits. Open-sourcing a modern chipset driver is a pretty ballsy thing to do.

akiselev 13y ago
IANAL and I don't have much experience with the legal side of silicon IP but from some cursory conversations with people in the industry, if you're making a chip as advanced as a VideoCore, you're certainly already cross licensing a lot of IP cores. If you license, for example, a EHCI compliant USB core or an MMU or cache pipeline that you get in the form of a VHDL or Verilog file (poor you), that license automatically transfers a right to the patents (as long as the legal chain of contracts were worked on by competent negotiators and lawyers) and rarely do those extend to firmware source code from my understanding. There could still be problems with the documentation of the interfaces to different cores or whatever, but that's peanuts to a company like Broadcom. I'd guess they already have very liberal agreements for important IP and the stuff you'd sue over is mostly the closed source silicon.

DougMerritt 13y ago

> generally older and more experienced, and thus apparently can't be taught new tricks. Ah yes, experience, the bane of all technical projects. I have worked at lots of hardware companies over the years, and to varying degrees, they universally treat software as the red headed stepchild -- an unfortunate necessity akin to paying taxes, or worse.

AceJohnny2 13y ago
Hahaha! Ha! Haa... And that's why I no longer work for a semiconductor company.

embedded 13y ago

Wow, armchair engineer, you sound like you really know what you're talking about. When this old engineer worked on embedded MIPS cores and 802.11[abgn] at Broadcom, everything was under source code control. This was pre-git, so I think we were using cvs. How the hell do you conclude that releasing a zip file means the engineers don't use source code control?

GFK_of_xmaspast 13y ago
The fashion of the day is, for better or worse, "if you don't have a github you ain't shit."
- bdamm 13y ago
  git is overkill for facilities with small groups working in a common area (not hard to imagine if you're in the hardware biz) and all the engineers are used to cvs command syntax..
  - GFK_of_xmaspast 13y ago
    The best VCS is the one you use.
    - ardacinar 13y ago
      unless it's CVS, or god forbid, Visual SourceSafe.
    - bigiain 13y ago
      There _are_ differences, but yeah - you're arguing about the ranking of the 99.91% - 99.95% better solutions compared to no version control. (Seriously - even CVS and SourceSafe are 99.9% closer to "perfect" than doing nothing)
  - jjoonathan 13y ago
    Overkill until the network goes down or the server dies or somebody needs to work remotely and the VPN isn't working. I don't know how fast git is wrt cvs, but I remember being pleasantly surprised coming from svn. You don't have to have a distributed workflow to occasionally reap the benefits of working with git.

Taniwha 13y ago

akislev: I think you paint with too broad a brush - I've worked as a chip designer, embedded systems programmer, kernel hack - it really depends on the team - also most chip teams I've worked with have been relatively young (most in their 20s)- most big silicon projects depend on good version control software because you are doing continual integrations and practice tapeouts through the last half of a project - you may have 2-3 different versions of the code you're working on passing through different portions of the process at any one time As the guy on the chip team who understood software well (or the guy on the software team who understood the gates) I do think there's a somewhat different issue that has to do with schedules: as a chip designer you get to do maybe 1 month a year of creative design and 11 months meeting timing and making damn sure that silicon will really work the first time - by the time you tape out you're really looking forward to that creative bit and about the time you've up to your armpits in it the silicon comes back and the firmware guys are doing bringup - you don't have a lot of time for the firmware guys because they're getting in the way of the cool part of your job, and besides you are sooo done with that chip you slaved over last year I don't know what the answer is other than making sure you have firmware running on your logic simulator long before tapeout (you should be doing that anyway)

akiselev 13y ago
Ooops yeah I chose the wrong words and painted way too broad. I meant version control as far as the firmware libraries and public facing code. I can't imagine going from FPGA to silicon synthesis is even possible without extremely tight version control of some sort or another (I think they used to use basic transperencies for comparing masks) I stand corrected as far as the average age of employees but every time I have interfaced with any level of a silicon company the average age distribution has been skewed pretty high.

bjackman 13y ago

22 year old working in firmware department of major silicon IP company here (you can probably guess who - obviously standard disclaimer about I don't represent them). My company selling IP rather than hardware makes it a bit easier, but: management is realistic and reasonably versatile. Attitude to proper technologies (e.g. using Github instead of releasing tar bombs over FTP) is good. Documentation is good, bar "don't document that or we will be sued" situations, which are too common. Testing sucks in certain areas but is good in most. Obviously at my age I don't have much experience, but I thought the alternative view might be nice.