16 ms·

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

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.
  - gluggymug 8y ago
    I believe Tcl scripts can help automate your FSBL and BSP changes. Pretty much everything you do in the GUI translates to Tcl commands.

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.
- gluggymug 8y ago
  I believe Tcl scripts can help automate your FSBL and BSP changes. Pretty much everything you do in the GUI translates to Tcl commands.