Wait, if there are 11 percent fewer engineers working on communications and network equipment, and you attribute this to "the cloud," then what do you guys think "the cloud" consists of? Water vapor? :) (Pretty clever, if I may say so myself.)
Possibly, what you mean is that you get some economies of scale, if you consolidate some of the previous enterprise network services in a fewer number of giant "cloud" companies. Could be. The opposite side of that coin is that a whole lot more gadgets, appliances, etc., are now "connected." So one would expect that engineers knowledgeable about comms and networks would be in greater demand for the makers of these end products.
From my perspective, the use of RTOSs may have declined as faster processors have made embedded Linux work just fine for many real time applications. I very much doubt that real time performance matters less than before.
Also, ultimately the use of buzz words make a fashion statement. For example, designing web apps is "so yesterday." But designing apps for "the cloud," now you show you're really with it.
@Bert22306: I think the author is attempting to get his point across that enterprise networks and small to medium data centers are shrinking. This could explain the 11 percent fewer engineers working on networking equipment. If you put this in perspective of what is evolving in software defined networks, the job number can get worse in the coming years.
You are quite correct in your critique on buzz words -the industry is awash in it!
The drop in FPGA use is the most surprising to me. My initial thought was that this could be an indicator of increasing adoption of 32 bit MCUs; that more FPGA functionality was moving to software. That would make some sense, but the drop in current FPGA use over the same time frame is considerably more than the increase in 32 bit use.
I suppose it could be that the 32 bit processors are getting more capable at the same time and thus are more able to take on complex functionality, even if the numbers aren't changing much.
Duane, I really enjoyed your Design West talk "FPGAs: I know nothing... yet" which illustrated some of the challenges a newbie has getting into FPGA design. As someone who designs FPGAs professionally, I've gotten used to the eccentricities of FPGA design languages and tools and don't appreciate how bizarre it must seem to the new user.
Back to the topic, I think it's mostly a question of cost. Everybody is trying to drive down cost, so if there's any way to get the functionality onto a SoC, management will cajole engineers into doing it even if it's ugly. With increasing SoC performance, there are fewer functions that have to be in an FPGA to meet performance and/or latency requirements. A number of SoCs have some very interesting features for handling functions that would otherwise require an FPGA, such as TI's PRU (Programmable Real-Time Unit) available on the BeagleBone's Am3358/9 and NXP's SCT (State Configurable Timer). Plus, some small SoCs are so cheap that you can add another one in place of an FPGA.
(to be continued)
While FPGAs in principle are clean and simple, they have a pretty steep learning curve in practice. It can also be difficult to place them within a design organization. To take the best advantage of FPGAs, you need to have the flexibility to move functionality between hardware and software. Having one person doing digital hardware design, device-level software, and FPGA design simultaneously is one approach, but even if you have that designer he or she will be overwhelmed unless the design is clean and simple. Most organizations have separate hardware and software people, and where to place FPGAs can be problematic. Some people say FPGA design should be easy for software people -- after all, Verilog even looks like C. In fact, the similarity in syntax is misleading, because hardware design is a very different beast from software. Some say it's better to do FPGA design in VHDL precisely because it looks different from C.
The design challenges of FPGAs -- particularly for a company that doesn't already have an FPGA guru -- adds enough risk that many would rather make do with SoCs. I don't think the FPGA vendors realize how hard it it for a new user to use their tools. Their marketing materials all say how fast and easy it is, so there seems to be some denial going on here. JMO/YMMV
"Since 11% fewer engineers are working on communications equipment, which is a strong-hold market for FPGAs, I'm guessing there are fewer such projects, thus less demand for FPGAs." Agree with your point. here is my site.
Drones are, in essence, flying autonomous vehicles. Pros and cons surrounding drones today might well foreshadow the debate over the development of self-driving cars. In the context of a strongly regulated aviation industry, "self-flying" drones pose a fresh challenge. How safe is it to fly drones in different environments? Should drones be required for visual line of sight – as are piloted airplanes? Join EE Times' Junko Yoshida as she moderates a panel of drone experts.