UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor gguichal
Visitor
6,782 Views
Registered: ‎05-18-2016

Vivado is still sloooooow and buggy, very buggy - Please bring back "Clean Up Project Files"

Jump to solution

I use Vivado to teach a digital design class, so I like the block diagrams to show the concept of interconnecting IP and to quickly integrate IP. But I just wasted 3 hours because of bugs and feel the need to rant. And also to ask XIlinx to improve this stuff.

 

Probably not using BDs would help, because they suck! But teaching-wise it is very useful.

 

It is slow.
I am not talking about how slow it is to synth a counter and flip flop that toggles a LED (which it is), but in its UI and handling files and stuff like that
- Remove a file... it takes forever to do... what? I dunno... 
- Add a file... it takes forever to do what.. I dunno
- It wants to do stuff for you so it takes forever to try to figure out what it should do: "Should I select a new top level whatever?"... NOOOOO... I am removing, adding, editing files. I will tell you when I am done. And I will tell you what the toplevel is
- Slow for everything that is handling stuff

Hides stuff and makes projects huge 
- Sources for BD, IPs and and sims are all in separate ;places, so exporting a project takes huge amounts of drive, when it shuld be just the RTL and probably XML files hat say what cores are used and how they are configured. 
- You want to look for this stuff and find things in 10 different places that are all called the same thing... well. Why should you look for this stuff? Because there are bugs, bugs, bugs!!! And also because I wanted to see if there was a simple way to export stuff so students could turn in their projects without all the crap that Xilinx adds  

- Board definitions... man. A mystery that can hold all sorts of crap that nobody knows about. Let me use the frikin good old XDC for the ins. Not add this stuff somewhere else that actually defines pins I am not aware of!
- 1 million wrappers for each thing, Aghhh. Check out how Mentor's HDL Designer does this stuff. Much cleaner.

- Some bug in the RTL... and suddenly a module is disabled, a new toplevel selected automatically. Whattt? It was only a small bug!!! Don't try to figure out what to do. Just tell me: hey. Your stuff is broken! Go fix it.

Buggy

- OMG... when using BDs signals disappear, are kept even if deleted, stuff is not updated even when forced!
- And you check the generaed RTL but everything seems good, until you look and look through the tremendous amount of c**p XIlinx added to the directory and find somewhere there is actually a generated RTL that still holds a signal you deleted!!! You regeneerate the wrappers, look through them and they're fine. But for synth or sim it uses something else that you don't know here wthe it is
- I just spent some hours figuring out if I was missing something... "port xxx doesn't exist. Check declaration vs whatever". I looked, and looked and looked and nope Everything was fine. I just changed the port names and then it decided some mysterious stuff and everything is fine. I assure you I did not have a bug. Ports were 4 bits wide, not 8. That was BEFORE I changed it and Vivado decided something was "up to date" and didn't regenereta it. 

Clean Up Project FIles

- It's SW... it will have bugs... so please, please, please XIlinx... do what you had in ISE. Allow me to clean up all the c**p you created and star over, so all this stuff will be started anew

I am seriously thinking about going to Intel to teach. I wonder if Quartus has the same problems. 

1 Solution

Accepted Solutions
Scholar jmcclusk
Scholar
10,243 Views
Registered: ‎02-24-2014

Re: Vivado is still sloooooow and buggy, very buggy - Please bring back "Clean Up Project Files"

Jump to solution

As Winnie the Pooh once famously said:   "Vivado is the worst of all FPGA design tools,  except for all others...."

 

I recently spoke with a university engineering student about his FPGA classes, and he told me about his experience with programming Virtex2Pro boards using ISE 10.4.     I sadly had to tell him that his knowledge was by and large useless for any potential employers.   

 

Vivado is slowly becoming ossified, as new features are added, and complexity increases.   I fear your post @gguichal will garner a lot of kudo's for declaring that indeed, the emperor has no clothing.  

 

I hate to say it, but you should also develop a very early teaching module showing students how to run Vivado in non-project mode, using either CentOS or Ubuntu.  

Don't forget to close a thread when possible by accepting a post as a solution.

View solution in original post

20 Replies
Scholar drjohnsmith
Scholar
6,774 Views
Registered: ‎07-09-2009

Re: Vivado is still sloooooow and buggy, very buggy - Please bring back "Clean Up Project Files"

Jump to solution
Agree with the basics , but Xilxin wont do much about this, the money is in the big chips,
And those guys have hair on the chest and have braces holding up their trousers, GUI is not for them . If it can't be put in a TCL or Python script they are not interested.
<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
Visitor gguichal
Visitor
6,731 Views
Registered: ‎05-18-2016

Re: Vivado is still sloooooow and buggy, very buggy - Please bring back "Clean Up Project Files"

Jump to solution

Maybe... but they have put a lot of effort and $ on something that doesn't work well, so I am not so sure. I think the strategy is to push towards having non-HW developers (SW developers) doing FPGA, so they try to hide and solve things for you HW-wise... but in my opinion this is not working well with Vivado.

In a second course I teach I  have had SW developers do HW by integrating cores and teaching some idea of RTL and HW design. And it works, except for when we run into situations where students spend a week working on something thinking they are doing something wrong... when it's actually a Vivado bug :-( 

0 Kudos
Observer keisn13
Observer
6,704 Views
Registered: ‎10-28-2013

Re: Vivado is still sloooooow and buggy, very buggy - Please bring back "Clean Up Project Files"

Jump to solution

Unfortunately this happens sometimes with Vivado on Windows OS!

Last update of the Windows killed my sound device at laptop. After that i am installed Ubuntu, and currently do not have any problems with GUI.

I think that You must to do the same: format C:/ and install Ubuntu

Scholar jmcclusk
Scholar
10,244 Views
Registered: ‎02-24-2014

Re: Vivado is still sloooooow and buggy, very buggy - Please bring back "Clean Up Project Files"

Jump to solution

As Winnie the Pooh once famously said:   "Vivado is the worst of all FPGA design tools,  except for all others...."

 

I recently spoke with a university engineering student about his FPGA classes, and he told me about his experience with programming Virtex2Pro boards using ISE 10.4.     I sadly had to tell him that his knowledge was by and large useless for any potential employers.   

 

Vivado is slowly becoming ossified, as new features are added, and complexity increases.   I fear your post @gguichal will garner a lot of kudo's for declaring that indeed, the emperor has no clothing.  

 

I hate to say it, but you should also develop a very early teaching module showing students how to run Vivado in non-project mode, using either CentOS or Ubuntu.  

Don't forget to close a thread when possible by accepting a post as a solution.

View solution in original post

Explorer
Explorer
6,488 Views
Registered: ‎09-13-2011

Re: Vivado is still sloooooow and buggy, very buggy - Please bring back "Clean Up Project Files"

Jump to solution

ISE had an excellent source scanner that was fast and could look through the most obvious mistakes in the code hierarchy - but for some reason Xilinx chose to unlearn everything they learned with ISE - they threw away everything. Now some 6-7 years after Vivado came to life its source scanner is still not as good as the one Xilinx had in 2011, rather it is much worse even from what Vivado had a few years back. Amazing too that only last year it became possible to delete a non-existent file without editing the auto-generated project file.
I can't see the wisdom but I agree that Vivado is the worst except for all the others and if one day Vivado becomes really good Xilinx will surely choose to obsolete it and forget everything about it...

Scholar u4223374
Scholar
6,428 Views
Registered: ‎04-26-2015

Re: Vivado is still sloooooow and buggy, very buggy - Please bring back "Clean Up Project Files"

Jump to solution

Fully agree on the speed aspect. The "important" tasks that Xilinx probably focuses on are fast, but the "unimportant" ones that get used much more frequently (I make connections between blocks in the block design more often than I run place & route) are horrible.

 

Case in point: I'm doing an experimental design with 48 AXI UARTs and three AXI interrupt controllers. There is nothing complex here - all the UARTs are identical, all the interrupt controllers are identical.

 

After connecting all of these (which took forever - I should not have time to write an email while waiting for Vivado to connect all my clock pins together) I needed to assign addresses. Easy: go into the address editor and hit "auto assign addresses". Given that this is simply a process of finding the next available address for each unit, I would have thought that something less than one second would be reasonable. Instead it took over 26 minutes. I've got no idea how it was possible for it to take so long.

 

 

Edit: with regards to Altera/Intel and Quartus - from what I've read, Quartus is not really any better than Vivado or ISE, and its free version is significantly more restricted. Vivado's free IP and the HLS functionality make it pretty special for hobby users.

 

However, Intel has traditionally done a pretty good job in software development where necessary to support their products and also just in general (OpenCV was originally developed by Intel). If Intel open-sources their FPGA toolchain (or provides documentation to allow open-source versions to be written) then I'll switch in a heartbeat. If they just do a Vivado-equivalent with an interface that works better, it'll be very hard to stick with Vivado in the long term.

6,235 Views
Registered: ‎01-08-2012

Re: Vivado is still sloooooow and buggy, very buggy - Please bring back "Clean Up Project Files"

Jump to solution

> but for some reason Xilinx chose to unlearn everything they learned with ISE - they threw away everything.

 

They had two teams doing essentially the same thing.  There's an obvious business decision to be made when a company is in that situation.  Unfortunately, they seemed to have lost a lot of compiler know-how when they did it.

Scholar drjohnsmith
Scholar
6,191 Views
Registered: ‎07-09-2009

Re: Vivado is still sloooooow and buggy, very buggy - Please bring back "Clean Up Project Files"

Jump to solution

@allanherriman

 

It was a sad time for the smaller designers.

    Xilinx realised that BIG chips make 1000 times more profit but only cost 10 times more support over small chips,

       and ISE was seen as a small chip solution,

 

They made the choice to drop small chips ( you try to compile a cool runner on windows 10 ) 

    and move to the ASIC flow technique of big chips.

 

And now moving to HLS world, where the chip cost is approaching zero compared to the design time,

    

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Scholar drjohnsmith
Scholar
6,188 Views
Registered: ‎07-09-2009

Re: Vivado is still sloooooow and buggy, very buggy - Please bring back "Clean Up Project Files"

Jump to solution

@jmcclusk

 

"I recently spoke with a university engineering student about his FPGA classes, and he told me about his experience with programming Virtex2Pro boards using ISE 10.4.     I sadly had to tell him that his knowledge was by and large useless for any potential employers.  "

 

At the moment I would dis agree with you, but thats may be another time.

 

I don't expect new students to know how to use the tools we use, 

    but I do expect them to know about the basics of RTL, and how the RTL converts to silicon.

 

We can easily bring a student up to speed on how to use a tool, 

    but it takes months to bring one up to speed that did not know RTL.

 

I say at the moment,

   as I'm aware this could be the equivalent to the  Assembly to C transition point in processors.

 

I could not program a multi core ARM system, any where as near effectively in ASM as I can in C

      Once upon a time I could, now the compiler will beet me 99 % of the time, 

           and hay, yes the C uses 10 times more memory than I would in ASM, and runs at 100th the speed,

               but its here this decade..

 

so for now , I'd still want a student that knows the difference between a wire and a signal , a process and a function, what a delta time step is rather than know how to drive the latest Xilinx or Intel tool.

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
Scholar markcurry
Scholar
5,237 Views
Registered: ‎09-16-2009

Re: Vivado is still sloooooow and buggy, very buggy - Please bring back "Clean Up Project Files"

Jump to solution

 

Any day I actually need to start the Vivado GUI, is a day that I know will be a long frustrating, unproductive experience.   This is a fairly universal feeling within my peers – often leading to procrastination when any new Xilinx IP is required.

 

I think a lot of what led up to this is driven from top down with in Xilinx – the desire to get to the bigger market and get FPGAs everywhere.  It doesn’t take too much thought to look at a few employment stat sheets to see that the potential customer list for a “software engineer” is much, much higher than those labeled “hardware engineer”.  So we must aim our tools at the former right?

 

The Vivado GUI experience for just the IP Integrator, are a huge step backwards in digital design. It’s schematic capture no matter how you try to pretty it up.  It operates at a little higher level than single nets, but still it’s still schematic capture in the end.  It’s great tool allowing for the apps engineer to quickly put up a toy design during a presentation.  But getting any real work done?  In a team environment?  Integrating with Revision Control?  Just beyond useless – getting in the way, and preventing any real work.

 

A similar story is happening on the HLS front.  The premise of this tool (both within Xilinx and the EDA industry in general) – is similar – let’s empower software engineers to design hardware.  Look at how much C code is out there on the net, imagine if we could just push a magic button and that C code would target an FPGA?  It’s any marketing manager’s dream. 

 

It’s also a lie, end to end.  The first error is aiming at the software engineer.  The whole notion of everything happening concurrently in hardware is a difficult concept for the normal software engineer to grasp.  One may try to apply the software concept of threads onto the hardware, but it’s not really an appropriate analogy.  How many times on these Xilinx forums does the experienced FPGA designer note that one must “think hardware” when designing an FPGA?

 

The second error is the language.  C, and C-like languages are wholly inappropriate to describe hardware.  The first problem is, as noted, the parallesism, and concurrency are absent from the language design.  Hardware interfaces, both in type and use are abstract concepts to C.  In the end any C code that’s been converted to use in HLS is overloaded with pragmas and other cruft (the pragmas often dominating the source code).  The end result looks nothing like “off the shelf C”. 

 

The third error is integrating with the rest of the hardware design.  As any experienced digital designer understands, designing the kernel of most algorithms is usually the easy part – not taking all that much time.  The difficultly in almost all digital designs isn’t the kernel algorithm – it’s the “Goes Intos”, and the “Goes Outtas”.  Getting the data to the kernel for processing and then the results out (all in a timely manner) dominates the design and verification.  These sorts of control operations are very poor candidate for coding in HLS.  So the designer is forced to somehow bolt together HLS models of the datapaths with RTL models of the control and rest of the system.  And this process is far from clean.

 

In the end, the software engineer (remember, that’s who this tool is aimed at) is dragged down into some VERY low level details – in areas they’re not familiar with.  For the software engineer this isn’t moving up to a higher level of abstraction – it’s decidedly the opposite – forcing them to lower levels of abstraction.

 

Those trying to compare today’s RTL to HLS movement with the movement from Schematic Capture to RTL of 30 years ago are at best engaging in wishful thinking.  I’d just started my career when synthesis started taking over.  It was readily apparent at the time that this was the way of the future.  But even for those resisting – things fit together well.  The tools were aimed at the right person –the hardware engineer.  Schematics (i.e. netlists) can be represented perfectly fine in Verilog and VHDL.  Those schematic based designs still simulate quite fine alongside the rest of the RTL – even today.

 

The same cannot be said for C-based HLS designs.

 

Personally, I’d really like to get at some of the HLS design abstractions, and algorithms.  But it needs to be with a tool, and language aimed at me – the hardware designer – in a language I use (SystemVerilog and/or VHDL).  I can (and have) coded up a Video Scaler in clock-less, transaction based SystemVerilog.  I’d love a tool that converted this to RTL and/or gates – one that balanced latencies and bandwidths, and made various algorithmic level tradeoffs.  As it is, I don’t have such a tool.  For me, this reference model I’ve written is just used as a golden verification to compare my RTL coded version against.

 

Until the EDA industry starts actually doing this and aiming the tool at the hardware engineer, instead of the software, HLS will remain a niche – the same as it has for the past 20 years. 

 

Regards,

 

Mark

Scholar jmcclusk
Scholar
5,226 Views
Registered: ‎02-24-2014

Re: Vivado is still sloooooow and buggy, very buggy - Please bring back "Clean Up Project Files"

Jump to solution

Awesome rant Mark!

Don't forget to close a thread when possible by accepting a post as a solution.
0 Kudos
Observer maxdz8
Observer
5,152 Views
Registered: ‎01-08-2018

Re: Vivado is still sloooooow and buggy, very buggy - Please bring back "Clean Up Project Files"

Jump to solution

I'd be happy if they could at least fix the 'column edit' feature. Every time I must modify columns I copy-paste from Notepad++ instead.

0 Kudos
Visitor gguichal
Visitor
5,129 Views
Registered: ‎05-18-2016

Re: Vivado is still sloooooow and buggy, very buggy - Please bring back "Clean Up Project Files"

Jump to solution
Exactly! If they understand those concepts and what digital design implies and the elements involved and how the rtl constructs affect that design it doesn't matter what device or tools they've used. They'll be able to use sny tool and device with some effort.
Contributor
Contributor
4,996 Views
Registered: ‎02-12-2009

Re: Vivado is still sloooooow and buggy, very buggy - Please bring back "Clean Up Project Files"

Jump to solution

You'll want to consider the resource requirements for the tools these days WRT the "speed" of the tool.  
https://www.xilinx.com/products/design-tools/vivado/memory.html

 

Even a ZU9 like on the ZCU102 board requires a peak of 15GB of RAM.  Look at your current memory footprint before you even fire up the tool and realize that as soon as you hit the memory hard, you're likely going to cache to disk, which is going to bring things to a crawl.

 

The best way to improve the tool speed is to ensure your development platform (whether a local workstation, server, or laptop) exceeds the resource requirements.  For example, most of us have relatively new Lenovo Thinkpad laptops with 4/8 core Core-i7 and 32 GB of RAM, but synthesis alone of a relatively small design targeting (early development) targeting a ZU11 was taking over 4 hours.  Migrate to our new blade server with dual Xeon Gold 6126 with 64 GB of 2666MHz DDR4 and synthesis takes about 25 minutes.

 

 

DornerWorks
https://goo.gl/LNexn5



Xilinx Alliance Program - Premier Tier
Visitor gguichal
Visitor
4,899 Views
Registered: ‎05-18-2016

Re: Vivado is still sloooooow and buggy, very buggy - Please bring back "Clean Up Project Files"

Jump to solution

Good point... but it doesn't fix the ugly GUI bugs :-)

0 Kudos
Visitor treczoks
Visitor
4,486 Views
Registered: ‎11-23-2007

Re: Vivado is still sloooooow and buggy, very buggy - Please bring back "Clean Up Project Files"

Jump to solution

> The second error is the language.  C, and C-like languages are wholly inappropriate to describe hardware.

 

As someone who has played on both sides, I fully agree. C is really not the best way to describe hardware in any form.

 

On the other hand: VHDL as a language is crap. Yes, it's bondage and discipline approach gives a few percent of additional error detection, but when I write a test bench, I always want to wring some developers necks. Yes, file IO and strings are not something of concern to hardware synthesis, but they are vital for simulation. And then some idiots decided that file IO uses bit vectors instead of std_logic ones. And don't provide any conversion routines.

 

The VHDL language design and structure is based on ADA, which was a horrible abomination when it was designed seventies (if you ever used the term "as designed by a committee", well, ADA is a masterpiece on that behalf), and has not really improved over the decades. It got a bit of patch-up - most of which is not supported by all platforms. But compare that slow pace with what happened on the software side. And how much more comfort and safety software development languages offer over e.g. normal C.

 

I can understand that Xilinx wants to get C programmers on board - Just compare how many programmers can write C vs. those who can write VHDL. But in the end, this is just a sales point. Someone has to understand the way a system ticks in order to accomplish something. If you grok hardware design and synthesis, you can use about any language that is can be synthetisize. If not, even the best language and IDE cannot help you.

 

Thank you for listening.

0 Kudos
Visitor treczoks
Visitor
4,482 Views
Registered: ‎11-23-2007

Re: Vivado is still sloooooow and buggy, very buggy - Please bring back "Clean Up Project Files"

Jump to solution

> Clean Up Project FIles

> - It's SW... it will have bugs... so please, please, please XIlinx... do what you had in ISE. Allow me to clean up all the c**p you created and star over, so all this stuff will be started anew

 

Oh my goodness! They removed this vital piece of software? I have not managed to get vivado running on my machine so far (my OS is a few years to current for xilinx requirements), but I use ISE ona a nearly daily base, and "clean up project files", while it should not be necessary, saved my day many, many, times. Whenever I get an unexplainable problem, a cleanup and compile fixes it.

 

Removing this vital feature looks like they either lost the knowledge they would need to determine what is actually crap - which would explain a lot, the cleanup feature should never be necessary, and wouldn't be if their build process actually knew what to do, and which parts to regenerate. Or it is the next step in xilinx war path against sourcecode repositories and revision control systems: Absolute paths everywhere and directories filled with large crap spread all over the landscape. And now we cannot even clean up the worst of it.

 

I had hoped that with vivado, they would cut a lot of crap from what was delivered with ISE, but it looks like they only made it worse in some places.

Scholar drjohnsmith
Scholar
4,357 Views
Registered: ‎07-09-2009

Re: Vivado is still sloooooow and buggy, very buggy - Please bring back "Clean Up Project Files"

Jump to solution

I always liked BASIC as a language,

Or Turtle,  lots of kids of 3 or 4  could program in that,  

     

why not use that as a new Hardware define language,

   then we'd not have a skills shortage of hardware programmers.

 

    its just as relevant as saying use C or such like.

 

Any language that does not have concurrency and parallelism at its heart, is going to have to fight hard to get around those problems

 

If C++ was good for concurrent processing and parallisum , I wonder why I can't use all 16 cores on my machine to speed up one program,

 

and Yes, I am an X ADA and Cobol programmer, ....

 

 

 

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
Visitor treczoks
Visitor
4,105 Views
Registered: ‎11-23-2007

Re: Vivado is still sloooooow and buggy, very buggy - Please bring back "Clean Up Project Files"

Jump to solution

@drjohnsmith wrote:

I always liked BASIC as a language,

Or Turtle,  lots of kids of 3 or 4  could program in that, 


It is not the point which language one knows. Even C or C++, while known by many, is not the best solution for defining hardware.

 

What we would actually need is a proper new hardware definition language that is actually a child of the 21st century, not just something based on an outdated concept of the 60s/70s that has been bent around to define hardware.

0 Kudos
Explorer
Explorer
2,533 Views
Registered: ‎09-26-2014

Re: Vivado is still sloooooow and buggy, very buggy - Please bring back "Clean Up Project Files"

Jump to solution

This is not a crash this is a disaster.
  I spent a few hours running some projects. As a result, my initial project is not compiled.
  The process of periodicals freezes, and it is necessary to control whether the synthesis hangs or the implementation hangs.

 GUI is very slow - I have not yet met such stupid CAD. 

0 Kudos