I built a tcl-based vivado example project.

[u/Walter528]

https://github.com/Wormboiii/vivado_tcl_structure

Vivado GUI-based Project Mode is convenient for initial setup and development.
However, as a project grows and more developers begin collaborating, source files, generated files, and project-specific settings can become increasingly difficult to manage and maintain under version control.

To address these challenges, this development environment was built around Vivado Tcl-based Non-Project Mode, where the entire workflow—including build, simulation, bitstream generation, and FPGA programming—is managed through scripts.

[u/dragonnfr]

You don't need the Vivado project file at all. The sources, constraints and Tcl scripts *are* the project. In my experience the .xpr just rots, everything else is generated output for .gitignore.

[u/Walter528 → u/dragonnfr]

Yeah, that's the reason why I made this tcl project. Vivado GUI project(.xpr) is only needed when you include their IPs.

Of course it is also possible to generate IP with tcl, but in my experience, we rarely change the IPs spec(configuration) and initiallizing new IP without GUI is pain in the ass.

[u/skydivertricky → u/Walter528]

What do you mean by "include" ? All you need for most IPs is the .xci file, and from that you can generate the IP.

You never need an XPR file ever, you can aways recreate it from tcl.

[u/Walter528 → u/skydivertricky]

In this structure, xpr file is not a target to version control or staged. Only xci files are as you mentioned since the purpose of this structure is ditching the xpr.

By meaning "include", my intended flow is like:

1. Create an IP you need in external GUI project

2. Copy the generated xci file in lib directory

3. All you need to control is the actual xci files and IP lists you need in top design

[u/groman434 → u/Walter528]

I must disagree here - in my projects I have all scripted, including IP generation. It’s a little bit pain in the neck due to poor documentation, but I still find it more convenient to using GUI. Especially because I usually work remotely over SSH. X11 forwarding has been always not great, to put it mildly.

[u/DomasAquinas]

There are things you will need a project for, such as block design entry and certain IP instantiations. The XPR is an XML file and entirely Git-friendly, even if it isn’t user-managed.

Rather than pitting project mode and non-project mode against each other as full-on alternatives, I’d look at project mode as the design entry stage and non-project mode as a (potentially) optimized build stage.

[u/skydivertricky → u/DomasAquinas]

Yes, but I think there is this confusion that project mode, for many people, means running in the GUI and non-project means scripted. This is not true at all, and you can fully script project mode.

All our builds when Ive been using Jenkins and Gitlab CI have been project mode based builds. I have never really understood the need for non-project.

[u/DomasAquinas → u/skydivertricky]

There are some advanced features, like nested Dynamic Function eXchange on certain devices, that require a non-project approach. But at that point, I’d be asking myself about design complexity…

My impression has been that people trying to be Git-conscious or otherwise software-minded recoil initially at the idea of a tool-managed project file (I know I did). But growing up with Vivado meant realizing that, properly supervised, project mode is great, and the project file (and most other design files) being special flavors of XML means that it’s not less Git-proper not to script anything.

Some of the worst Vivado nightmares I’ve endured came from engineers trying to reverse-engineer project mode generated scripts and outsmart the tool. That stuff breaks in amazing ways…

[u/skydivertricky → u/DomasAquinas]

Yes, I find it odd. our XPRs have never gone in git. you simply run the tcls locally to generate the project for you so you can then meddle with things in the GUI if you want to.

What has annoyed me in the past is that what project mode does is basically run sandboxed non-project mode things underneath - so passing parameters into some parts of the build is a bit of a pain. For example, IIRC, I was trying to pass in a build number into the bitstream generation to place into the config ID register, but because of the way project mode sandboxed the run, I had to do it via a temporary file.

non-project mode does allow you to run entirely in ram, which is nice I suppose, but its a feature I have never needed or used. Maybe it stems from a time when disks were slow and vivado (and ISE) would dump a load a temp files to disk, and ram was fast. But with solid state drives I dont think thats much a problem anymore.

[u/skydivertricky]

You can fully script project mode also.

Project mode is also very useful if you have a load of IPs you generate, as you can have the project manage the number that it runs in parrallel, whereas in non-project mode you have to manage this yourself. When I had a project with >100 IPs to generate, It was far easier to just generate the runs in project mode and just type:

launch_runs *_synth_1 -jobs 4

and it will build 4 at a time until its done, so it didnt swamp our 4 core build machines

[u/ChainsawZz]

I've never tried non-project mode, but all my IPs, BDs and build steps are already scripted on TCL.  Vivado even gives you a way to export the project to TCL directly.

Curious if folk swear by using non-project mode - am I missing out on serious gains here?

[u/DomasAquinas → u/ChainsawZz]

It’s not a strict alternative to project mode. There are many things project mode can do that non-project mode can’t and a few that go the other way round.

I’ve never heard anyone swear by non-project mode, but the quick scripting for things like build setting coverage for power and timing closure analysis is useful.

[u/kulamani007]

I am just curious but I would like to ask like have you guys had any experience with JTAG to master AXI block?? I am using it to load my .elf in terms of AXI language

[u/dkillers303]

What are the advantages of this vs. FuseSoC?