Whilst I applaud the effort, could someone explain why this is preferable to the scripting flow?
I agree you need to do pin-planning and possibly play with constraints, but all of that is possible from a post-synthesis design checkpoint. The advantage of OOC flow is it's scriptable, reproducible, you can parallelise different place and route strategies if you're really stuck. This advice about IP in out of context mode is good though - you need that whether you're scripting or using the UI.
The only thing that really grinds my gears about source control is that checkpoints are 50-100MB, so it's not great if you want to incrementally place and route (which is often a nice time saver)
There are several open source tools that can generate a Vivado project from a high level description that can be version controlled. One example is https://gitlab.com/truestream/tsfpga
This is one of the reasons I jumped ship from writing VHDL for Xilinx parts and am now a Java dev. It’s worth noting that Altera, the other major FPGA vendor, is not noticeably better in this regard (or at least they weren’t when I last used their stuff ~5 years ago).
(The other reason is that I am unbelievably bad at getting the damn thing to meet timing.)
Not with the same exact source files / same software version. But sometimes small changes in the design, or changing tool versions can cause the design to not meet timing. It's just the nature of map / place and route.
It often is. Place-and-route is typically implemented as simulated annealing, which is a randomized algorithm. Unless you explicitly force it to reuse the same seed, you'll get slightly different results each time -- and even if you do set a seed, small changes to the HDL may result in a vastly different result.
I understand there is some validity with this criticism. Xilinx has always been slow to adopt standard software development practices. But really, Xilinx tools have never cost 'multi-tens of thousand dollar's. The most expensive tools are several thousand dollars. There are also free tools for smaller devices / certain flows. Source control is done with tcl scripting (simple text files) and standard source control tools. It's not as bad as it was in the past. Cheers.
Microsemi Libero is a joke and is probably the greatest hindrance to getting actual work done. I wish Xilinx bought them out instead of Microchip so there could actually be some improvement to the tools. You can throw every bit of computing resource at it's dinosaur PnR tool and it will just happily chug along at 1% CPU usage. They just came out with some update that made a 20% improvement to PnR, literally hours of time gained back from watching a wheel spin. What is it doing? Who knows, it will probably fail and not tell you why. Zero source control, almost zero documentation for scripting, and a design tool that seems nearly crash everything just to tell you there are IP core updates available.
The only parts that actually work reliably are whatever ancient Actel-branded tools are hidden in the suite.
People like to lambast "enterprisey" software on HN, but it's got nothing on the typical software written by a hardware company.
In their defense, nobody is buying FPGAs for the tooling, so "just good enough to check the boxes" is probably the correct economic decision with the current state of affairs, since it's probably 10x as expensive to write software that is actually pleasant to use, and while they sell a lot of FPGAs, they don't sell very many FPGA dev tools, so the economies of scale aren't there.
I have been through a similar process myself a couple years back, and just wanted to say that this is a really good effort in trying to tame a beast that doesn't really want to be tamed. Lots of experimenting around with write_project_tcl and figuring out what settings are needed to coerce the tool into making version control/CI friendly decisions. Nice work!
They made a nice effort in dressing it up but you can just see the shitty Eclipse scream at you, it's deafening. The biggest tell is when they invariably copy the abominable Eclipse "wizard" flows.
I'm told Eclipse is actually good for Java, but there are so many shitty adaptations of Eclipse to a hardware-vendor's toolchain that it's really tarnished the brand image for me.
Use your own editor and source control tools outside of Xilinx's 1990s straightjacket. It creates Vivado projects and invokes it to do synthesis. You can open the generated projects in Vivado if you really need their GUI.
Chip stocks are soaring, so no. They’re coming due for a market correction.
There’s also a lot of volatility these days since all chip stocks rise and fall with trade news related to China. If you know or have faith that the trade tensions between the West and China are going to be resolved in the near future, buy. If you don’t, stay away.
Xilinx/Altera/Lattice have never found a real high volume mass market.
Xilinx for example is trying to push for cloud storage and AI applications but the reality is that if your are not worried about power consumption, then the development time/cost will be far less if you just use a GPU+CPU instead.
Unless you are doing nanosecond high criticality i/o or signal processing that benefits from high parallelization then FPGA's are probably overengineering.
FPGA Pro here. I checked out the README.md to see if I could pick up any tips. It is a good guide for a first time through, but I recommend also reviewing the Xilix documentation on this.
A few words of warning here:
The documentation recommends using the write_project_tcl and write_bd_tcl scripts. I have experienced problems with both of these not faithfully recreating the .xpr and .bd files so exercise caution with them. A better approach is to avoid .xpr files and to use a non-project or scripted flow. If you have to use a Vivado project for some reason (I can think of a couple) then create and maintain tcl script to generate the project by hand. One can use the write_project_tcl to get started and then update it by copying the tcl generated by Vivado after each GUI operation out of the Vivado tcl console into the project generation script when making changes to the project one wants to keep.
I have had the most problems with write_bd_tcl so I am now experimenting with just checking in the .bd file and setting the .bd extension to "binary" and various merge strategies in the .gitattributes file after several projects worth of frustration with the write_xx_tcl nonsense.
Finally, take all other Xilinx recommendation of source files to check in with a grain of salt. The documentation recommends checking in way too much. I recommend sticking with the "Minimum Set of Source Files to Manage" with archival backups of all output products for critical tags (eg. releases) somewhere outside the VCS.
23 comments
[ 3.4 ms ] story [ 61.6 ms ] threadI agree you need to do pin-planning and possibly play with constraints, but all of that is possible from a post-synthesis design checkpoint. The advantage of OOC flow is it's scriptable, reproducible, you can parallelise different place and route strategies if you're really stuck. This advice about IP in out of context mode is good though - you need that whether you're scripting or using the UI.
The only thing that really grinds my gears about source control is that checkpoints are 50-100MB, so it's not great if you want to incrementally place and route (which is often a nice time saver)
(The other reason is that I am unbelievably bad at getting the damn thing to meet timing.)
[1] https://symbiflow.github.io
[2] https://github.com/SymbiFlow
The only parts that actually work reliably are whatever ancient Actel-branded tools are hidden in the suite.
In their defense, nobody is buying FPGAs for the tooling, so "just good enough to check the boxes" is probably the correct economic decision with the current state of affairs, since it's probably 10x as expensive to write software that is actually pleasant to use, and while they sell a lot of FPGAs, they don't sell very many FPGA dev tools, so the economies of scale aren't there.
Use your own editor and source control tools outside of Xilinx's 1990s straightjacket. It creates Vivado projects and invokes it to do synthesis. You can open the generated projects in Vivado if you really need their GUI.
There’s also a lot of volatility these days since all chip stocks rise and fall with trade news related to China. If you know or have faith that the trade tensions between the West and China are going to be resolved in the near future, buy. If you don’t, stay away.
Xilinx/Altera/Lattice have never found a real high volume mass market.
Xilinx for example is trying to push for cloud storage and AI applications but the reality is that if your are not worried about power consumption, then the development time/cost will be far less if you just use a GPU+CPU instead.
Unless you are doing nanosecond high criticality i/o or signal processing that benefits from high parallelization then FPGA's are probably overengineering.
There's Xilinx App Note 1165 [Circa 2013] which is getting long in the tooth but still valid: https://www.xilinx.com/support/documentation/application_not...
And, Chapter 5 in Xilinx User Guide 892 is "Source Management and Revision Control Recommendations" https://www.xilinx.com/support/documentation/sw_manuals/xili...
There is also a .gitignore example which can be helpful but is not geared towards a minimal file set without alot of tweaking: https://www.xilinx.com/support/answers/61232.html
A few words of warning here: The documentation recommends using the write_project_tcl and write_bd_tcl scripts. I have experienced problems with both of these not faithfully recreating the .xpr and .bd files so exercise caution with them. A better approach is to avoid .xpr files and to use a non-project or scripted flow. If you have to use a Vivado project for some reason (I can think of a couple) then create and maintain tcl script to generate the project by hand. One can use the write_project_tcl to get started and then update it by copying the tcl generated by Vivado after each GUI operation out of the Vivado tcl console into the project generation script when making changes to the project one wants to keep.
I have had the most problems with write_bd_tcl so I am now experimenting with just checking in the .bd file and setting the .bd extension to "binary" and various merge strategies in the .gitattributes file after several projects worth of frustration with the write_xx_tcl nonsense.
Finally, take all other Xilinx recommendation of source files to check in with a grain of salt. The documentation recommends checking in way too much. I recommend sticking with the "Minimum Set of Source Files to Manage" with archival backups of all output products for critical tags (eg. releases) somewhere outside the VCS.