It also depends on what you're the go-to person on and what the promoted position is. Being the expert on some low-level technology isn't necessarily going to help you get promoted to a managerial position or the upper tiers of technical positions.
While full bandwidth applications certainly exist, it is rare. Most direct sampling schemes are used for having a purely digital RF front end within the Nyquist range of the ADC/DACs. It's cheaper and easier to develop firmware/gateware than debug analog RF issues and respin hardware.
I have noticed it is harder for getting people straight out of college used to a professional working environment. However, I haven't noticed any difference in getting them up to speed technically.
This type of debugging is fine for people just starting out or hobbyists but won't be useful if you're trying to design HDL professionally. You really need to be able to create accurate simulations so you're not debugging on hardware the entire time. Hardware debugging takes a long time (builds can take hours) and you're more limited in terms of how many signals you can view/how many samples you can take.
Part of the purpose of the document is to sabotage surreptitiously. If you always take shortcuts and something gets messed up, it's easy for people to see that you were the cause. However, if you always insist on doing things through the proper channels then it's a lot harder for people to see that you're the problem or argue against your methodology.
It's a slow beginning. Tolkien focuses a lot on Hobbit culture as it's important to the morality of the narrative but it picks up very quickly. Oftentimes important events are only briefly summarized by one character to another as they meet up or narrated in brief chapters. That said, his writing style definitely isn't for everyone.
I understand what you mean about Tolkien, he describes seemingly random crap at length and doesn't really care about the plot, but it's not really accurate to call him verbose. The entirety of the Lord of the Rings has less words than two ASOIAF books or WoT books. I recently re-read LotR for the first time since childhood and what struck me is just how compact they are compared to modern fantasy.
Writing a 'book' early in your career definitely sounds like it could open doors but that's a clear edge case. I'm talking about internal documentation. I don't think it's reasonable to put the entire onus of communication on the writer and I've never seen a company value engineers who put large amounts of time into perfecting documentation.
It's completely alien to me that people here seem to believe engineers should be spending time making requirements and architecture documents more engaging. You're paid to read the thing, just read it.
There is no amount of writing skill that allows people to read complex technical documentation without any effort put into reading comprehension. All you're going to do is put your own career on hold as people see you putting large amounts of effort into nothing productive. Dave gets his documentation done in a sprint, why can't you?
In my experience, writing skill rarely matters as much as people think. A large portion of my coworkers won't bother to read what anyone wrote or put effort into comprehending it. I try to make good documentation but I know it's pretty much just for my future self.
But why not just create it directly? To use the article's example, you can just directly fill in or ask questions about the upper triangle of the matrix below. Adding in the anti-requirements just adds the possibility of missing a combination.
I don't understand the benefit of anti-requirements. It seems trivial to put your attributes in a matrix and identify relationships between them. Randomly making up requirements doesn't seem effective
Coarse Grained Reconfigurable Arrays (CGRAs) are the only way I see accelerators taking off. They reconfigure a lot faster and I believe they have better area utilization at the expense of bit-level programmability. I don't see many use cases for the FPGAs bit-level reconfiguration in an accelerator anyway so I doubt it would be missed.
Having lived on both sides of the fence, I feel comfortable blaming the EEs. Many are allergic to basic scripting, don't bother to learn how their tools work, and have an elitist attitude towards other design responsibilities (ex. layout, verification).
P.S Set up Vivado in scripted mode with either an in-memory project or non-project mode. It works like a champ.
A lot of the simulation software for PCB design is stuck in the 90s. The core of the simulation hasn't changed so it's not too big of a deal from a results perspective. However, it integrates terribly into the workflow so designers only simulate a small portion of a design and there's little automatic checks and things.
Left-libertarianism is a subset of socialism. Socialism is a wide umbrella term for multiple economic systems that put the people doing the work in charge of the workplace. It has nothing directly to do with a 'harmonious society'
From a professional perspective, I have a general annoyance towards raspi or embedded linux more generally. I have been part of multiple projects where there was a push towards prototyping/initial release on Pis and SOMs when a simple MCU was all that was required. It enabled a metric ton of bloat that made debugging the system a nightmare and made it impossible to easily port the software to a simpler hardware setup. Software grows to fit the available hardware.
Not that kind of emergency. AM Radio stations are used for disseminating information about weather and road conditions during weather events and natural disasters. Around where I live, there are signs that say "Tune to XXXAM when this light is flashing"
That's the intended purpose and origination of these systems. In a traditional hardware firm, marketing is constantly coming up with ideas but you can't constantly change hardware without delaying the project. So you come up with an engineering change request system. This forces marketing to go through a bit of bureaucratic pain every time they want to add something to the project. The committee acts as a gatekeeper but mostly, that little bit of extra work makes marketing self-select the more important ideas to go through the process.
I don't think I really agree with that characterization. To take PCB design as an example, you could just as easily say that once you have your blueprints (i.e. manufacturing files) then you're done. I see two big differences between SW/HW. The first is that software has a free and fast iteration loop whereas that same feedback loop would cost 2+ weeks and $10k on a PCB design. This makes it so that upfront design and analysis is more reasonable than try it and see. The second is that SW team structures appear to be much more coupled and interdependent. Multiple hardware designers can work for months on the same project without having to communicate much with anyone whereas this seems rare for SW teams. This causes the interdependencies between personnel to be highly predictable even if the work itself is not predictable.
I've been through a couple attempted transitions to agile for hardware. There are some agile elements that I think could work in hardware development but the people pushing the changes have always been too stubborn to recognize when SW agile methods just don't make sense for HW.