cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
tigi
Contributor
Contributor
956 Views
Registered: ‎01-17-2018

Rant about vivado directory structure

The way Vivado (2019.1 in my case) moves source files to newly created directory (typically import/<some_project_name>, or /new/) is very confusing to me, and it has been reported in other messages in the forum.

But to make things worse, when i run simulations now i get these errors:

  ERROR: [XSIM 43-4316] Can not find file...

and i have been able to trace the problem to the fact that Vivado has moved sources to a new directory, and then the vivado simulator can not find the files in the new directory.

This is crazy, and it should be fixed.

 

11 Replies
devinl
Community Manager
Community Manager
780 Views
Registered: ‎05-08-2017

Hi @tigi ,

We do greatly appreciate your feedback and have documented this to be looked into.

Thank you,
Devin

spaceboy
Visitor
Visitor
611 Views
Registered: ‎03-08-2021

Le me add to your rant, Tigi. The Vivado tool has many good features, but clarity and transparency are not amongst them.

WHy this crazy, arbitrary and esoteric directory structure. Where are my files? It's all very well tpo say it makes untrained users capable of designing FPGAs. I like to see my source files and commands, tcl scripts etc. The worst of all this is that the end up being multiple copies of files. Now I am sure you have very good reasons ofr thios, probably ease of S/W devleopment.

 

So, I have two suggestions:

 

1. Publish a detailed description of the directory structure and how it works.

2. Give users the option to create their own directory structures, such as source code; build;tcl;etc.

Why this is particularly important is that if I use an external simulator, or some other tool, or even hand the design out to different people to create specific modules, how do I maintain all the variants?.

maps-mpls
Mentor
Mentor
559 Views
Registered: ‎06-20-2017

Just a tip... (if you don't like it, no need to be offended--and this is not directored toward anybody on this thread, but others who seem to get their undies in a bunch unless you say things like "I feel like 2 + 2 = 4")

Anyway, I create my own directory structure, and when I add the files to the project, I uncheck the box "copy files into project".  This is better in my view especially if you use revision control.

Works everywhere for me except (last time I tried) in the create and package new IP project.  But I have other ways to deal with that (scripted up the create and package IP flow).

*** Destination: Rapid design and development cycles *** Unappreciated answers get deleted, unappreciative OPs get put on ignored list ***
dpaul24
Scholar
Scholar
555 Views
Registered: ‎08-07-2014

@maps-mpls ,

Anyway, I create my own directory structure, and when I add the files to the project, I uncheck the box "copy files into project". This is better in my view especially if you use revision control.

+1, same style here!

------------FPGA enthusiast------------
Consider giving "Kudos" if you like my answer. Please mark my post "Accept as solution" if my answer has solved your problem

bitjockey
Adventurer
Adventurer
499 Views
Registered: ‎03-21-2011

Vivado is horrible with version control and seems to fight it every step of the way.  It's 2021 and yet Xilinx still doesn't seem to grok relative file paths.  So if I try to check in a project I was working on in C:/Projects/MyProject/ and a coworker does an svn/git checkout to C:/Review/BitjockeysProject/ on his machine it will not work.  We have to resort to using external tools and command line tricks to make our projects and block diagrams etc. portable.  Such as making a "run me once.tcl" in source control that creates the project locally only and adds the controlled files into it (actually more like run_me_any_time_a_new_file_was_added_and_introduced_to_source_control_to_update_your_local_absolute_path_based_vivado_project.tcl that has to be remembered to be edited every time you add a file to a project.)   You then can't change the project or block diagram and then check it in, you must copy the tcl command equivalents into the script or other developers will not get the changes.

Even on a common build server we may want to fork a project and check out a branch in a different directory to work on.

And the idea of a "make it portable" "packager" that you run every check in is not a practical solution.

0 Kudos
spaceboy
Visitor
Visitor
475 Views
Registered: ‎03-08-2021

Well thank you for that tip; I'll look for that tick-box. But, also, I would like to be able to redirect the Xilinx IP code to a specific directory that I can gather together with the rest of the source code for a complete design. Note: I consider constraints as source code. Under ISE I had developed  a solid directory structure for my projects. Source code,  testbenches, simulations runs and FPGA builds were all kept separate from each other; and there was only one copy of each file. Now there is just an undocumented heap of directories which need explanation or a way of directing results to specific locations.

0 Kudos
spaceboy
Visitor
Visitor
470 Views
Registered: ‎03-08-2021

To further add a suggestion: How about allowing the user the option of specifying which directories source code, IP files, tcl scripts, program command lines, etc. be placed in. It is important for different, independent, tools to be able to access the design independtly of Xilinx software. Especially if the development is part of an ASIC or IC development project where many other tools will need to access the source files, and modify them.

0 Kudos
spaceboy
Visitor
Visitor
470 Views
Registered: ‎03-08-2021

Don't suggest to Xilinx they lack a revision control system, they will build in something in such a Xilinx way, it will be incomprehensible

0 Kudos
maps-mpls
Mentor
Mentor
445 Views
Registered: ‎06-20-2017

Sounds like a learning curve issue, in that your suggestion "How about allowing the user the option of specifying which directories source code, IP files, tcl scripts, program command lines, etc. be placed in" is already here in a sense.  Spend a half a day and learn some tcl.  Even project mode Vivado projects can be scripted.  And you have complete control.   And Xilinx through the journal file makes it trivial to create a project, review the journal script, cut, paste it into your own, and modify.  And Tcl at the level you need it is pretty trivial to learn.  You might consider Vivado Training if it is too steep of a price to pay (learning on your own).  And if the support team wasn't getting beat up so often, some of them might even point you in the right direction.

As an analogy:  I used to design PCBs way back in the day using PCAD.  SImple tool.  6-8 layer boards using FR4.  Running under DOS.  I know a lot about signal integrity and PCB design, and have guided very complex designs (and simple designs) to first pass success.  But if I tried to pick up and drive Altium today, it is a whole different beast as far as user interface goes, compared to PCAD.  I have used it to review PCB designer's work (with the designer sitting next to me explaining the user interface to me) but I don't think I'd be ready to design a PCB using a modern PCB tool like Altium without some training or mentorship .  If I had to work professionally using Altium to design a 24 layer Megtron 6 card, I would talk to my boss about getting some training, or just hire somebody who already knows how to drive the tool.  I'd personally want the training from an experienced instructor who actually uses the tool for real projects, not a pre-recorded video starring a voice actor reading a script written by a content developer--but that is me. 

We're all engineers of some sort.  But you have to learn to adapt, as not only is the technology changing today, it will continue to change throughout your career. 

If you don't like working on the bleeding edge (and we all get cut working on the bleeding edge), maybe stick to Spartan 6 and ISE/planahead, or PIC microchips, or 80C186 processor designs.  I am not trying to be mean here, but I have noticed a whole lot of complaining on these boards by a lot of people lately, and it is spreading, about things I deem to be trivial in comparison to other issues I think Xilinx should address.  Making prettier block diagrams and supporting a VHDL2019 feature that will save me one line of typing in VHDL are very low on that list.  

And I understand (as all engineers should) that issues need to be prioritized, as the tech labor economy doesn't have an infinite number of workers willing to work for free adding every feature every squeaky wheel user requests.

Anyway, we all could use some attitude adjustments (myself included), and stop and take inventory of our careers.  Some of us are working on devices with close to 50,000,000,000 transistors, capable of processing more data in a second than an entire state of people can type in their entire lives.  A data center and super computer on a chip.  With all sorts of abstraction and tools and utilities and GUIs that are not widely used (compared to Microsoft Excel), and are pushing the limits of CMOS thanks to Xilinx's and AMD's relationship with TSMC.

Disagree if you want...it's just a few observations.

 

*** Destination: Rapid design and development cycles *** Unappreciated answers get deleted, unappreciative OPs get put on ignored list ***
0 Kudos
spaceboy
Visitor
Visitor
424 Views
Registered: ‎03-08-2021

I understand and use tcl and have done many ASICs. I've been around too. Which is why I like to keep source code, which includes constraints and tcl, separate from CAD system; this enables you to run tools from different manufacturers on the design to check it. The current Xilinx system seems to want to borg-like swallow all the independent life-forms. But I did get a useful tip from someone here earlier.

0 Kudos
maps-mpls
Mentor
Mentor
420 Views
Registered: ‎06-20-2017

Cool.  Because Tcl solves the directory issue.  That same checkbox you use in the gui to not copy a file into a project is an option in a tcl command.

EDITED TO ADD:  Now that I think about it, fixing many of these issues that are being reported would reduce the barrier to entry, and possibly get more customers using Xilinx parts.

*** Destination: Rapid design and development cycles *** Unappreciated answers get deleted, unappreciative OPs get put on ignored list ***
0 Kudos