
How to set up Xilinx Vivado for source control - jhallenworld
https://github.com/jhallen/vivado_setup
======
cmrdporcupine
Use fusesoc.
[https://github.com/olofk/fusesoc](https://github.com/olofk/fusesoc)

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.

------
tcherasaro
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.

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...](https://www.xilinx.com/support/documentation/application_notes/xapp1165.pdf)

And, Chapter 5 in Xilinx User Guide 892 is "Source Management and Revision
Control Recommendations"
[https://www.xilinx.com/support/documentation/sw_manuals/xili...](https://www.xilinx.com/support/documentation/sw_manuals/xilinx2019_1/ug892-vivado-
design-flows-overview.pdf)

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](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.

------
stefan_
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.

~~~
aidenn0
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.

------
dwoozle
You mean the multi tens of thousand dollar FPGA set up that Xilinx hawks
doesn’t have source control?

~~~
odmkSeijin
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.

~~~
moftz
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.

------
Traster
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)

------
kraigher
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](https://gitlab.com/truestream/tsfpga)

~~~
cmrdporcupine
fusesoc is another one.

------
bisrig
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!

------
navidr
Why they would use tcl? Why not something more cleaner?

~~~
saagarjha
Because that's what Vivado uses for scripting?

------
unixhero
Off topic: Is this a good time to buy Xilinx shares? I seem to hear their
name, and talk about synthesis every week on here now.

~~~
unlinked_dll
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.

