4 ms·
> While lengthy, the process of compiling and getting something running on silicon didn't seem any more complicated than Grade/Maven etc all based Android Studi
by ThePadawan 8y ago
> While lengthy, the process of compiling and getting something running on silicon didn't seem any more complicated than Grade/Maven etc all based Android Studio builds.
I'm not sure many people would share your opinion that Gradle/Maven are uncomplicated.
Personally, I would say they belong to the 20% most complicated build toolchains I have encountered - which would make the FPGA process still not very uncomplicated in comparison.
- sfifs 8y ago> Personally, I would say they belong to the 20% most complicated build toolchains I have encountered I actually agree which is why I used that as a comparison. Over a million developers deal with it every day of their work lives and the FPGA tooling I dealt with did not seem any more complicated than something that's very mainstream.
- user5994461 8y agoMaven is just right click + build to build. Or file + import to import a project. The last time I worked with Vivado, I remember our interns couldn't manage to create a project or use an existing project after a whole week. It doesn't help that there are no tutorials from the vendor or the internet, or that projects can't be stored in source control.
- noselasd 8y agoMaven is that simple when someone have gone through all the pain of setting things up - but someone have to do that too - it is a battle for all but the very simplest of projects.
- analognoise 8y agoI went on an interview once where part of the process was "here is a development board. Here is a computer and the internet. Make a full adder, connect the inputs to push buttons and the outputs to LEDs. You have all day, by yourself, in a cubicle." I was told it cut out something like 95% of candidates who looked good on paper. It was an interesting approach.
- user5994461 8y agoThat's what the interns were trying to do. Get a push button to a LED working, on a Xilinx SoC, with the Vivado IDE. They couldn't figure it out in days. I don't blame them. I tried and couldn't get it working in a day either. We were lucky we found another guy in the company who worked with that board on a different project. He showed us and he had extensive notes to get the environment working. Embedded development really sucks.
- hak8or 8y agoNot all embedded. Thankfully there is a sort of standard embedded mcu arch showing up via arm (would love risc v but I'll take what I can get). This has support via mainline clang/llvm and gcc, and isn't much work to get a more modern setup going via cmake, c++17, and clion. But the amount of people who are still going the raw c route for often times unfounded reasons (c++ is slower or has more bloat), prefer one large c file, don't do code based testing, etc, in embedded is staggering. And for more niche areas (like FPGA) it's extremely behind the times. Not to say c is behind the times, it has its time and place, but 99% of the time they aren't bale to properly articulate it.
- monocasa 8y agoIronically enough, a lot of the people I've cut in the interview process seemed like working their way through Vivado, Lattice, etc. wizards was the only development they had ever done. They could get an env setup, but would be completely lost outside of a trivial hello world style project.
- analognoise 8y agoYeah, we had several interview questions specifically to weed those out too. A favorite was, "How would you design a multiplier, without a wizard/Coregen?" They didn't have to hit everything, but a couple of general multiplier design points - throughout and area? A MAC, or a straight multiplier? Shift add? Do they know enough to try to hit a certain primitive (DSP48E, fast carry chains?). The wizard-only designers frequently couldn't even understand the question, and were incapable of discussing tradeoffs of area/time/resources.