5 ms·

All the FPGA tools by Xilinx work well under Linux and Vivado is actually quite pleasant to use. Almost all of the EDA tools can be scripted with TCL (cadence h

All the FPGA tools by Xilinx work well under Linux and Vivado is actually quite pleasant to use. Almost all of the EDA tools can be scripted with TCL (cadence has a host of other DSL aswell) so you don’t need to use the GUI if you don’t want to.

arghwhat 8y ago
Vivado is absolutely terrible, especially the GUI. Our toolchain at work is set up so that it can be entirely avoided, with developers only writing Verilog in their editor of choice, and calling make or pushing to Jenkins when they want results. And then they go home, as it takes a full day to build a product on our server farm. Sim/others is done with third-party products. I recall one Xilinx event where a Xilinx presenter asked how many people were using the Vivado IDE for development. IIRC, only a single hand was held up. Vivado isn't worse than the competition, though. Intel/Altera's offering is also a steaming pile of crap (we evaluate the competing platform every once in a while when we decide what FPGAs to use for new products). I don't know why all FPGA tooling sucks, but it does.
- xu3kev 8y ago
  Writing Verilog in the editor of choice then calling make and pushing to Jenkins sounds amazing. Could you elaborate further on the methods and best practices to develop FPGA without Vivado IDE?(As your story indicate that there are many people can do this in the industry.) I'd like to know more about the setup.
- planteen 8y ago
  And don't get me started on trying to version control a Vivado project. It's like they didn't even consider the possibility of committing a project to source control! I last used Vivado about 2 years ago but doubt things have changed much. It really makes me wonder how Xilinx does it in-house.
  - matt_the_bass 8y ago
    I was just about to say this! We’ve recently hacked our Vivado project into git. This requires unpacking all packages and ignoring compiled packages. Plus a bunch of bat files to handle house keeping. A big part of the issue is compiling packages. I think this is a thing because synthesis takes so long. Until synthesis time is reduced, I think we’ll see these hack-y solutions.
- lvoudour 8y ago
  Vivado is absolutely terrible, especially the GUI. Our toolchain at work is set up so that it can be entirely avoided, with developers only writing Verilog in their editor of choice, and calling make or pushing to Jenkins when they want results. And then they go home, as it takes a full day to build a product on our server farm. Sim/others is done with third-party products. That's how most companies do it in my experience (and I prefer it as well). That said, Vivado is leaps and bounds better than its predecessor (ISE). It may be horrible for HDL coding, but when you need to do timing analysis and floorplanning the GUI is really helpful and the integrated TCL command line makes it very flexible. Tooling in FPGA-land is a sad story, unfortunately. It's stuck in the 90's. I've ranted enough times to feel I'm beating a dead horse, but it's frustrating to see how behind the times it is compared to software development. Just look at HDL IDEs as an example: The vendor ones are worse than simple text editors, 3rd party IDEs cost an arm and a leg, while feature wise they are nowhere near their software counterparts. Take the most popular HDL IDEs (or should I say eclipse plugins?) and compare them with visual studio pro or jetbrains. The feature discrepancy is staggering (as is the price difference). We use Sigasi at work and while it's definitely better than a text editor, the basic version costs ~800$/yr and apart from error-checking, goto-definition and renaming there's not much else going on. For the same price you can get the whole jetbrains suite with a couple hundred dollars to spare.
  - dman 8y ago
    Is it possible that the market for software developers is larger than the fpga developer market hence allowing tool development costs to be amortized over a larger set of users.
    - lvoudour 8y ago
      That's true, but that doesn't explain why the HDL IDEs lack modern productivity features or why the simulator GUIs have the same interface as 20 years ago. Inertia and vendor lock-in are better explanations IMHO. I hope with FPGAs becoming more mainstream the open source/hobbyist community will step in and refine some things, but if the big EDA shops don't take hints from the software industry things are not going to change very fast.
- TomVDB 8y ago
  I don’t see how the quality of the IDE has any influence on what selection of FPGA to use. We select FPGAs based on HW features and that is that. The tools are more than good enough for debugging or to kick off an occasional custom synthesis run when you don’t have the time to wrap it in a Makefile.
  - planteen 8y ago
    The quality of the tool chain absolutely has bearing. You are essentially locked into using using the FPGA vendor's tools. And its not like there is much choice in FPGAs anyway. You have Xilinx, Altera, Lattice, and MicroSemi. In a small company with a low volume product, the engineer working with the FPGA has a ton of other duties. The speed with which you can knock out the FPGA is huge and the tools and available documentation play a large part in that.
    - TomVDB 8y ago
      I wrote "quality of IDE" not "quality of the toolchain" for a reason. In fact, let's reduce this to "quality of the editor." The text editors are absolutely terrible, but that's why they invented Vim. You're only a "Add File" away to work around that. Other than that, getting from Verilog to a design mapped to hardware is pretty trivial with both Quartus and Vivado. They both have excellent debugging tools with SignalTap and ChipScope, they have pin planners that works reasonably well. Synthesis and P&R results are decent. If your design is so generic that it really doesn't matter which FPGA you're using, then, sure, make your decision based on this kind of detail. But I find that to be almost never the case. Price, number of DSPs and their precision, amount of block RAM, performance of the SERDES units. Those are real decision makers.
      - davrosthedalek 8y ago
        In Vivado, you can actually tell it to spawn a different editor than the build in one. I use emacs. Much better.
      - planteen 8y ago
        Yeah, I know you can use vim. Text editing is not even close to where the major pain points are with Vivado. There's more to the workflow of developing a FPGA than adding files in Vivado. My experience went something like this: An hardware engineer needs to do a routine task like add a peripheral, swap some pin assignments, and modify the Verilog/VHDL. So they do all their synthesis and have an export ready to hand it off the the software engineer. They commit their changes and it probably causes differences in dozens of files, but so is life. It seems like this could be reduced to differences in a few human-readable files, except for the bitstream which obviously is binary. The SW engineer then needs to update the FSBL and BSP for the board. I never found a way to automate this on the command line, you needed to update the FSBL using their horrible Eclipse-based import tool. In my case, I had to make some manual modifications to the FSBL. I think for my modifications that I needed to flip some GPIO pins early in the boot process and also do some RSA validation on the bitstream. Well, all those modifications would get wiped out. I never found a way to template those and preserve them across new imports. So I had a bunch of differences that had to be manually merged every time. I had notes about it, but come on. What a pain. At the end of all of this, many dozens more files were changed. Once again, it seems like this should reduce to just handful of human-readable files like a FSBL configuration header / C file, the new U-Boot config, and the new kconfig. But instead you had two massive changesets in version control for some very routine work.

arghwhat 8y ago

Vivado is absolutely terrible, especially the GUI. Our toolchain at work is set up so that it can be entirely avoided, with developers only writing Verilog in their editor of choice, and calling make or pushing to Jenkins when they want results. And then they go home, as it takes a full day to build a product on our server farm. Sim/others is done with third-party products. I recall one Xilinx event where a Xilinx presenter asked how many people were using the Vivado IDE for development. IIRC, only a single hand was held up. Vivado isn't worse than the competition, though. Intel/Altera's offering is also a steaming pile of crap (we evaluate the competing platform every once in a while when we decide what FPGAs to use for new products). I don't know why all FPGA tooling sucks, but it does.

xu3kev 8y ago
Writing Verilog in the editor of choice then calling make and pushing to Jenkins sounds amazing. Could you elaborate further on the methods and best practices to develop FPGA without Vivado IDE?(As your story indicate that there are many people can do this in the industry.) I'd like to know more about the setup.
planteen 8y ago
And don't get me started on trying to version control a Vivado project. It's like they didn't even consider the possibility of committing a project to source control! I last used Vivado about 2 years ago but doubt things have changed much. It really makes me wonder how Xilinx does it in-house.
- matt_the_bass 8y ago
  I was just about to say this! We’ve recently hacked our Vivado project into git. This requires unpacking all packages and ignoring compiled packages. Plus a bunch of bat files to handle house keeping. A big part of the issue is compiling packages. I think this is a thing because synthesis takes so long. Until synthesis time is reduced, I think we’ll see these hack-y solutions.
lvoudour 8y ago
Vivado is absolutely terrible, especially the GUI. Our toolchain at work is set up so that it can be entirely avoided, with developers only writing Verilog in their editor of choice, and calling make or pushing to Jenkins when they want results. And then they go home, as it takes a full day to build a product on our server farm. Sim/others is done with third-party products. That's how most companies do it in my experience (and I prefer it as well). That said, Vivado is leaps and bounds better than its predecessor (ISE). It may be horrible for HDL coding, but when you need to do timing analysis and floorplanning the GUI is really helpful and the integrated TCL command line makes it very flexible. Tooling in FPGA-land is a sad story, unfortunately. It's stuck in the 90's. I've ranted enough times to feel I'm beating a dead horse, but it's frustrating to see how behind the times it is compared to software development. Just look at HDL IDEs as an example: The vendor ones are worse than simple text editors, 3rd party IDEs cost an arm and a leg, while feature wise they are nowhere near their software counterparts. Take the most popular HDL IDEs (or should I say eclipse plugins?) and compare them with visual studio pro or jetbrains. The feature discrepancy is staggering (as is the price difference). We use Sigasi at work and while it's definitely better than a text editor, the basic version costs ~800$/yr and apart from error-checking, goto-definition and renaming there's not much else going on. For the same price you can get the whole jetbrains suite with a couple hundred dollars to spare.
- dman 8y ago
  Is it possible that the market for software developers is larger than the fpga developer market hence allowing tool development costs to be amortized over a larger set of users.
  - lvoudour 8y ago
    That's true, but that doesn't explain why the HDL IDEs lack modern productivity features or why the simulator GUIs have the same interface as 20 years ago. Inertia and vendor lock-in are better explanations IMHO. I hope with FPGAs becoming more mainstream the open source/hobbyist community will step in and refine some things, but if the big EDA shops don't take hints from the software industry things are not going to change very fast.
TomVDB 8y ago
I don’t see how the quality of the IDE has any influence on what selection of FPGA to use. We select FPGAs based on HW features and that is that. The tools are more than good enough for debugging or to kick off an occasional custom synthesis run when you don’t have the time to wrap it in a Makefile.
- planteen 8y ago
  The quality of the tool chain absolutely has bearing. You are essentially locked into using using the FPGA vendor's tools. And its not like there is much choice in FPGAs anyway. You have Xilinx, Altera, Lattice, and MicroSemi. In a small company with a low volume product, the engineer working with the FPGA has a ton of other duties. The speed with which you can knock out the FPGA is huge and the tools and available documentation play a large part in that.
  - TomVDB 8y ago
    I wrote "quality of IDE" not "quality of the toolchain" for a reason. In fact, let's reduce this to "quality of the editor." The text editors are absolutely terrible, but that's why they invented Vim. You're only a "Add File" away to work around that. Other than that, getting from Verilog to a design mapped to hardware is pretty trivial with both Quartus and Vivado. They both have excellent debugging tools with SignalTap and ChipScope, they have pin planners that works reasonably well. Synthesis and P&R results are decent. If your design is so generic that it really doesn't matter which FPGA you're using, then, sure, make your decision based on this kind of detail. But I find that to be almost never the case. Price, number of DSPs and their precision, amount of block RAM, performance of the SERDES units. Those are real decision makers.
    - davrosthedalek 8y ago
      In Vivado, you can actually tell it to spawn a different editor than the build in one. I use emacs. Much better.
    - planteen 8y ago
      Yeah, I know you can use vim. Text editing is not even close to where the major pain points are with Vivado. There's more to the workflow of developing a FPGA than adding files in Vivado. My experience went something like this: An hardware engineer needs to do a routine task like add a peripheral, swap some pin assignments, and modify the Verilog/VHDL. So they do all their synthesis and have an export ready to hand it off the the software engineer. They commit their changes and it probably causes differences in dozens of files, but so is life. It seems like this could be reduced to differences in a few human-readable files, except for the bitstream which obviously is binary. The SW engineer then needs to update the FSBL and BSP for the board. I never found a way to automate this on the command line, you needed to update the FSBL using their horrible Eclipse-based import tool. In my case, I had to make some manual modifications to the FSBL. I think for my modifications that I needed to flip some GPIO pins early in the boot process and also do some RSA validation on the bitstream. Well, all those modifications would get wiped out. I never found a way to template those and preserve them across new imports. So I had a bunch of differences that had to be manually merged every time. I had notes about it, but come on. What a pain. At the end of all of this, many dozens more files were changed. Once again, it seems like this should reduce to just handful of human-readable files like a FSBL configuration header / C file, the new U-Boot config, and the new kconfig. But instead you had two massive changesets in version control for some very routine work.