How to prevent Vivado from modifying XDC files without my permission?

[alexis_jp]

I'm encountering an excessively annoying behavior as usual with Vivado 2020.1.

I have several xdc files defining constraints used or not.

1. Vivado always adds an useless empty line after all the xdc files. Some files have tens of empty lines for nothing.

2. Vivado modifies and deletes lines of my XDC files without my permission.

Fortunately we use git to keep track of our code and we didn't loose anything but that behavior is intolerable.

Project is created with a tcl: add_files -fileset constrs_1

I don't want Vivado to remove constraints that will be used in the future.

How to stop that non-sense behavior?

I consider that Vivado shouldn't change any user files EVER. Why isn't it obvious for Xilinx?
gcc/clang/whatever compiler have never changed a single character of the source files.

[alexis_jp]

@archangel-lightworks

I'll be very clear.

* What is an FPGA doesn't matter here. In fact, that's very similar, the user has files and an application processes these files.

* A design that is more than 2 buttons and 4LEDs is obviously changing during development phase, your statement is infinitely wrong.

* A constraint file isn't a generated file at all and is definitely a user source file that belongs to the user only.

* The way I handle my xdc files is exclusively my business and has nothing to do with the non-sense Vivado's behavior.

* An XDC file can define all the pins, timings and clocks of a board. Unlike a design, that file should never be changed or it just becomes error-prone.

Vivado can do whatever it wants to with its generated files but it should NEVER alter any of the user files.

That's a sick development choice/policy, I can't recall any other application doing so without letting the user know.

Moreover, I'd like to meet the dev or her/his techlead who thought deleting lines rather than commenting them is a good idea.

[richardhead · Accepted solution]

If you load the .xdc file as unmanaged then Vivado will not modify it. It also gives you the benefit of being able to add all sorts of TCL to your XDC files. Im not sure if you can do this via the gui, but you can do it via the following tcl command:

read_xdc -unmanaged <some_xdc_file>

It is very annoying vivado modifying your nicely laid out XDC.

@archangel-lightworks 

That comment isnt very helpful. XDCs are NOT generated files, they can easily be written and managed by a user. While Vivado does like to control things for you, it can get very annoying. XDC should be treated as any other sources.

[alexis_jp]

@archangel-lightworks  Sure, that's the best mindset to improve an application. I'm dreaming of being able to choose unfortunately, I'm not a student playing with 50$ boards.

@richardheadThanks for that much more constructive answer.

In the end, I found the reason.

On that new project, the board's XDC file was set as target. In all our projects, we have an ila.xdc to be used as the target file.

From my experience, I knew it was replacing the tcl commands for the ILA but I didn't expect it was also giving Vivado the freedom to also parts that haven't been generated by Vivado.

The problem with read_xdc is that it's read only when the project is generated, if we change it after that, Vivado doesn't read the new version automatically. Of course I could add read_xdc in tcl.pre.

I'll come back here after some experiments.

Thanks again!

[alexis_jp]

@archangel-lightworks 

Each team has a different workflow, a workflow that is fighting against a tool isn't a good workflow.

make will never alter a makefile, cmake will never alter a cmakefile. Is it a better analogy for you?

What if you didn't commit your change that just got deleted by Vivado?! Comments help the user to see there is a problem somewhere rather than just wondering where all the lines went to.

git is used to control the versions, not each single word you wrote and definitely not to save you from Vivado.

I tend to expect the tool I used for thousands dollars chips to be time-saver, not time-consumer.

Anyway, in that case, it might be my fault not having seen the xdc file was automatically set as target.

Thanks for your participation anyway! I still appreciate to see other's mindset.

[alexis_jp]

---

@archangel-lightworks wrote:

"I'm not a student playing with 50$ boards"

Like most of us, no surprise. Are you a Fortune 50 CEO with a multi-billion project on the table to tell Xilinx what is tolerable and what isn't?

---

In that case why do you tell me Vivado isn't for me and I should switch to Intel?

Whatever you think, however I asked it, my question is legit for people who want to improve their workflow and improve a tool they use every day.

[alexis_jp]

Another solution: Just rename the .xdc to .tcl and it has the same effect but Vivado won't modify the files anymore. (xdc files are managed, tcls aren't)

I like this solution because I never use the GUI to add constraints except for ILA but I use a specific ila.xdc file for that.

[maps-mpls]

What I do:

1.  create a target.xdc file and make it the target.

2.  When using the Constraints Wizard, never allow Vivado to save the constraints for you, as it will change constraints not only in the target constraint file, but it will surreptitiously rewrite all constraint files, deleting some comments, variables, evaluating expressions and turning results into magic numbers, etc..  And whomever made that technical decision to have the Constraints wizard do that to constraint files, especially those that are not the target constraint file, is is at best a technical Calamity Jane.  But whether there through malice, idiocy, or incompetence--it doesn't matter, the effect is the same.  The Constraints Wizard save constraints can rightly be considered malware with regard to non-target constraint files, in my opinion.  The constraints wizard is useful for review of constraints you might have missed, just don't let it save constraints for you.   I've been reporting this issue for some time and Xilinx should address this issue as it causes its new customers a great deal of trouble, delaying projects, pushing out the time when customers will be ready for production and wanting to buy Xilinx parts in bulk.  I haven't tested on 2020.1 and 2020.2 because frankly, I don't have time to do basic testing on behalf of a large corporation that should diligently be done as part of the Vivado release process.  For all I know they fixed it.  I hope they did at least.

[alexis_jp]

@maps-mplsThank you for the share.

That was my workflow before but I almost never use the Constraints Wizard. Vivado modifies your xdc files even though you never open the Constraints Wizard.

I fully completely agree with your last comment, that's a shame.

The Constraints Wizard problem might be fixed but we use 2020.1 and Vivado kept modifying our xdc files.

I don't even talk about the hundreds of empty lines we discovered at the end of our XDC files because Vivado adds them for no reason. I wonder how hard it is to make the user files read-only...