7 ms·

Actually I recently bought a Spartan 7 based FPGA board after taking the nand2tetris course and started playing with the free version of the Vivado suite. If

by sfifs 8y ago

Actually I recently bought a Spartan 7 based FPGA board after taking the nand2tetris course and started playing with the free version of the Vivado suite. If your complaint is principle based on the stuff being non free software, then it holds. If it's on usability - not sure it does. 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.

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 ago
  Maven 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 ago
    Maven 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 ago
    I 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 ago
      That'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 ago
        Not 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 ago
      Ironically 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 ago
mattnewton 8y ago
Gradle and maven aren’t the posterchild for easy development setups- I would instead look at a successful dynamic language like python, php, or the web with JavaScript. That being said, I’m also not sure the issue is entirely developer ergonomics. Personally I think the fact that the hardware is something you have to go out and buy versus just coming stock in your computer is more of a factor in developer onboarding, and the resulting mindshare.
davemp 8y ago
For basic implementations in ways intended by the vendor, I'm sure the supplied tools are fine. When you want to leave the sandbox and do interesting things, it's hard. I was thinking along the lines of writing your own tools that would require information about timings and chip resources/layouts. EDIT: your cpu ISA is open, but fpga layout/bit-stream is not--locking you to your vendor's innovation and ideas for how things should be done.
- rjsw 8y ago
  Lots of engineers manage to do interesting things with the vendor tools.
  - davemp 8y ago
    Mhm. I am aware. People did interesting things chipping away with rocks as well.
- esmi 8y ago
  What does leaving the sandbox mean when implementing an FPGA? I'm not aware of any soft resource one can't completely control in Vivado/Xilinx as every hard resource can be completely described in your own design via the primitive library. That doesn't mean it is always a good idea, but one can do it.
  - davemp 8y ago
    > described in your own design via the primitive library There's your sandbox EDIT: If you cannot replace their tools with yours, it is a sandbox.
    - duskwuff 8y ago
      The elements in the primitive library directly map to the hardware components available on the FPGA. There's no "sandbox" involved.
      - 8y ago
Shikadi 8y ago
Maybe for personal projects, but I find I spend more time dealing with vivado bugs than I do vhdl bugs. I spent four hours today just getting a simulation to run correctly in 2017.3 upgraded from 2016.1. My Co worker was simultaneously dealing with a bug where deleting a net in ECO was silently deleting other nets, and not necessarily causing an error. EE tools are the worst.
- lnsru 8y ago
  First rule of FPGA development: never ever upgrade IDE in the middle of the project. Even if it’s a move from 2016.x to 2017.y version it can cost 2 months of precious time just dealing with some nonsense migration stuff/broken projects/broken settings.
dkarl 8y ago
> didn't seem any more complicated than Grade/Maven etc all based Android Studio builds Can you say anything nicer about it than that? I've used Make, ant, and cmake, I've built and packaged multiplatform GUI apps using Eclipse RCP, I've built modern web apps using npm and babel, and building Android apps was the single worst experience out of all of them. Comparing a toolchain to Android sounds more like a takedown than a defense.

by sfifs 8y ago

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 ago
Maven 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 ago
  Maven 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 ago
  I 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 ago
    That'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 ago
      Not 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 ago
    Ironically 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 ago

mattnewton 8y ago

Gradle and maven aren’t the posterchild for easy development setups- I would instead look at a successful dynamic language like python, php, or the web with JavaScript. That being said, I’m also not sure the issue is entirely developer ergonomics. Personally I think the fact that the hardware is something you have to go out and buy versus just coming stock in your computer is more of a factor in developer onboarding, and the resulting mindshare.

davemp 8y ago

For basic implementations in ways intended by the vendor, I'm sure the supplied tools are fine. When you want to leave the sandbox and do interesting things, it's hard. I was thinking along the lines of writing your own tools that would require information about timings and chip resources/layouts. EDIT: your cpu ISA is open, but fpga layout/bit-stream is not--locking you to your vendor's innovation and ideas for how things should be done.

rjsw 8y ago
Lots of engineers manage to do interesting things with the vendor tools.
- davemp 8y ago
  Mhm. I am aware. People did interesting things chipping away with rocks as well.
esmi 8y ago
What does leaving the sandbox mean when implementing an FPGA? I'm not aware of any soft resource one can't completely control in Vivado/Xilinx as every hard resource can be completely described in your own design via the primitive library. That doesn't mean it is always a good idea, but one can do it.
- davemp 8y ago
  > described in your own design via the primitive library There's your sandbox EDIT: If you cannot replace their tools with yours, it is a sandbox.
  - duskwuff 8y ago
    The elements in the primitive library directly map to the hardware components available on the FPGA. There's no "sandbox" involved.
    - 8y ago

Shikadi 8y ago

Maybe for personal projects, but I find I spend more time dealing with vivado bugs than I do vhdl bugs. I spent four hours today just getting a simulation to run correctly in 2017.3 upgraded from 2016.1. My Co worker was simultaneously dealing with a bug where deleting a net in ECO was silently deleting other nets, and not necessarily causing an error. EE tools are the worst.

lnsru 8y ago
First rule of FPGA development: never ever upgrade IDE in the middle of the project. Even if it’s a move from 2016.x to 2017.y version it can cost 2 months of precious time just dealing with some nonsense migration stuff/broken projects/broken settings.

dkarl 8y ago

> didn't seem any more complicated than Grade/Maven etc all based Android Studio builds Can you say anything nicer about it than that? I've used Make, ant, and cmake, I've built and packaged multiplatform GUI apps using Eclipse RCP, I've built modern web apps using npm and babel, and building Android apps was the single worst experience out of all of them. Comparing a toolchain to Android sounds more like a takedown than a defense.